dataesr/scientific-paragraphs-categorization huggingface dataset:
Such a consensus may emerge only if the selected approaches put little constraints on and require little efforts from those in charge of describing datasets, publishing and maintaining query services thereof. This means relying on existing, well-adopted standards or de-facto standards. In terms of semantic description, existing vocabularies should be leveraged, ranging from mature and widely used W3C standards to de-facto standards such as Schema. org that benefits from a large and growing adoption even though it still lacks terms in many domains. Additionally, selected approaches should enjoy sufficient and appropriate tooling with APIs in various programming languages. Such tools should be relatively simple in the sense that (i) they should not require a long learning curve from developers, and (ii) they should be easy to deploy and maintain.
Together, they provide various metadata, a description of the graphs that the service typically spawns, the service inputs and outputs and the way they relate to one another. An application willing to carry out a certain task first queries search engines (step 2) for datasets matching certain keywords. From the search results, it extracts and looks up SPARQL endpoint URLs. SPARQL micro-services return an SD document that links to the shapes graph. In turn, the application fetches the shapes graph that allows verifying whether the service is indeed suited for the task (step 3). Based on the description of the service inputs, the application can submit an appropriate SPARQL query to the micro-service (step 4). The rest of this article is organized as follows. Section 2 briefly summarizes the concepts of SPARQL micro-services and presents a quick example.
BACKGROUND In  [22] , we described the SPARQL Micro-Service architectural principles. Later on in  [23] , we extended this description and reported on several biodiversity-related use cases. In this section, we briefly summarize these previous works. The SPARQL Micro-Service architecture addresses the problem of combining Linked Data with data from non-RDF Web APIs. A SPARQL micro-service is a lightweight SPARQL endpoint that provides access to a graph generated at run-time. This graph is shaped by the Web API service being wrapped, the arguments passed to the micro-service and the types of RDF triples it is designed to produce. How the arguments are passed to a SPARQL micro-service, and how the Web API response is transformed into a SPARQL result, are implementation choices. In accordance with the micro-service architecture principles  [24] , a SPARQL micro-service is typically designed to be loosely coupled (it is deployed independently of other services, possibly using lightweight container technologies such as Docker  5  ) and fine-grained: it provides access to a small, resource-centric graph corresponding to a small fragment of the whole dataset served by the Web API.
MACHINE-READABLE DESCRIPTION OF SPARQL MICRO-SERVICES Building on the work presented in section 2, we aim at proposing a mechanism that enables a software agent to discover, select and invoke the SPARQL micro-services that are relevant for a certain task. In section 1, we pointed out three principles that, we believe, should help pursue this goal: (1) have rich descriptions of data sources that go beyond common metadata, (2) leverage Web search engines to discover data sources, and (3) rely on well-adopted standards. This section presents the modeling choices we made with respect to principle (1), section 4 deals with principle (2) while principle (3) is transversal to both sections. A rich SPARQL micro-service description should span two distinct levels further detailed in this section. The high-level description consists of metadata about the data being queried (keywords, publisher, license, vocabularies, graphs, etc.
High-level Description To describe SPARQL micro-services, we use SPARQL Service Description (SD)  [33]  which is both a vocabulary to describe SPARQL endpoints and a method requiring compliant endpoints to return an SD document when their URL is looked up. Listing 3 depicts a snippet of the SD document (in the Turtle syntax) for the example service S µf introduced in section 2. The service is at the same time an instance of the SD Service class and the class of SPARQL micro-services sms:Service (line 17). Common metadata are provided lines 19 to 26, such as a name and description, keywords, supported SPARQL language and result formats. A VoID description can also be embedded here, as exemplified in line 29 (the default dataset is stated to be a void:Dataset) and lines 34 to 36 10. Additional triples are not depicted here for conciseness, such as the service publisher and an example SPARQL query.
Note that many more metadata could be provided, such as common dataset profile features  [2]. Furthermore, in the implementation we demonstrate here, we wrote the SD document manually. Future works could consider dataset profiling techniques to (at least partially) automate this generation. The SD document is obtained by looking up the service URL. Content negotiation is supported such that a Web browser will obtain an HTML page, whereas a Linked Data application would typically require one of the supported RDF serialization syntaxes. The SD document itself is a named graph of the dataset served by the SPARQL micro-service (line 31). The interested reader may view the full range of metadata by looking up the named graph URI 11 in a Web browser (this will typically return an RDF/XML representation) or by issuing the following command on a standard Linux system: curl --header " Accept : text / turtle " \ http :// sms.
Functional Description There exist various options to represent the functional description of a service. In section 5 we discuss some of them. As far as SPARQL micro-services are concerned, we choose to leverage several vocabularies for this purpose: SHACL  [16] , Schema. org and Hydra  [19]. SHACL Description of the Dataset. SHACL, the Shapes Constraint Language, is designed for the validation of RDF graphs (called data graphs) against a set of conditions expressed in the form of shapes graphs. In our context, instead of using a shapes graph G sh a posteriori to validate the data graph produced by a 10 As an alternative, a VoID description could be made available using the well-known URIs mechanism, at path /. well-known/void. Listing 3: Snippet of the Service Description of SPARQL micro-service S µf.
SPARQL micro-service, we consider G sh as a specification of the graphs that a SPARQL micro-service can generate. The shapes graph is linked to the SD document as follows: the default dataset has a default graph that is validated by the shapes graph (property shacl:shapesGraph lines 30). The shapes graph is itself one of the named graphs of the default dataset (line 32). A short snippet of the shapes graph corresponding to service S µf is given in Listing 4. The interested reader may check the complete shapes graph on GitHub 12 or by dereferencing its URI 13. It states that an instance of class dwc:Taxon (lines 4-5) should have 12 Complete shapes graph on GitHub: https://frama. link/we_EQWnC 13 Shapes graph URI: http://sms. i3s. unice. fr/sparql-ms/flickr/getPhotosByTaxon_sd/ ShapesGraph exactly three properties: rdf:type with object dwc:Taxon (lines 9-10), shacl:image whose object should be validated against another shape (lines 12-13) and property dwc:scientificName that should have exactly one literal object (lines  [17] [18].
For instance, it would be impossible to define a precise shapes graph of crowd-sourced graphs such as DBpedia. (2) A SHACL shapes graph is itself an RDF graph. Therefore, a software agent can leverage existing tooling to reason upon it and verify whether the SPARQL micro-service fulfills the agent's goals. As an illustration, we are currently developing a SPARQL microservice federated query engine 14. Given an input SPARQL query, the engine searches candidate SPARQL micro-services whose inputs 14 Beta version available at https://frama. link/VWG7r8PF. are satisfied by the query. It then selects those whose shapes graphs validate some triple patterns of the query, and finally rewrites the input query into a UNION of SERVICE clauses that invoke SPARQL micro-services. Each step of the processing (selection, matchmaking, query rewriting) is performed using SPARQL queries that involve the SD documents, the shapes graphs and the input query.
This query is shown in Listing 5. The first member of the UNION clause (lines 4-11) matches the case where arguments are denoted with hydra:property: it retrieves the object of hydra:property (line 8), i. e. dwc:scientificName, and looks for it in the SPARQL query SPIN graph (line 11). By contrast, the second member (lines 15-34) matches the case where arguments are denoted with a property shape. Once the arguments have been extracted, the rest of the SPARQL query evaluation is performed as illustrated in section 2. Implementation. To implement this solution, we deployed Corese  [7] , an in-memory triple store, as the SPARQL engine underlying SPARQL micro-services. Corese implements the SPARQL Template Transformation Language (STTL)  [5]  and comes with a built-in STTL SPARQL-to-SPIN transformation.
For greater flexibility, our implementation allows passing arguments with VALUES or FILTER clauses, which entails a substantially more complicated query than the one depicted in Listing 5. In particular, it leverages the LDScript  [6]  SPARQL extension to define functions able to parse the nested RDF lists entailed by the VALUES clause  15. From a more general perspective, the approach we propose considers the service as a coherent, self-contained, reflexive system where RDF and SPARQL are used internally for the service selfdescription and configuration, at run-time for the query processing, and as the service external interface.
To standardize such markup data, Google, Yahoo, Bing and Yandex support the Schema. org community project that has become a de-facto standard. In particular, Google's recently launched Dataset Search service 16 exploits Schema. org's Dataset term 17 as well as equivalent terms from the DCAT W3C recommendation  [21]. A Schema. org Dataset consists of a set of distributions represented by means of the DataDownload object that, unfortunately, is not suited to depict API resources such as SPARQL endpoints. Ongoing discussions are held within the Schema. org community regarding how to annotate a Dataset with the interfaces that allow access it 18. Until a consensus be eventually adopted, a common workaround implemented by the CKAN data portal 19 is to associate to the DataDownload object the encoding format "api/sparql".
Although semantically questionable ("api/sparql" is not a standard IANA media type 20 ), this practice is a trade-off between the need for valid semantic description and the need for effective Web-scale discovery means. Furthermore, given the popularity of CKAN for hosting data portals, this practice tends to spread out. In the context of SPARQL micro-services, we mitigate this issue with a twofold approach. On the one hand, we comply with the DataDownload + "api/sparql" encoding format practice to ensure maximum discoverability. On the other hand, we embed additional DCAT Dataset and Distribution objects conveying similar information in a more semantically formal manner. Both ways are depicted in Listing 6, lines 24-30 and 38-49 respectively. Results. The combination of standard content negotiation, semantic Web standards and current Linked Data practices fuels a human-friendly documentation and testing interface on one side and a machine-readable Linked Data description on another side.
Furthermore, this combined use pushes "RDF in HTML" descriptions to Web crawlers and indexes in such a way that the described services can be effectively discovered and called by both humans and machines as if they were just another data source. As an illustration, at the time of writing, the example service S µf can be discovered in Google Dataset Search using the keywords "biodiversity" and "photography". Figure  3  shows a snapshot of the result page. Notice that the available download format is appropriately set to SPARQL. Furthermore, adding keyword "sparql" returns the micro-service as the first result in the result page. Implementation. The Web page generation is performed using the technologies already introduced in section 3. 3. An STTL transformation 21 instantiates HTML templates with elements from the SPARQL SD document.
The embedded markup data (exemplified in Listing 6) is generated by a SPARQL CONSTRUCT query whose result is passed to a generic built-in STTL transformation that serializes RDF data in JSON-LD. All these transformations are 16 Google Dataset Search: http://g. co/datasetsearch 17 Schema. org Dataset: https://schema. org/Dataset 18 https://github. com/schemaorg/schemaorg/issues/1423. Accessed Jan. 30th 2019. 19 The CKAN project: https://ckan. org/ 20 IANA media types: https://www. iana. org/assignments/media-types/ 21 The whole transformation code is available at: https://frama. link/hBDkM7ep. 1 { 2 " @context ": [ 3 " http :// schema. org ", 4 { " dcat ": " http :// www. w3. org / ns / dcat #" , 5 " frmt ": " http :// www. w3. org / ns / formats /" } 6 ], 7 8 " @type ": "Dataset", 9 " identifier ": 10 " http :// sms.
Furthermore, LRA describes a Web API by means of a custom vocabulary and relies on a SPARQL graph pattern to serve as a functional description. To spur large adoption, we instead stick to standard vocabularies, and we use SHACL to describe resources as it allows for more expressiveness than a sheer SPARQL graph pattern. RESTdesc  [32]  is a semantic description format for hypermedia APIs. It captures the functional description of APIs in Notation3  [3] , a language extending RDF's data model with variables, existential and universal quantifiers, and logical implications. RESTdesc relies on the HTTP mechanisms and RESTful principles for the discovery and invocation of semantically described Web services. Starting from a known URI, an application can follow its nose by resolving links and making sense of Notation3 service descriptions.
This is an elegant solution that however requires Notation3 reasoners able to interpret the advanced features of quantification and logical implications. Such reasoners exist but are far less common than SPARQL-based implementations available in many programming languages. Since we seek a solution that can be adopted easily by a large community of independent actors, leveraging more common standards such as regular RDF and SPARQL is probably more promising. In line with our idea of leveraging Web search engines to discover relevant datasets and query services, SpEnD  [34]  is a metacrawler designed to discover SPARQL endpoints. It first creates a list of keywords commonly found on Web pages advertising SPARQL endpoints, such as the pages of DataHub. It then looks for these keywords on search engines, explores the result Web pages looking for SPARQL endpoint URLs and looks up these URLs in search for VoID or SPARQL SD documents.
CONCLUSION AND PERSPECTIVES In this article, we address the problem of enabling automatic discovery and consumption of data sources at Web scale. We suggested that three principles should be considered to pursue this goal: (1) provision rich descriptions of data sources and query services, (2) leverage the power of Web search engines to discover data sources, and (3) rely on simple, well-adopted standards that come with extensive tooling. We applied these principles to the concrete case of SPARQL micro-services that aim at querying Web APIs using SPARQL. The proposed solution considers a SPARQL Service Description (SD) document as the description central point. It links to a SHACL shapes graph describing precisely the resources manipulated by the micro-service. It also connects the resources to the micro-service inputs, thereby coming up with a rich functional description that allows a software agent to decide whether this micro-service can help in carrying out a certain task.
To enable accurate discovery using common Web crawlers, the SD document can be dynamically transformed into a Web page embedding rich markup data based on Schema. org's Dataset term and the DCAT vocabulary. From a general perspective, the combination of standard content negotiation, semantic Web standards and Linked Data practices fuels a human-friendly documentation and machine-readable description that make it possible for humans and machines alike to discover and invoke SPARQL micro-services as if they were just another data source. We showed that our approach is effective as our example SPARQL micro-service can be successfully discovered using the Google Dataset Search engine (as illustrated in Figure  3 ). From this point on, a framework such as SpEnD (described in section 6) could be extended to accommodate the invocation of SPARQL micro-services.
Service composition-based query answering systems could fetch the shapes graphs of candidate SPARQL micro-services, check the compatibility of their inputs and outputs with respect to the query to process, and finally compute and enact valid compositions. In particular, SPARQL query federation is a specific type of Web service composition wherein any piece of data in the federated graphs may play the role of either an input or an output. Existing federated query engines could be extended so as to reason on the description of SPARQL micro-services and come up with query plans that respect SPARQL micro-services' input requirements. As pointed out in section 4, denoting a SPARQL endpoint using Schema. org terms is still quite unpractical at the moment. From a more general perspective, describing the multiple interfaces that a client may use to access a dataset is an increasingly pressing need.
The Schema. org community is currently thinking this through with discussions revolving around the Dataset, WebAPI and EntryPoint terms. Concomitantly, the DCAT community is working out the next version of the W3C DCAT recommendation  [11]  that defines the generic concept of DataService meant to serve dataset distributions. The term is flexible enough to accommodate various types of interfaces, providing notably a contract the interface conforms to and an out-of-band description that may typically be a SPARQL SD document in our context. In the current state of our work, SHACL graphs are used as a specification of the graphs that a SPARQL micro-service can generate. We can think of two interesting leads for future works in this respect. Firstly, once a shapes graph is published with its own dereferenceable URI, it can be reused by SPARQL micro-services providers, thereby sparing time and making it possible to share common practices.
A second lead could be to consider SHACL as a way for a client to request responses in a certain shape. This would amount to some sort of extended content negotiation where a client could express that it would prefer a response not only favoring a vocabulary over another, but also describing resources and their relationships according to a certain shape, as much as possible. Finally, whether our approach succeeds in reaching principle (3) (rely on well-adopted standards) is debatable and possibly a matter of perspective and community. Some people contend that Semantic Web standards are not likely to be largely adopted by Web developers  [18]  due to the perceived complexity of RDF and SPARQL, as compared to RESTful APIs for instance. Besides, SHACL is a rich language, yet perhaps too rich to gain large adoption.
Listing 5: Extraction of input argument predicates and values (variables ?predicate and ?value) from a SPARQL query submitted to a SPARQL micro-service. The default dataset contains the SPARQL query SPIN graph, the shapes graph and the SPARQL SD graph. 1 SELECT SELECT SELECT DISTINCT DISTINCT DISTINCT ? name ?predicate ?value 2 WHERE WHERE WHERE { 3 { 4 # Predicate given with hydra : property 5 [] a sd : Service ; 6 dct : source [ schema : potentialAction [ hydra : mapping [ 7 hydra : variable ? name ; 8 hydra:property ?predicate; 9 ]]]. 10 11 [] sp : predicate ?predicate; sp : object ?value. 12 } 13 UNION UNION UNION 14 { 15 # Predicate given through a property shape 16 [] a sd : Service ; 17 dct : source [ schema : potentialAction [ 18 hydra : mapping [ 19 hydra : variable ? name ; 20 shacl : sourceShape ? propShape ; 21 ]]].
Conclusion Based on what has been previously discussed we have concluded the following:  We have a multi-area type, where each area is divided into multi-zones where different regulations are applied to check the compliance of city elements in the zone, e. g. buildings, transportation networks. Which indicates a certain granularity and aggregation for the regulations contained in the PLU. To achieve automated regulatory compliance checking for a construction project, we need to automatically extract requirements from various construction regulation documents and transform these rules into a formalized syntax that enables machine automated reasoning. To reach our goal, we seek to express our set of rules in a language that can be handled and interpreted by a machine. As all considered urban models are converted into ontologies, we aim to transform natural language rule into semantic queries such as SPARQL, as it is the equivalent of SQL for ontologies.
Previous Work Related to BIM/GIS Interoperability and Transforming Textual Regulation into Formal Rules 3. 1 Related Work for BIM/GIS Integration In this section, we are going to introduce previous work addressing BIM/GIS integration/linkage:  [21]  introduces a semantic extension called Urban Information Modelling (UIM), that defines spatial, temporal and multi-representation concepts using extensible ontology. However, the main drawback of this approach persists in the usage of database to store the instances of the ontology. [22]  solves the interoperability between BIM and GIS by applying the following steps: 1) transforming IFC to RDF, 2) transform GIS to RDF, and finally 3) using the GMO (graph matching for ontologies) algorithm to map between the Ontologies. However, the algorithm needs more enhancement as it does not take into count all semantic information.
Research Issue Addressed In This Paper PLU regulations are aggregated on different scale: region, city, district and buildings. This points us toward the need of a multi-scale model that contains necessary information related to each scale. Based on that we have presented before we can conclude that IFC model represents the building scale and CityGML represents the region, city, and district scale. To be able to detect the non-compliant element in an urban, city, district and building scale we need to achieve interoperability between BIM and GIS on a semantic level (based on section 2. 4) and transform the PLU rules into semantic queries such as SPARQL and finally apply the SPARQL queries on BIM and GIS to retrieve the non-compliant elements. In this section we are going to discuss interoperability issues between BIM and GIS, explain how regulations can be adapted into logical rules through logical languages e.
Federated Architecture for OWL Ontologies (FOWLA) Federation approach does not aim to integrate or unify CityGML and IFC models, it only seeks to generate strong and light coupling/connection between the two models. To do so we consider relying on an existing approach: federated architecture for OWL ontologies or FOWLA  [28]. FOWLA is an approach relying on SWRL rules for federating autonomous ontologies (including TBox and ABox). The architecture contains two main components: The Federal Descriptor (FD) and the Federal Controller (FC)  [28]. The first is responsible for identifying missing concept instantiation and identifying new alignments (based on previously defined ones). The latter is mainly responsible for executing SPARQL queries. More specifically, it comes with a Rule Selector module that is responsible for selecting only the subset of SWRL rules that allow returning results pertaining to the considered SPARQL query.