dataesr/scientific-paragraphs-categorization huggingface dataset:
INTRODUCTION The web of data is now emerging through the publication and interlinking of various open data sets in RDF. Initiatives such as the W3C Data Activity 1 and the Linking Open Data (LOD) project 2 aim at Web-scale data integration and processing, assuming that making heterogenous data available in a common machine-readable format should create opportunities for novel applications and services. Their success largely depends on the ability to reach data from the deep web  (He et al. , 2007) , a part of the web content consisting of documents and databases hardly linked with other data sources and hardly indexed by standard search engines. Furthermore, the integration of heterogeneous data sources is a major challenge in several domains  (Field et al. , 2013). As data semantics is often poorly captured in database schemas, or encoded in application logics, data integration techniques have to capture and expose database semantics in an explicit and machine-readable manner.
The deep web keeps on growing as data is continuously being accumulated in ever more heterogeneous databases. In particular, NoSQL systems have gained a remarkable success during recent years. Driven by major web companies, they have been developed to meet requirements of web 2. 0 services, that relational 1 http://www. w3. org/2013/data/ 2 http://linkeddata. org/ databases (RDB) could not achieve (flexible schema, high throughput, high availability, horizontal elasticity on commodity hardware). Thus, NoSQL systems should be considered as potential big contributors of the linked open data. Other types of databases have been developed over time, either for generic purpose or specific domains, such as XML databases (notably used in edition and digital humanities), objectoriented databases or directory-based databases.
Significant efforts have been invested in the definition of methods to translate various kinds of data sources into RDF. R2RML  (Das et al. , 2012) , for instance, is the W3C recommendation to describe RDBto-RDF mappings. RML extends R2RML for the integration of heterogeneous data formats  (Dimou et al. , 2014a) , but it does not address the constraints that arise when dealing with different types of databases and query languages. In particular, to our knowledge, no method has been proposed yet to tackle NoSQLto-RDF translation. In this paper, we present xR2RML, a mapping language designed as an extension of R2RML and RML. Besides relational databases, xR2RML addresses the mapping of a large and extensible scope of nonrelational databases to RDF. It is designed to flexibly adapt to various data models and query languages.
xR2RML can translate data with mixed formats and generate RDF collections and containers. Our primary focus includes some NoSQL and XML native databases but the approach can equally apply to other types of database such as object-oriented and directory-based databases. In the rest of this section we draw a picture of other works related to the translation of various data sources to RDF, and we scope the objectives of xR2RML. Section 2 explores in more details the capabilities required to reach these goals. In section 3 we summarize the main characteristics of R2RML and RML, and in section 4 we describe xR2RML specific extensions. Section 5 presents a working implementation of the language, finally sections 6 and 7 discuss xR2RML applicability in different contexts and concludes by outlining some perspectives.
, 2011)  and KGRAM-DQP  (Gaignard, 2013). The global data model is expressed by domain ontologies using common languages, e. g. RDFS or OWL. User queries, expressed in terms of the domain ontologies, are written in SPARQL. SPARQL is also used as the wrapper interface. Each data source wrapper is a SPARQL endpoint that performs the schema mapping with the source schema. Our work, as well as most related works listed below, focuses on the mapping step: the rationale is to standardize the schema mapping description, so that a mapping description be written once and applied with different wrapper implementations. RDB-to-RDF mapping has been an active field of research during the last ten years  (Spanos et al. , 2012; Sequeda et al. , 2011; Michel et al. , 2014b). Several mapping methods and languages have been proposed over time, based either on the materialization of RDF data sets or on the SPARQL-based access to relational data.
Published in 2012, R2RML, the W3C RDB-to-RDF mapping language recommendation, has reached a notable consensus 3. 3 http://www. w3. org/2001/sw/rdb2rdf/wiki/Implementations Similarly, various solutions exist to map XML data to RDF. The XSPARQL  (Bischof et al. , 2012)  query language combines XQuery and SPARQL for bidirectional transformations between XML and RDF. Several other solutions are based on the XSLT technology such as XML Scissor-lift  (Fennell, 2014)  that describes mapping rules in Schematron XML validation language, and AstroGrid-D  (Breitling, 2009). SPARQL2XQuery  (Bikakis et al. , 2013)  applies XML Schema to RDF/OWL translation rules. Much work has already been accomplished regarding the translation of CSV, TSV and spreadsheets to RDF. Tools have been developed such as XLWrap  (Langegger and Wöss, 2009)  and RDF Refine 4.
The Linked CSV 5  format is a proposition to embed metadata in a CSV file, that make it easy to link on the Web and eventually to translate to RDF or JSON. However this approach assumes that CSV data be made compliant with the format in the first place, before it can be translated to RDF. The CSV on the Web W3C Working Group 6  , created in 2014, intends to propose a recommendation for the description of and access to CSV data on the Web. In this context, RDF is one of the formats envisaged either to represent metadata about CSV data, or as a format to translate CSV data into. Several tools are designed as frameworks for the integration of sources with heterogeneous data formats. XSPARQL, cited above, provides an R2RMLcompliant extension. Thus it can simultaneously translate relational, XML and RDF data to XML or RDF.
TARQL 7  is a SPARQL-based mapping language that can convert from RDF, CSV/TSV and JSON formats to RDF, but it does not focus on how the data is retrieved from different types of databases. Datalift  (Scharffe et al. , 2012)  provides an integrated set of tools for the publication in RDF of raw structured data (RDB, CSV, XML) and the interlinking of resulting data sets. RML  (Dimou et al. , 2014b; Dimou et al. , 2014a ) is an extension of R2RML that tackles the mapping of data sources with heterogeneous data formats such as CSV/TSV, XML or JSON. Most approaches create links between data sets after they were translated to RDF, e. g. using properties rdfs:seeAlso or owl:sameAs. This is sometimes not adequate as logical resources having different identifiers in different data sets cannot easily be reconciled.
RML creates linked data sets at mapping time by enabling the si-multaneous mapping of multiple data sources, thus allowing for cross-references between resources defined in various data sources. However, RML does not investigate the constraints that arise when dealing with different types of databases. It proposes a solution to reference data elements within query results using expressive languages such as XPath and JSONPath. But it does not clearly distinguish between such languages and the actual query language of a database. In some cases they might be the same, e. g. XPath can be used to query an XML native database, and later on to reference data elements from query results. But in the general case, the query language and the language used to reference elements within query results must be dissociated, e.
Objectives of this Work The works presented in section 1. 1 address various types of data sources. Some of them could be extended to new data sources by developing ad-hoc extensions, although they are generally not designed to easily support new data models and query languages. Only RML comes with this flexibility as its design aims at adapting to new data models. Our goal with xR2RML is to define a generic mapping language able to equally apply to most common relational and non-relational databases. We make a specific focus on NoSQL and XML native databases, and we argue that our work can be generalized to some other types of database, for instance object-oriented and directory (LDAP) databases. In section 2 we explore the capabilities required by xR2RML to reach these goals.
XR2RML LANGUAGE REQUIREMENTS Different kinds of databases typically differ in several aspects: the query language used to retrieve data, the data model that underlies the data structures retrieved and the cross-data referencing scheme, if any. Below we explore in further details the capabilities that we want xR2RML to provide. Query languages. The landscape of modern database systems shows a vast diversity of query languages. Relational databases generally support ANSI SQL, and most native XML databases support XPath and XQuery. By contrast, NoSQL is a catch-all term referring to very diverse systems  (Hecht and Jablonski, 2011; Gajendran, 2013). They have heterogeneous access methods ranging from low-level APIs to expressive query languages. Despite several propositions of common query language (N1QL 8  , UnQL 9  , SQL++  (Ong et al.
, 2014) , ArangoDB QL 10  , CloudMdsQL  (Kolev et al. , 2014) ), no consensus has emerged yet, that would fit most NoSQL databases. Therefore, until a standard eventually arises, xR2RML must be agile enough to cope with various query languages and protocols in a transparent manner. Data models. Similarly to the case of query languages, we observe a large heterogeneity in data models of modern databases. To describe their translation to RDF, a mapping language must be able to reference any data element from their data models. Below we list most common data models, we shortly analyse formats in which data is retrieved and figure out how a mapping language can reference data elements within retrieved data. Relational databases comply with a row-based model in which column names uniquely reference cells in a row.
NoSQL extensible column stores 11  also comply with the row-based model, with the difference that all rows do not necessarily share the same columns. For such systems, referencing data elements is simply achieved using column names. Other non-relational systems, such as XML native databases, NoSQL key-value stores, document stores or graph stores, have heterogeneous data models that can hardly be reduced to a row-based model: -In databases relying on a specific data representation format like JSON (notably in NoSQL document stores) and XML, data is stored and retrieved as documents consisting of tree-like compound values. Referencing data elements within such documents can be achieved thanks to languages such as JSONPath and XPath. -Object-oriented databases conventionally provide methods to serialize objects, typically as key-value associations: keys are attribute names while values are objects (composition or aggregation relationship), or compound values  (collection, map, etc).
Serialization is typically done in XML or JSON, thus here again we can apply XPath or JSONPath expressions. -A directory data model is organised as a tree: each node has an identifier and a set of attributes represented as name=value. Each entry retrieved from an LDAP request is named using an LDAP path expression, e. g. cn=Franck Michel,ou=cnrs,o=fr. Referencing data elements within such entries can be simply achieved using attribute names. -In graph databases, the abstract data model basically consists of nodes and edges. Query capabilities generally allow to retrieve either values matching certain patterns (like the SPARQL SELECT clause), or a set of nodes and edges representing a result graph (like the SPARQL CONSTRUCT clause). Whatever the type of result though, graph databases commonly provide APIs to manipulate query results.
For instance a SPARQL SELECT result set has a row-based format: each row of a result set consists of columns typically named after query variable names. The Neo4J graph database provides a JDBC interface to process a query result, and its REST interface returns result graphs as JSON documents. Thus, although a graph may be a somehow complex data structure, query results can be fairly easy to manipulate using well-known formats: a row-column model, a serialization in JSON or some other representation syntax, etc. Finally, the way a mapping language can reference data elements within query results depends more on the API capabilities than the data model itself. To be effective, xR2RML must transparently accept any type of data element reference expression. This includes a column name (applicable not only to rowbased data models but also to any row-based query result), JSONPath, XPath or LDAP path expressions, etc.
An xR2RML processing engine must be able to evaluate such expressions against query results, but the mapping language itself must remain free from any reference to specific expression syntaxes. Collections. Many data models support the representation of collections: these can be sets, arrays or maps of all kinds (sorted or not sorted, with or without duplicates, etc. ). Although the RDF data model supports such data structures, to the best of our knowledge, existing mapping languages do not allow for the production of RDF collections (rdf:List) nor RDF containers (rdf:Bag, rdf:Seq, rdf:Alt), except TARQL that is able to convert a JSON array into an rdf:List. In all other cases, structured values such as collections or key-value associations are flattened into multiple RDF triples. Listing 1 is an example XML collection consisting of two "movie" elements.
Cross-references. Cross-references are commonly implemented as foreign key constraints in relational data models, or aggregation and composition relationships in object-oriented models. Crossreferencing is even the primary goal of graph-based databases. More generally, it is possible to crossreference logical entities in any type of database. For instance, a JSON document of a NoSQL document store may refer to another document by its identifier or any other field that identifies it uniquely, even if this is generally not recommended for the sake of performances. A cross-referenced logical resource may be mapped alternatively as the subject or the object of triples. This may entail joint queries between tables or documents. Therefore, xR2RML must (i) allow a modular description so that the mapping of a logical resource can be written once and easily reused as a subject or an object, and (ii) allow the description of joint queries to retrieve cross-referenced logical resources.
Summary. Finally, we draw up the list of key capabilities expected from xR2RML as follows: 1. It enables to describe the mapping of various relational and non-relational databases to RDF. 2. It is flexible enough to allow for new databases, query languages and data models in an agile manner: supporting a new system, query language and/or data model only requires changes in the implementation (adaptor, plug-in, etc. ), but no changes are required in the mapping language itself. 3. It enables to generate RDF collections (rdf:List) or containers (rdf:Seq, rdf:Bag, rdf:Alt) from oneto-many relations modelled as compound values or as cross-references. RDF collections and containers can be nested. 4. It enables to perform joint queries following crossreferences between logical resources, and it allows the modular reuse of mapping definitions.
Taken the other way round, data sources to be mapped to RDF using xR2RML need to fulfil some requirements entailed by xR2RML's capabilities: 1. The data source interface should provide a declarative query language. If not, it must be possible to fetch the whole data at once, like a CSV or XML file returned by a Web service. 2. There must exist technical means to parse query results and reference data elements: this ranges from simple column names to expressive languages like XMLPath. 3. In case of large data sets, the database interface should provide ways to iterate on query results, similarly to SQL cursors in RDBs. Notice that the last two requirements are quite natural features of most decent database systems. To help in the design of xR2RML we chose to leverage R2RML, a standard, well-adopted mapping language for relational databases.
R2RML AND RML R2RML is a generic language meant to describe customized mappings that translate data from a relational database into an RDF data set. An R2RML mapping is expressed as an RDF graph written in Turtle syntax 12. An R2RML mapping graph consists of triples maps, each one specifying how to map rows of a logical table to RDF triples. A triples map is composed of exactly one logical table (property rr:logicalTable), one subject map (property rr:subjectMap) and any number of predicate-object maps (property rr:predicateObjectMap). A logi-cal table may be a table, an SQL view (property rr:tableName), or the result of a valid SQL query (property rr:sqlQuery). A predicate-object map consists of predicate maps (property rr:predicateMap) and object maps (property rr:objectMap). For each row of the logical table, the subject map generates a subject IRI, while each predicate-object map creates one or more predicate-object pairs.
THE XR2RML MAPPING LANGUAGE In this section we breifly describe the elements of the xR2RML language. A complete specification is provided in  (Michel et al. , 2014a). We illustrate the descriptions with a running example: Listing 4 shows JSON documents stored in a MongoDB database, in two collections: a "directors" collection with documents on movie directors, and a "movies" collection in which movies are grouped in per-decade documents. Listing 5 shows an xR2RML mapping graph to translate those documents into RDF. Director IRIs are built using director names, while IRIs of resources representing movies use movie codes. We assume the following namespace prefix definitions (the @predfix key word is not displayed for readability):.
Describing A Logical Source To reach its genericity objective, xR2RML must avoid explicitly referring to specific query languages or data models. Keeping this in mind, we define logical sources as a mean to represent a data set from any kind of database. In conformance with R2RML principles, we keep database connection details out of the scope of the mapping language. In RML on the other hand, a logical source points to the data to be mapped typically using a file URL (property rml:source). sible column store, CSV/TSV, etc. ). It refers to a table by its name (property rr:tableName). An xR2RML view represents the result of executing a query against the input database. It has exactly one xrr:query property that extends RML property rml:query (which itself extends rr:sqlQuery 13 ). Its value is a valid expression with regards to the query language supported by the input database.
No assumption is made whatsoever as to the query language used. Reference formulation. Retrieving values from a query result set requires evaluating data element references against the query result, as discussed in section 1. 2. Relational database APIs (such as JDBC drivers) natively support the evaluation of a column name against the current row of a result set. Conversely, some databases come with simple APIs that provide low-level evaluation features. For instance, APIs of most NoSQL document stores return JSON documents but hardly support JSONPath. Therefore, the responsibility of evaluating data element references may fall back on the xR2RML processing engine. To do so, it needs to know which syntax is being used. To this end, RML introduced the reference formulation concept (property rml:referenceFormulation of a logical source) to name the syntax of data element 13 rml:query also subsumes rml:xmlQuery and rml:queryLanguage, although none of those properties are described or exemplified in the RML language specification and articles at the time of writing.
references. As underlined above, xR2RML adheres to R2RML's principle that database-specific details are out of the scope of the mapping language. Moreover, we want the mapping language to remain free from explicit reference to specific syntaxes. As a result, we amend the R2RML processor definition as follows: an xR2RML processor must be provided with a database connection and the reference formulation applicable to results of queries run against the connection. If the reference formulation is not provided, it defaults to column name, in order to ensure backward compatibility with R2RML. Iteration model. In R2RML, the row-based iteration occurs on a set of rows read from a logical table. xR2RML applies this principle to other systems returning row-based result sets: CSV/TSV files, extensible column stores, but also some graph databases as underlined in 1.
2, e. g. a SPARQL SELECT result set is a table in which columns are named after the variables in the SELECT clause. In the context of non row-based result sets, the model is implicitly extended to a document-based iteration model: a document is basically one entry of a result set returned by the database, e. g. a JSON document retrieved from a NoSQL document store, or an XML document retrieved from an XML native database. In the case of data sources whose access interface does not provide built-in iterators, e. g. a web service returning an XML response at once, then a single iteration occurs on the whole retrieved document. Yet, some specific needs may not be fulfilled. For instance, it may be needed to iterate on explicitly specified entries of a JSON document or elements of an XML tree.
To this end, we leverage the concept of iterator introduced in RML. An iterator (property rml:iterator) specifies the iteration pattern to apply to data read from the input database. Its value is a valid expression written using the syntax specified in the reference formulation. The iterator can be either omitted or empty when the reference formulation is a column name. Listing 5 presents two logical source definition examples. Both consist of a MongoDB query (property xrr:query). We assume that the JSONPath reference formulation is provided along with the database connection. In collection "directors" (Listing 4), each document describes exactly one director. By contrast, in collection "movies" each document refers to several movies grouped by decade. To avoid mixing up multiple movies of a single document, an iterator with JSONPath expression $.
Referencing Data Elements In section 3 we have seen that RML properties rml:reference and rr:template both allow data element references expressed according to the reference formulation (column name, XPath, JSONPath). xR2RML uses these RML definitions as a starting point to a broader set of use cases. In real world use cases, databases commonly store values written in a data format that they cannot interpret. For instance, in key-value stores and in most extensible column stores, values are stored as binary objects whose content is opaque to the system. A developer may choose to embed JSON, CSV or XML values in the column of a relational table, for performance issues or due to application design constraints. We call such cases mixed content. xR2RML proposes to apply the principle of data element references defined in RML, and extend it to allow referencing data elements within mixed content.