dataesr/scientific-paragraphs-categorization huggingface dataset:
(Priyatna et al. , 2014)  have extended it to support custom R2RML mappings; they address the problem of eliminating null answers by adding not null conditions for SPARQL variables. Two limitations can be underlined though: (i) R2RML triples maps must have constant predicate maps, i. e. the predicates of the generated RDF triples cannot be built from database values; and (ii) triple patterns are considered and translated independently of each other, even when they share SPARQL variables. Unnecessary complexity is thus entailed in the SQL query with nested queries whose solutions are ruled out only during the final join step. Unbehauen et al. (Unbehauen et al. , 2013a)  define the concept of compatibility between the RDF terms of a triple pattern and R2RML term maps. This more general approach effectively manages variable predicate maps, which clears the first aforementioned limitation.
Furthermore, they reduce the number of candidate triples maps for each triple pattern by pre-checking join constraints implied by shared variables. This clears the second aforementioned limitation. Yet, two limitations can be noticed: (i) R2RML referencing object maps are not considered, therefore joins implied by shared variables are dealt with but joins declared in the mapping graph are ignored. (ii) The rewriting maps each term map to a set of columns, called column group, that enables filtering, join and data type compatibility checks. This relies on SQL capabilities (CASE, CAST, string concatenation, etc. ), making it hardly applicable out of the scope of SQL-based systems. Similarly, approaches have been proposed to deal with XML databases. SPARQL2XQuery  (Bikakis et al. , 2015)  relies on the ability of XQuery to support joins, nested queries and complex filtering.
For instance a SPARQL FILTER is translated into an encapsulating For-Let-Where XQuery clause. The rich expressiveness of SQL and XQuery makes it possible to translate a SPARQL query into a single, possibly deeply nested, target query, whose semantics is strictly equivalent to that of the SPARQL query. In the general case however, the target query language may not support joins, unions and/or subqueries. NoSQL databases typically make a trade-off between query language expressiveness and scalability. For instance, MongoDB does not support joins, and only supports nested queries under strong restrictions. To tackle this issue, we propose to translate the SPARQL query into a pivot abstract query independent of the target database, under xR2RML mappings. Our method relies on and extends the aforementioned SPARQL-to-SQL approaches.
The xR2RML Mapping Language The xR2RML mapping language  (Michel et al. , 2015a)  is designed to map an extensible scope of relational and non-relational databases to RDF. It is independent of any query language or data model. It is backward compatible with R2RML and it relies on RML for the handling of various data formats. It can translate data with mixed embedded formats and generate RDF lists and containers. Below we shortly describe the main xR2RML features and propose a running example. xR2RML language description. An xR2RML mapping defines a logical source (property xrr:logicalSource) as the result of executing a query (property xrr:query) against an input database. Data from the logical source is mapped to RDF triples using triples maps. A triples map consists of several term maps: they are functions that extract values from a query result set, and translate them into RDF terms.
A subject map generates the subject of RDF triples, and multiple predicate-object maps produce the predicate and object terms. Optionally, a graph map is used to name a target graph. Listing 2 depicts two triples maps <#Mbox> and <#Knows>, each consisting of a subject map, a predicate map and an object map. Term maps extract data from query results by evaluating xR2RML data element references, hereafter named xR2RML references. The syntax of xR2RML references depends on the target database e. g. a column name in case of a relational database, an XPath expression in case of a native XML database, or a JSONPath 1  expression in case of JSON documents like in MongoDB. xR2RML references are used with properties xrr:reference and rr:template. The value of a xrr:reference property is a single xR2RML reference, whereas the value of a rr:template property is a template string possibly involving several references.
Properties xrr:reference and rr:template may also accept mixed-syntax path expressions that are useful to deal with content of mixed formats: for instance, a JSON value embedded in the cells of a relational table can be addressed by specifying the column name followed by a JSONPath expression. Running example. We define a running example that we shall use throughout this paper. The reader interested in more detailed examples of xR2RML may Listing 3: Grammar of the Abstract Pivot Query Language look at  (Michel et al. , 2015a; Callou et al. , 2015). We consider a MongoDB database with a collection people depicted in Listing 1: each JSON document provides the identifier, email addresses and contacts of a person; contacts are given by their email addresses. Listing 2 defines two xR2RML triples maps.
This is achieved using specific values of the rr:termType property. Besides, property xrr:nestedTermMap is a means to create nested lists and collections, and to qualify terms of a list or collection with a language tag or data type. Like R2RML, xR2RML can model crossreferences: a referencing object maps uses subject values produced by the subject map of another triples map (the parent) as objects. Properties rr:child and rr:parent specify the join condition between documents of the current triples map (the child), and the parent triples map. This is illustrated in triples map <#Knows>, that joins email addresses from the emails and contacts fields. • trans m (gp) = trans m (gp, true) • if gp consists of a single triple pattern tp, trans m (gp, f) = transTP m (tp, sparqlCond(tp, f)) • if gp is (P FILTER f'), trans m (gp, f) = trans m (P, f && f') FILTER sparqlCond(P, f && f') • if gp is (P1 AND P2), trans m (gp, f) = trans m (P1, f) INNER JOIN trans m (P2, f) ON var(P1) ∩ var(P2) • if gp is (P1 OPTIONAL P2), trans m (gp, f) = trans m (P1, f) LEFT OUTER JOIN transF m (P2, f) ON var(P1) ∩ var(P2) • if gp is (P1 UNION P2), trans m (gp) = trans m (P1, f) LEFT OUTER JOIN trans m (P2, f) ON var(P1) ∩ var(P2) UNION trans m (P2, f) LEFT OUTER JOIN trans m (P1, f) ON var(P1) ∩ var(P2).
Translation of a SPARQL Graph Pattern Function trans m (Definition 1) translates a welldesigned SPARQL graph pattern  (Pérez et al. , 2009)  into an abstract query, while making no assumption with respect to the target database query capabilities. It relies on function transTP m (section 4. 4) to translate each triple pattern, and extends the translation algorithms defined in  (Chebotko et al. , 2009) , (Unbehauen et al. , 2013a) and  (Priyatna et al. , 2014). In particular we propose a generalized management of SPARQL filters: the goal is to push down SPARQL filters into the translation of each triple pattern, in order to make inner queries more selective and limit the size of intermediate results. A SPARQL filter f can be considered as a conjunction of n conditions (n ≥ 1): C 1 &&. C n. Function sparqlCond, further detailed in  (Michel et al.
Below we describe these functions in details and extend them to fit our context of an abstract query language. Function compatible (Definition 4) checks if a term map is compatible with a triple pattern term and a SPARQL filter. A term map is always considered compatible with a variable triple pattern term, unless a SPARQL filter contradicts the term map. These situations are identified in function compatibleFilter (Definition 5), they pertain to type constraints expressed using SPARQL operators isIRI, isLiteral or isBlank, as well as language and data type constraints expressed using operators lang and datatype. For instance, if variable ?var is matched with an object map that produces literals (rr:termType rr:Literal), the SPARQL constraint isIRI(?var) is unsatisfiable. When the triple pattern term is not a variable, function compatible identifies the similar situations wherein the triple pattern term and the term map cannot match with regards to the type of the triple pattern term (literal, IRI, blank node), its language tag (e.
A formal definition of function reduce is given in  (Michel et al. , 2015b) , and the concept of compatibility between term maps is shown in Definition 6. Definition 4. Compatibility between a term map, a triple pattern term and a SPARQL filter. Let tpTerm be a triple pattern term, termMap be a term map of an xR2RML triples map TM and f be a SPARQL filter. It holds that termMap is compatible with tpTerm and f, denoted by compatible(termMap, tpTerm, f), if termMap is compatible with filter f denoted by compatibleFilter(termMap, f), and either (i) tpTerm is a variable or (ii) none of the following assertions holds: • tpTerm is a literal and the term type of termMap is not rr:Literal; • tpTerm is an IRI and the term type of termMap is not rr:IRI; • tpTerm is a blank node and the term type of termMap is not one of rr:BlankNode, xrr:RdfList, xrr:RdfBag, xrr:RdfSeq, xrr:RdfAlt; • tpTerm is a literal with a language tag L, and the language of termMap is undefined or different from L; • tpTerm is a literal with a datatype T, and the datatype of termMap is either undefined or different from T; • termMap is constant-valued with value V, and tpTerm is different from V; • termMap is template-valued with template string T, and tpTerm cannot match T; • termMap is a ReferencingObjectMap and the subject map of the parent triples map is not compatible with tpTerm, i.
e. ¬compatibleTermMaps(termMap. parentTriplesMap. subjectMap, tpTerm). Definition 5. Compatibility between a term map and a SPARQL filter. Let termMap be an xR2RML term map and f be a SPARQL filter. termMap is compatible with f, denoted as compatibleFilter(termMap, f) if f ="true" or none of the following assertions holds: • a necessary condition of f is isIRI(?var) and the term type of termMap is not rr:IRI; • a necessary condition of f is isLiteral(?var) and the term type of termMap is not rr:Literal; • a necessary condition of f is isBlank(?var) and the term type of termMap is not rr:BlankNode; • a necessary condition of f is lang(?var)="L" or langMatches(lang(?var),"L"), and the language of termMap is either not defined or different from L; • a necessary condition of f is datatype(?var)=<T> and the datatype of termMap is either undefined or different from <T>.
Definition 6. Compatibility between two term maps. Let termMap 1 and termMap 2 be two xR2RML term maps. It holds that termMap 1 and termMap 2 are compatible, denoted by compatibleTermMaps(termMap 1 , termMap 2 ) if none of the following assertions holds: • termMap 1 and termMap 2 have different term types (property rr:termType). • termMap 1 and termMap 2 have different language tags, or one has a language tag and the other does not. • termMap 1 and termMap 2 are both template-valued, and they have incompatible template strings. • termMap 1 (resp. termMap 2 ) is a referencing object map and the subject map of its parent triples maps is not compatible with termMap2 (resp. termMap1), i. e. ¬compatibleTermMaps(termMap 1. parentTriplesMap. subjectMap, termMap 2 ), (resp. ¬compatibleTermMaps(termMap 1 , termMap 2.
Translation of a SPARQL Triple Pattern Below we define the transTP m function and we elaborate on its main concepts. The interested reader is referred to  (Michel et al. , 2015b)  for the comprehensive algorithm transTP m. Definition 7. Function transTP m. Let m be an xR2RML mapping graph consisting of a set of xR2RML triples maps, gp be a well-designed graph pattern, tp be a triple pattern of gp, and f be a SPARQL filter expression. Let getBoundTMs m be the function that, given gp, tp and f, returns the set of triples maps of m that are bound to tp in bind m (gp,f). We denote by transTP m (tp,f) the translation, under getBoundTMs m (gp,tp,f), of "tp FILTER f" into an abstract query whereof results can be translated into RDF triples matching "tp FILTER f". The abstract query generated by function transTP m consists of operators from the abstract query language and atomic abstract queries.
e. returned as part of the query results. An xR2RML reference may be e. g. a column name in a relational database, a JSONPath expression for MongoDB database or an XPath expression for a native XML database. If an xR2RML reference corresponds to a variable of the triple pattern, it is always projected. In our running example, the subject and object of tp 1 are the ?x and ?mbox1 variables. The references in the subject map and object map of triples map <#Mbox> must be projected, hence the Project part for tp 1 : {$. id AS ?x, $. emails. * AS ?mbox1}. Furthermore, the child and parent joined references of a referencing object map must be projected in order to fit databases that do not support joins. In the relational database case, those projected references (columns) are useless since the database can compute the join operation.
Abstract Query Optimization At this point, our method produces abstract queries that are effective, i. e. that preserve the semantics of SPARQL queries. Yet, their structure may show unnecessary complexity, and entail inefficient queries when translated into a target query language. Although query optimizations may be postponed to the final translation step, it is interesting to figure out which ones can be achieved on the abstract representation first, and leave only database-specific optimizations to the latter stage. SPARQL-to-SQL meth-ods proposed various SQL query optimizations  (Unbehauen et al. , 2013b; Rodríguez-Muro and Rezk, 2015; Elliott et al. , 2009) , that are often independent of SQL. Below we review some of these techniques referring to the terminology defined in  (Unbehauen et al.
, 2013b). We show that some of them are implemented in our method by construction, and others apply in the context of our abstract query language. Filter Optimization. In a naive approach, strings generated by R2RML templates are dealt with using an SQL comparison of the resulting strings rather than the database values used in the template. This is notably the case of IRIs that are generally built according to a string template. As a consequence, the query evaluation cannot take advantage of existing indexes and performs poorly. In our approach, equality conditions apply to xR2RML references rather than on the generated IRIs, hence the Filter Optimization is enforced by construction. Filter pushing. As mentioned earlier, the translation of a SPARQL filter into an encapsulating SELECT WHERE clause tends to lower the selectivity of inner queries, and the query evaluation process may have to deal with unnecessarily large intermediate results.
Application to MongoDB MongoDB is a NoSQL database that stores data as JSON documents (more precisely Binary-JSON). Its JavaScript interface defines a declarative query language exemplified in the logical sources of Listing 2. In recent years, MongoDB has become a leader in the NoSQL market, making it an interesting candidate for RDF-based data integration systems, and a potential contributor to the Web of Data. In our running example, we have shown how to translate a SPARQL query into an abstract query, under xR2RML mappings of arbitrary MongoDB documents to RDF. Unlike SQL or XQuery whose expressiveness is similar to that of SPARQL, the expressiveness of the MongoDB query language is far more limited: joins are not supported and filters are supported with strong restrictions (e. g. no comparison between fields of a document).
Conclusion and Perspectives The method proposed in this paper aims at fostering the development of SPARQL interfaces to heterogeneous databases, as we believe this is a key to the advent of the Web of Data. Leveraging R2RML-based SPARQL-to-SQL works, we have defined a method to translate a SPARQL query into a pivot abstract query, utilizing xR2RML to describe the mapping of a target database to RDF. The method determines a reduced set of mappings matching each SPARQL triple pattern, and takes into account join constraints and SPARQL filters. Lastly, several query optimizations are applied to the abstract query in order to facilitate the subsequent translation into the target query language. At this stage, our method has some limitations that we may address in the future. Firstly, SPARQL named graphs and solution modifiers (DISTINCT, OFFSET, LIMIT, ORDER BY, HAVING) are not considered.
Besides, like in most SPARQL rewriting approaches so far, SPARQL 1. 1 is not fully supported, in particular with respect to property paths and negation operators (NOT EXISTS, MINUS). In the translation of a triple pattern, the management of SPARQL filters is postponed to the translation into a target query using the sparqlFilter condition. Yet, further works shall try to raise filters at the abstract query level. For instance SPARQL operators BIND or VALUES may be turned into equivalent equals conditions, and BOUND into isNotNull conditions. Secondly, thanks to the example of MongoDB, we have shown that bridging the gap between the expressiveness of SPARQL and that of the target query language may entail the generation of multiple independent target database queries, delegating several steps to the query processing engine, e.
Firstly, in the con-text of the Zoomathia research project 3 , a taxonomic reference designed to support studies in Conservation Biology was translated into a SKOS 4 thesaurus  (Callou et al. , 2015). The taxonomic reference is stored in a MongoDB database, and the RDF graph is materialized at once. Our perspective is to provide a dynamic access to the SKOS thesaurus using our SPARQL-to-MongoDB prototype. Secondly, we are having discussions with researchers who intend to explore the added value of Semantic Web technologies to support ecology and agronomic studies. They maintain a large MongoDB database of phenotype information about thousands of plants, that they wish to access using SPARQL. This context would be a significant and realistic use case of our method.
Land-cover datasets are crucial for earth system modeling and human-nature interaction research at local, regional and global scales. They can be obtained from remotely sensed data using image classification methods. However, in processes of image classification, spectral values have received considerable attention for most classification methods, while the spectral curve shape has seldom been used because it is difficult to be quantified. This study presents a classification method based on the observation that the spectral curve is composed of segments and certain extreme values. The presented classification method quantifies the spectral curve shape and takes full use of the spectral shape differences among land covers to classify remotely sensed images. Using this method, classification maps from TM (Thematic mapper) data were obtained with an overall accuracy of 0.
TM Data and Processing The satellite imagery used in this research was Landsat 5 TM Level 1T, recorded on 23 September 2006 with path and row of 122 and 41, respectively. The TM sensor has four bands in visible and NIR wavelengths (TM 1: 450-520 nm, TM 2: 520-600 nm, TM 3: 630-690 nm and TM 4: 760-900 nm), two bands in SWIR wavelengths (TM 5: 1550-1570 nm and TM 7: 2080-2350 nm), and one band in the thermal infrared wavelength (TM 6: 10,400-12,500 nm)  [27]. All six reflectance bands (1-5 and 7) have a spatial resolution of 30 m  [27]. The digital numbers (DNs) of bands 1-5 and 7 were converted into at-sensor radiances using the radiometric calibration coefficients obtained from the TM header file. Moreover, an atmospheric correction was performed to calculate surface reflectance from the at-sensor radiances using the FLAASH software.
Solar zenith angle and acquisition time of the TM scene, input into the FLAASH software, were also obtained from the TM header file. Spectral shape-based image classification is a time-consuming process. Therefore, two subset images (labeled as areas A and B) with 512 × 512 pixel size were used as examples for performing spectral shape-based image classification. The geolocations of the two subset images are shown in Figure  1.
Classification Results Applying the developed program on the MATLAB platform, the spectral shape-based classification method was performed to classify the subset images. The classified images for areas A and B are shown in Figures  13  and 14 , respectively. To facilitate interpretation of the results, the corresponding false-color images are also displayed in Figures  13  and 14. A visual comparison of the land cover maps obtained using the presented method with the false-color images shows a good consistency between them. In accordance with the random sample points, the error matrixes (Tables  11  and 12 ) were produced with the overall accuracy and Kappa coefficients of 0. 834 and 0. 677 (see Table  13 ) for Table  11  and 0. 854 and 0. 748 (see Table  13 ) for Table  12 , respectively.
This resulted in 105,697 contigs, which were annotated: most contigs had a best blastx hit to the pea aphid (phylogenetically closest complete genome), while very few bacterial hits were recorded (except for Probionibacterium acnes). Coding sequences were predicted from this data set (17,372 sequences), revealing an extremely high AT-bias (at the third codon position). Differential expression (DE) analysis among root-feeding and gall-feeding showed that i) the root-feeding form displayed a much larger number of differentially expressed transcripts ii) root-feeding biased genes were enriched in some categories, for example cuticular proteins and genes associated with cell-cell signaling iii) leafgalling-biased genes were enriched in genes associated with the nucleus and DNA-replication, suggesting a metabolism more oriented towards fast and active multiplication.
We also identified a gene family with a very high expression level (copies totaling nearly 10 % of the reads) in the grapevine phylloxera (both in root and leaf galling forms), but usually expressed at very low levels in true aphids (except in sexual oviparous females). These transcripts thus appear to be associated with oviparity. Conclusions: Our study illustrated major intraspecific changes in transcriptome profiles, related with different life-styles (and the feeding on roots versus in leaf-galls). At a different scale, we could also illustrate one major shift in expression levels associated with changes in life-traits that occurred along evolution and that respectively characterize (strictly oviparous) grapevine phylloxera and (mostly viviparous) true aphids.
We have explored this interaction for gene families containing copies with the highest level expression and for a gene family showing transcripts with different patterns of morph-biased expression. Grapevine phylloxera is an invasive pest species with worldwide economic importance  [8, 9]. This insect native to North America was accidentally introduced in Europe around 1850  [10] , where it became a pest of cultivated grapevine (Vitis vinifera) which is highly susceptible  [11]. Soon after its unintended introduction, phylloxera caused the collapse of the whole European viticulture and of its economy  [12]. Only after more than 30 years of research, a cure to this plague was found with the grafting of grapevine varieties on rootstocks resistant to the insects  [12] [13] [14]. Phylloxera is still found in almost every wine-producing region of the world  [8].