dataesr/scientific-paragraphs-categorization huggingface dataset:
Designed and calibrated to account for the specificities of small reservoirs, this semi-automated MNDWI approach reduced RMSE by 57% in comparison, by minimising omission errors from flooded vegetation and shallow waters. Results also argue for the importance of exploiting all Landsat archive imagery to maximise temporal resolution, capture flood peaks, reproduce coherent flood dynamics and improve water resource assessments considering the rapid flood declines in small lakes. Clearer distinction of clouds and SLC-off in the JRC datasets would have allowed finer filtering of images due to the non systematic cloud error observed here. Accurate long term water availability assessments are notably required to inform farmers of water resources in the millions of small reservoirs worldwide  (Wisser et al.
A3 Topographic normalisation Finally, topographic corrections to account for the effect on surface reflectance values of reduced illumination from inclined surfaces were implemented. The Minnaert algorithm  (Minnaert, 1941) , shown to perform as well or better than C correction, Cosine correction and Gamma correction  (Vanonckelen et al. , 2013; Hantson and Chuvieco, 2011)  was used. Minnaert adds a band specific constant K to the cosine correction, a trigonometric correction defined in Eq. (A10) where ρ t is the reflectance value generated by the inclined surface, and ρ h is the value on a theoretical flat surface. Illumination is modelled as per Eq. (A11) where γ i is the incident angle, slope angle is θ p , solar zenith angle is θ z , solar azimuth angle φ a , and aspect angle φ o. Slope and aspect were derived in R from the SRTM version 3 30 m digital elevation model, and information on solar azimuth and zenith angle were extracted from satellite and solar geometry in the metadata files.
Fmask  (Zhu and Woodcock, 2012)  which uses top of atmosphere reflectances for all visible and IR bands, and brightness temperature for band 6 (Eq. (A12)) as inputs was used to assess clouds and shadow presence on each image and over each lake cell. It reports a 96. 41% overall accuracy vs 84. 8% for the Automated Cloud Cover Assessment (ACCA) algorithm  (Irish et al. , 2006)  used originally by the USGS. DN values in Landsat thermal bands were converted to TOA radiance using Eq. (A2) and then to (brightness) temperature (Kelvin) using Eq. (A12). ρ h = ρ t • ( cosθ z IL ) K (A10) brightness temperature = K 2 log( K1•ε L + 1) (A12) K1 and K2 can be found in the Landsat 8 metadata and in the literature for Landsat 5 and 7  (Chander et al. , 2009). ε is emissivity, and can be estimated as 0. 95 to account for atmospheric interferences.
Acknowledgements. We gratefully acknowledge the collaboration from the  Direction Générale de l'Aménagement et de la Conservation des Terres Agricoles (DG ACTA)  and  Direction Générale des Ressources en Eau (DGRE)  in Tunis and local representatives at the Kairouan and  Siliana Commissariat Régional au Développement Agricole (CRDA). These works were partly financed by the  ANR AMETHYST  and SICMED DYSHYME projects. SPOT 5 10 m imagery was provided through  CNES ISIS  programme, request 703. 28 Hydrol. Earth Syst. Sci. Discuss. , https://doi. org/10. 5194/hess-2018-19Manuscript under review for journal Hydrol. Earth Syst. Sci. Discussion started: 24 January 2018 c Author(s) 2018. CC BY 4. 0 License.
Hydrol. Earth Syst. Sci. Discuss. , https://doi. org/10. 5194/hess-2018-19 Manuscript under review for journal Hydrol. Earth Syst. Sci. Discussion started: 24 January 2018 c Author(s) 2018. CC BY 4. 0 License. cloud & shadows detection and notably specific methods capable of addressing the incremental change even on small land use objects  (Zhu and Woodcock, 2014). Alternate optimisation of clouds & SLC-off or concomitant imagery sources including active sensors (Eilander et al. , 2014)  could also be used to maintain more observations at critical stages (e. g. flood peaks). Remotely sensed observations may also be combined with field data and modelling to overcome image availability issues and problems of incoherent hydrological dynamics. Code and data availability. Landsat L1T data are available from USGS Earth Explorer.
Using classical protein classifications such as SCOP, proteins in the same superfamily but not in the same family are considered remote homologous proteins. Finally, ranking methods approach remote homology detection as a database search. Upon embedding known protein structures into a (generally fixed dimensional) space, the query protein is used to retrieve the nearest neighbors-see again  [3]  and the references therein. Because protein structures and functions tend to be more conserved than sequences  [7] , the use of combined sequence -structural information also offers various routes to improve the detection of remote homologs. These methods target different features of proteins, including folds, pockets and clefts, active sites, interfaces and protein -protein interactions  [8, 9, 10, 11].
Similarly to HMAPs  [8] , our method combines structure and sequence information; yet, it bears major differences. First, the method relies on structurally conserved motifs that may span SSE and loops, as opposed to secondary and tertiary structure elements. Second, it involves a unique parameter, used to tune the stringency threshold of structural information termed relevant -see above our discussion on stringency thresholds. Third, our structural motifs are used to produce profile HMM biased towards structurally conserved regions. These HMM are then utilized to query databases such as UniProtKB, in order to retrieve the sequences of proteins which may exhibit the function of interest. We validate our hybrid profile HMM on two problems related to class II fusion proteins. First, using variable learning sets involving viruses and eukaryotes, we show that our hybrid HMM retrieve from UniProtKB species which are beyond reach for models based on sequences only.
Step 3: Database queries and filtering Database queries. A HMM is used to query UniProtKB. Such a query return hits in the form of UniProtKB accesion codes (unique identifiers tied to a protein sequence). The significance of hits being assessed with e-values (SI 7. 4. 4). For a given hit, we retrieve the taxonomic information from the NCBI Taxonomy database  [31]  (SI Sect. 7. 4. 4. ) Note that we focus on species rather than protein sequences, since fragments, isoforms, or variants of a given protein typically correspond to separate entries. Filtering hits using annotations: generic and fusion class II specific. The hits obtained can also be filtered using various criteria, which we illustrate for class II fusion proteins. A first filter identifies transmembrane proteins. To find a transmembrane region in a hit from its FASTA sequence, we use Phobius  [32].
The second filter aims at identifying class II candidates, based on three conditions: (i) at least one transmembrane region, (ii) an ectodomain (protein region extending into extracellular space) involving ≥ 400 residues, (iii) at least six cysteins in the ectodomain. Cross-validation using HMM-HMM comparisons. Sequences obtained from UniProtKB can be rescored via HMM-HMM comparison (HHpred,  [6] ; see also SI Section 7. 4). This strategy being of special interest to check the coherence with a HMM associated with a structure, we practically launch a query on the target database PDB mmCIF70 (see https://toolkit. tuebingen. mpg. de/#/tools/hhpred). Remark 2 With respect to our overarching goal, which is to annotate sequences from UniProtKB, note that we use HMMER rather than HHpred, since since HHpred searches selected databases (PDB, Pfam, SMART,.
Software The software implementing our methods is available in the Structural Bioinformatics Library  [33]  at http: //sbl. inria. fr). The two main packages involved are Structural motifs for the detection of motifs (https: //sbl. inria. fr/doc/Structural_motifs-user-manual. html), and FunChaT for the functional characterization of proteins (https://sbl. inria. fr/doc/FunChaT-user-manual. html).
performs better although HMM Hyb. still has exclusive species. Note that this tally is not exhaustive as some proteins that are known HAP2-GSC1 family members are not annotated. For example, the Tetrabaena socialis HAP2 protein (UniProtKB accession code A0A2J8AI85), does not have the HAP2-GSC1 domain annotation. Even though it is a know HAP2 protein, it will not show up in the HAP2-GSC1 domain count. Additionally, members of HAP2-GSC1 in larger organisms (such as vertebrates) are theorized to be distant homologs. A model that is too specific could be a hindrance to finding such a protein so that loosing some hits in the further steps should not be necessarily seen as an obstacle torward that goal. Homologs of HAP2-GCS1. To further constrain the models, we restrict the learning set to the domains II of three HAP2-GSC1 structures known at the time of this study.
The three structures accession numbers are 5MF1 (HAP2e)  [22] , 5OW3 (AtHAP2) and 5OW4 (TcHAP2)  [23]. Using motifs at threshold τ / = 0. 8, we build a new HMM Hyb. (SI Fig. 11  for its sequence logo. ) When results are displayed, the particular method used is indicated (by method we refer to Align-Kpax-CD, Align-Kpax-SFD, see Section 3. 2, and the multiple sequence alignment used). To assess the ability of our method to find remote homologs, we check for the recovery of the most distant known homolog to our training set, the HAP2-GCS1 in the drosophila fly. It was indeed shown  [35]  that D. melanogaster gene CG34027, an ortholog of HAP2-GCS1, codes for a protein involved in plasma membrane fusion. Different combinations of filtration methods as well as sequence aligners yield different results (Tab.
3). From the first iteration, we recover a number of known HAP2 sequences, notably in arthropodes (34 species, data not shown). From the first bootstrap iteration, we recover 17 plausible HAP2-GCS1 candidate sequences in 10 different Drosophila species. We cross validate these results using HHpred (Sect. 3. 4 on HMM-HMM comparisons). Of particular interest are comparisons against the known gamete fusion protein in chlamydomonas reinhardtii (HAP2 structure, pdbid 5MF1). Eleven of the sequences returned a very low e-value leading to the conclusion that they are most probably HAP2 proteins (Tab. 3). One of these corresponds to the aforementioned gene CG34027 (UniProtKB identifier: Q2PDQ0). Importantly, none of these eleven sequences mentions the Pfam domain PF10699 (https://pfam. xfam. org/family/PF10699).
c) The groups of structures as presented in Sec. 2. For each group, we display pairwise sequence identity statistics as well as structural similarity. Regarding sequence identity, we denote three cases (which are color coded): pairs of structures (for which there is only one value), mildly heterogeneous groups (with a small interval of sequence identity values) and heterogeneous groups. 10 We study N structures with low sequence identity and loose structural homology, yet harboring the same function. We identify structurally conserved motifs, characterized by a least RMSD ratio smaller than yielded by the whole structures. Sub-sequences of motifs and whole sequences are used to build multiple sequence alignments. Next, these MSA are used to build profile hidden Markov models (HMMER). HMM are used to query the Uniprot database.
org and by the JSON-LD format. Furthermore, the tree representation abstracts from the semantic web approach. Other standards and data models could be used in a similar manner to create the semantic schema. The tool supports the selection of vocabulary terms based on string searches by accessing repositories of semantic vocabularies (e. g. , the LOV repository, as discussed in section 2. 2). Exploration of attached elements of a chosen vocabulary term should also be abstracted from the underlying concept, and selected terms may be added to any part of the targeted schema tree. The example in Figure  1  shows a user who intends to publish information about a smart home and creates a tree structure of semantic terms related to his/her facilities/Things (e. g. , House, Car, etc. in ). •.
SMART PARKING USE CASE The context of the proposed use case falls within the scope of the bIoTope H2020 project, which is part of the IoT-EPI initiative  [15]. The bIoTope ecosystem is built upon three building blocks that aim to form a trade-off between RESTful principles using open standards (while also supporting remote procedure calls for heavier web services) and developing ecosystem components that provide interoperability among all levels under IoT requirements. These three building blocks are briefly introduced hereinafter: • Open Data Format subscribe, or by remote procedure calls. O-MI, in combination with O-DF, forms a service description and are thus applied to achieve pragmatic interoperability. • IoT service marketplace  [15] : It holds a repository of available O-MI/O-DF services and their specifications.
Based on the integration of vocabularies it is possible to discover relevant data and services, which can then be accessed in a peer-to-peer fashion in a common publish-find-bind manner. Consumers are also able to track changes in the state of published services, which allows for dynamic interoperability through the marketplace. In order to demonstrate the practicability of our productivity tool, a smart parking use case has been defined and implemented. This use case extends the one presented in  [14] , and is illustrated in Figure  2. Considered is a scenario in two distinct smart cities, namely Grand Lyon and Brussels Region, both being official partners of the bIoTope project. Step in Figure  2  illustrates how various data providers of smart things (e. g. , of parking sensors or charging stations) in the city expose the data through traditional, proprietary APIs.
In step , PROFICIENT is used to create a standardized gateway around these APIs. In this demonstrator, two O-MI gateway agents -exposing information of parking facilities in Lyon and in Brussels -are deployed thanks to a prototype (which is presented in following Section 4. 1). The two existing formats of the parking data (proprietary JSON, Datex II 8  in XML) are mapped to the MobiVoc 9  vocabulary. Step shows the implementation of an IoT service that relies on the published data, namely a service that is able to discover available parking data and gives recommendations to drivers for best parking locations based on the location and other vehicle-related features. Step shows the bIoTope service flow through the O-MI gateway, whereas step shows the In the following, the implementation of PROFICIENT is presented in Section 4.
PROFICIENT Prototype The productivity tool concepts presented earlier in Section 3 are implemented as a prototype to meet the bIoTope requirements. This implies that O-DF is the targeted format and that the generated IoT gateway agent pushes the O-DF structured data into an O-MI server node. However, the internal representation is based on a generic semantic format, which is JSON-LD. The implementation of the PROFICIENT prototype is depicted in Figure  3. Steps 1 and 2 are illustrated through two distinct screenshots of the web interface of the productivity tool. In step 1, the user can define the targeted semantic schema(s) of the data to be published by accessing vocabulary terms from the LOV repository (cf. , Section 2. 2). The user is able to add terms individually or browse through attached properties and add parts of the tree structure to the targeted schema.
g. , only one parking item in Brussels) instead of requesting the whole data structure (e. g. , all parking-related data) exposed by the O-MI gateway. The IoT service marketplace developed in bIoTope can eventually help developers to search for and access such service items depending on their location, service type and/or reputation, etc. Such an architecture -having resource-constrained devices at the edge of the network and a powerful server at the marketplace level -helps unload the incoming traffic at the O-MI gateway level, thus offering low response times. The effort is therefore drifted from the IoT data publishers to an IoT intermediary service, namely the IoT service marketplace. In a second experiment, it was investigated whether the harmonized data formats (O-DF-based) impacts the application performance compared to the direct access to the proprietary APIs.
DISCUSSION To open the discussion section about the approach for enhanced interoperability proposed in this paper, the links between the building blocks of the bIoTope ecosystem and LCIM (cf. Table  1 ) are presented in Table  5 , while highlighting which layers the productivity tool prototype directly and indirectly supports. The presented productivity tool directly contributes to semantic and pragmatic interoperability. Supporting the design of a standardized data structure by suggesting known semantic terms for annotation aims at semantic interoperability. The application of the tool to O-MI/O-DF addresses pragmatic interoperability, as O-MI and O-DF together form a service description, i. e. define how to read data objects and call methods.
HTTP, etc. compliant This table reveals that our approach relies indirectly on existing interoperability mechanisms for the lower layers. The O-MI standard (used for the presented prototype) is mainly built upon the HTTP stack (technical interoperability) and uses XML as a serialization (syntactical interoperability). The presented productivity tool prototype does not contribute to these levels, but relies and complies with existing solutions of the bIoTope initiative. The indirect influence of the proposed productivity tool on dynamic and conceptual interoperability is more significant. This is because the discovery of data and services via the IoT marketplace (at the dynamic interoperability level) highly depends on the semantic annotations. At the same time, the bIoTope ecosystem follows an open vision that does not statically impose a conceptual model on all data/service providers and consumers, but rather aims to guide data/service providers to find the right model for their use case.
Such a guidance can be achieved thanks to an approach (and associated productivity tools) like the one presented in this paper. The proposed productivity tool, as of now, relies on the LOV repository. If a certain term is not available in existing vocabularies, the user is able to add custom elements to the data structure. This could be an advantage in terms of flexibility, however, it also leads to inconsistencies in the semantic model. In addition, the selection of the right vocabulary term(s) is not very intuitive from the ranking of terms returned by LOV's API. Users might have a different technical and domain-related background and might want to reuse vocabulary terms based on custom preferences. This opens up a research question on how to "optimally" select the right vocabulary terms depending on various criteria such as the vocabulary relevance (popularity.
), or the relationship between vocabularies (which impacts on potential reasoning built on the data structure). Furthermore, even though the tool aims at reducing the overhead for such a process, it is still challenging to motivate IoT data/service providers to publish their IoT resources based upon open standardized APIs as long as the process is not fully automated. However, such a productivity tool could also be applied by consumers themselves, e. g. , by system integrators of companies who aim to provide all company departments with an harmonized way of accessing and understanding data from various and disparate information systems. Another limitation for the bIoTope prototype arises through the design of O-DF, which was not designed to represent RDF but rather for describing IoT resources in a simple manner.
CONCLUSION AND FUTURE WORK This paper presents a productivity tool that allows to publish IoT data and services with minimal effort to the Web of Things (WoT). The steps introduced by the conceptual design of the tool include the development of the data structure based on semantic vocabularies, mapping of proprietary formats and entities, and the generation of an IoT gateway agent that can be deployed on any devices at the edge of the WoT. The prototype and use case is implemented in the framework of the H2020 bIoTope project (part of the IoT-EPI initiative), whose resulting IoT gateway agents are deployed to expose smart city-related data -Grand Lyon and Brussels Region in the presented use case -through the adopted open standardized API named O-MI (Open-Messaging Interface) and O-DF (Open-Data Format).
In conclusion, if O-MI nodes are hosted on resource-constrained devices, the requests should be formulated as specific as possible. The discovery of relevant IoT data or services (referred to as Objects and InfoItems in O-DF) can be optimized through potential IoT search engines and associated service marketplaces (as the one investigated in bIoTope), which is designed as a scalable cloud service. Future work includes the improvement of vocabulary recommendation by extending the lookup of model and vocabulary terms, as well as allowing a ranking based on user preferences. Furthermore, it is intended to automate more and more steps of the tool, e. g. with a learning model of the semantic mappings, to minimize the additional effort to publish in a standardized format.
K soilC scales the initial values (after spinup) of the slow and passive soil carbon pools in order to account for the historical effects that are not accounted for in the model spin-up that would result in a disequilibrium of these pools in reality (e. g. changes in land use and management). The parameter bounds and uncertainties used in this study were derived from literature analysis and parameter databases such as the TRY database (http://www. try-db. org, last access: 26 November 2018) as well as expert knowledge of the model equations; they are reported in the Supplement (Table  S1 ). The prior uncertainty is set to 40 % of the range of variation for each parameter following previous studies  (Kuppel et al. , 2012; MacBean et al. , 2015).
Assimilated data: carbon and water fluxes We use eddy covariance measurements of surface CO 2 NEE fluxes and latent heat flux (LE) from the FLUXNET global network (La Thuile database;  Baldocchi et al. , 2001). Based on an original list of the 252 sites we selected 78 sites, repre-senting 7 PFTs of ORCHIDEE (from the total number of 13) with the number of sites in each PFT varying from 2 (temperate evergreen broadleaf forests, TempEBF) to 24 (C 3 grasses) and the length of each observation record varying from 1 to 10 years. We only kept sites where the dominant PFT represents at least 70 % of the footprint of the flux tower so that we could restrict the optimisation to the parameters of one PFT per site. Also, we disregarded sites that had a large discrepancy with respect to the prior ORCHIDEE simulation (in terms of seasonal cycle), which suggests large model structural errors that prevent meaningful parameter optimisations.
For ORCHIDEE the corresponding TL model has been derived with the automatic differentiation tool TAF (Transformation of Algorithms in Fortran; see  Giering et al. , 2005) , following code cleaning and structural adjustments (without changing the physics) to allow the use of TAF (a significant effort that took around 2 years). It was used to calculate the gradient for all parameters except for two phenology parameters, K pheno,crit and C Tsen , associated with threshold functions. For these two parameters, the finitedifference method is more appropriate and was used here. The search is terminated when the relative change in the cost function becomes smaller than 10 -4 during five consecutive iterations. On average the iterative process stopped within 30 iterations. Given that the computation of a TL model run is about twice as long as the standard run of OR-CHIDEE, the total computation time for one BFGS optimisation for one site with 30 parameters is equivalent to around 1800 standard model runs.