SPARQL 1.1 Entailment Regimes @import url("local.css");
code { font-family: monospace; }
div.constraint, div.issue, div.note, div.notice { margin-left: 2em; }
ol.enumar { list-style-type: decimal; } ol.enumla { list-style-type: lower-alpha; } ol.enumlr { list-style-type: lower-roman; } ol.enumua { list-style-type: upper-alpha; } ol.enumur { list-style-type: upper-roman; }
div.exampleInner pre { margin-left: 1em; margin-top: 0em; margin-bottom: 0em} div.exampleOuter {border: 4px double gray; margin: 0em; padding: 0em} div.exampleInner { background-color: #d5dee3; border-top-width: 4px; border-top-style: double; border-top-color: #d3d3d3; border-bottom-width: 4px; border-bottom-style: double; border-bottom-color: #d3d3d3; padding: 4px; margin: 0em } div.exampleWrapper { margin: 4px } div.exampleHeader { font-weight: bold; margin: 4px}
em.rfc2119 { text-transform: lowercase; font-variant: small-caps; font-style: normal; } This version: http://www.w3.org/TR/2013/REC-sparql11-entailment-20130321/ Latest version: http://www.w3.org/TR/sparql11-entailment/ Previous version: http://www.w3.org/TR/2013/PR-sparql11-entailment-20130129/ Editors: Birte Glimm, Universität Ulm Chimezie Ogbuji, Invited Expert Contributors: Sandro Hawke, W3C Ivan Herman, W3C Bijan Parsia, University of Manchester Axel Polleres, Siemens AG Andy Seaborne, The Apache Software Foundation Please refer to the errata See also translations Copyright W3C ® MIT ERCIM Keio Beihang liability trademark document use SPARQL is a query language and a protocol for data that is stored natively as RDF or viewed as RDF via middleware.
The main mechanism for computing query results in SPARQL is subgraph matching: RDF triples in both the queried RDF data and the query pattern are interpreted as nodes and edges of directed graphs, and the resulting query graph is matched to the data graph using variables as wild cards. Various W3C standards, including RDF OWL entailment regimes May Be Superseded This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index Set of Documents This document is one of eleven SPARQL 1.1 Recommendations produced by the SPARQL Working Group SPARQL 1.1 Overview SPARQL 1.1 Query Language SPARQL 1.1 Update SPARQL1.1 Service Description SPARQL 1.1 Federated Query SPARQL 1.1 Query Results JSON Format SPARQL 1.1 Query Results CSV and TSV Formats SPARQL Query Results XML Format (Second Edition) SPARQL 1.1 Entailment Regimes SPARQL 1.1 Protocol SPARQL 1.1 Graph Store HTTP Protocol No Substantive Changes There have been no substantive changes to this document since the previous version change log color-coded diff Please Send Comments Please send any comments to [email protected] public archive SPARQL Working Group errata [email protected] public archive Endorsed By W3C This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web. Patents This document was produced by a group operating under the 5 February 2004 W3C Patent Policy public list of any patent disclosures Essential Claim(s) section 6 of the W3C Patent Policy 1 Introduction Document Conventions Graph Syntax Namespaces Preliminary Definitions Result Descriptions Effects of Different Entailment Regimes Extensions to Basic Graph Pattern Matching Parts of an Entailment Regime RDF Entailment Regime General Notes on Entailment Regimes (Informative) Blank Nodes in the Queried Graph Answers from Axiomatic Triples Literals in the Subject Position Boolean Queries Aggregates and Blank Nodes RDFS Entailment Regime Inconsistencies (Informative) Effects of Unchecked Inconsistencies D-Entailment Regime The D-Entailment Regime XML Schema Datatypes and Canonical Lexical Representations OWL 2 RDF-Based Semantics Entailment Regime Entailments under the OWL 2 RDF-Based Semantics (Informative) Restriction on Solutions Computing Query Answers under the RDF-Based Semantics (Informative) OWL 2 Profiles and Entailment Checkers OWL 2 DL The OWL 2 EL Profile The OWL 2 QL Profile The OWL 2 RL Profile Computing Query Answers for the OWL 2 RL Profile with RDF-Based Semantics (Informative) OWL 2 Direct Semantics Entailment Regime Introduction OWL Import Directives Extended Grammar for OWL 2 Direct Semantics BGPs Variable Typing The OWL 2 Direct Semantics Entailment Regime Restrictions on Solutions (Informative) BGP Constraints for OWL 2 DL Queries with Variables in Literal Positions Higher-Order Queries (Informative) OWL 2 Entailment Checkers and Profiles RIF Core Entailment (Simple) RIF Core Entailment Regime Custom Rulesets for Common Vocabulary Interpretations (Informative) Finite Answer Set Conditions (Informative) Referencing a RIF Document Semantics of rif:usedWithProfile Dereferencing RIF Documents (Informative) HTTP Dereferencing Encoding RIF documents within named graphs in the dataset Entailment Regimes and Data Sets (Informative) Entailment Regimes and Property Paths (Informative) Limitations of Property Paths in Combination with Entailment Regimes Entailment Regimes and Updates (Informative) A References Normative References Other References Appendix: Mapping from BGPs to the extended OWL 2 Structural Specification Parsing BGPs into Objects of the Extended OWL 2 Structural Specification Appendix: Proofs Change Summary The SPARQL 1.1 Query specification [SPARQL 1.1 Query] simple entailment relation between RDF graphs entailment regimes RDF entailment RDF Schema entailment D-Entailment OWL 2 RDF-Based Semantics entailment OWL 2 Direct Semantics entailment RIF-Simple entailment References to RDF or RDFS entailment rules from the RDF Semantics 1.2 3.1 3.2 4.1 Throughout the document, certain conventions are used, which are outlined below. This document uses the Turtle [TURTLE] _:xxx [] IRIs are written enclosed in < > @prefix @prefix foo: <http://example.org/ns#> . foo: foo:bar <http://example.org/ns#bar> For example, the following triples use prefixes and abbreviated IRIs and also the non-abbreviated IRI <book2> @prefix dc: <http://purl.org/dc/elements/1.1/> . @prefix : <http://example.org/book/> . :book1 dc:title "SPARQL Tutorial" . <book2> dc:title "Turtle Tutorial" . Standard Turtle abbreviations a rdf:type ( ex:a ex:b ) rdf:first rdf:rest rdf:nil [ rdf:first ex:a; rdf:rest [ rdf:first ex:b; rdf:rest rdf:nil ] ] Examples assume the following namespace prefix bindings unless otherwise stated: Prefix IRI rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> rdfs: <http://www.w3.org/2000/01/rdf-schema#> owl: <http://www.w3.org/2002/07/owl#> xsd: <http://www.w3.org/2001/XMLSchema#> rif: <www.w3.org/2007/rif#> In the interests of brevity, the prefix ex: <http://www.example.org/> This document uses the same definitions SPARQL Query Language The term I RDF-L RDF Literals RDF-B blank nodes The set of RDF Terms RDF-T I ∪ RDF-L ∪ RDF-B The set of query variables is denoted as V V RDF-T (RDF-T ∪ V) x (I ∪ V) x (RDF-T ∪ V), A basic graph pattern (BGP) is a set of triple patterns. A pattern instance mapping x P x b x b v x v P x x Result sets are illustrated in tabular form. x y z "Alice" <http://example/a> A 'binding' is a pair ( variable RDF term x y z x "Alice" y <http://example/a> z Sometimes solutions are annotated with the name of a solution mapping so that the explanatory text can refer to the solution mapping and explain or justify certain solutions. For example, in the results table below, the only solution is given by the solution mapping μ 1 x y z μ 1 "Alice" <http://example/a> The SPARQL Query specification already envisages that SPARQL can be used with entailment regimes other than simple entailment. To illustrate the differences between simple, RDF, and RDFS entailment, consider the following data: (1) ex:book1 rdf:type ex:Publication . (2) ex:book2 rdf:type ex:Article . (3) ex:Article rdfs:subClassOf ex:Publication . (4) ex:publishes rdfs:range ex:Publication . (5) ex:MITPress ex:publishes ex:book3 . Figure 1 Consider, for example, the following query: SELECT ?prop WHERE { ?prop rdf:type rdf:Property } Under simple entailment the query has an empty answer when querying the above graph. Under RDF entailment, the RDF rule rdf1 ex:publishes rdf:type rdf:Property ex:publishes ?prop The following query asks for a list of all publications: SELECT ?pub WHERE { ?pub rdf:type ex:Publication } Clearly, ex:book1 ex:book2 ex:book3 ex:book1 ex:book2 ex:book3 ?pub rdf:type ex:Publication ?pub ex:book1 ex:book2 ex:book3 ex:book2 ex:book3 RDFS entailment rules rdfs9 (6) ex:book2 rdf:type ex:Publication . The rule rdfs3 (7) ex:book3 rdf:type ex:Publication . The triples (6) and (7) can then be used to find that ex:book2 ex:book3 OWL 2 Web Ontology Language The SPARQL Query specification [SPARQL 1.1 Query] conditions An entailment regime specifies A subset of RDF graphs called well-formed for the regime An entailment relation between subsets of well-formed graphs and well-formed graphs. Since the OWL 2 Direct Semantics is, for example, only defined for certain well-formed RDF graphs, the first condition can be used to define an OWL 2 Direct Semantics entailment regime only over those RDF graphs that represent an OWL 2 DL ontology. For the entailment relations mentioned in the second condition, this specification uses entailment relations that are already specified and used on the semantic web such as RDF(S) entailment or OWL Direct Semantics entailment. SPARQL Query further defines a set of conditions Section 3.1 scoping graph RDF graph equivalence scoping graph 1 n 1 n SG E-entails (SG ∪ P 1 1 n n MUST SHOULD This specification does not change any of the existing entailment relations, but rather defines the vocabulary from which possible answers can be taken and defines certain conditions which guarantee that query answers are finite for most entailment regimes herein (with the exception of RIF, where finiteness is not always guaranteed, see details below in Section 8.3 All entailment regimes specified here use the same definition of a scoping graph as given for simple entailment Only mappings that, when applied to the BGP, yield a set of RDF triples that are well-formed for E are legal solution mappings and included in the answer. For example, under RDFS entailment, any SPARQL query is legal, but queries that require literals as a binding for a variable in a subject position have no answer because all mappings that result in a set of RDFS entailed triples are not well-formed RDF since RDF forbids literals in the subject position. Similarly, for OWL 2 Direct Semantics entailment, a query might have no answer because all possible bindings might result in RDF triples that are not well-formed for OWL 2 DL This condition prevents the reuse of blank nodes between query answers unless those blank nodes are really the same in the queried graph. Under this restriction no accidental co-references among blank nodes are introduced. All entailment regimes use the same definition of a scoping graph This point is very important since infinite answers are easily possible under all the considered regimes. For example, already under RDF and RDFS entailment, even the empty graph entails an infinite number of axiomatic triples such as rdf:_1 rdf:type rdf:Property rdf:_2 rdf:type rdf:Property { ?x rdf:type rdf:Property . } Name IRI service description sd:defaultEntailmentRegime sd:entailmentRegime Legal Graphs Legal Queries Illegal Handling Entailment Inconsistency Query Answers RDF entailment is closest to simple entailment in that it provides only few additional answers and RDF is not expressive enough to express inconsistencies. RDF does, however, entail an infinite set of axiomatic triples and the entailment regime specifies conditions that address the fourth condition on extensions of basic graph pattern matching. Further explanations are given in the informative sections following the main definition of the regime. Name RDF IRI http://www.w3.org/ns/entailment/RDF Legal Graphs Any legal RDF graph. Legal Queries Any legal SPARQL query. Illegal Handling In case the query is illegal (syntax errors), the system MUST MalformedQuery MUST QueryRequestRefused Entailment RDF Entailment [RDF Semantics] Inconsistency RDF graphs are always RDF consistent and no inconsistency handling is required. Query Answers Let G be the queried RDF graph, BGP be a basic graph pattern, V(BGP) the set of variables in BGP, B(BGP) the set of blank nodes in BGP, SG the scoping graph Skolemization RDF vocabulary rdf:_n n {1, 2, ... } A solution mapping μ is a possible solution for BGP from G under RDF entailment A possible solution μ is a solution for BGP from SG under RDF entailment (C1) The RDF triples sk(P(BGP)) are ground and RDF entailed by sk(SG). (C2) For each variable x in V(BGP), μ(x) occurs in SG or in rdfV-Minus. The multiplicity of μ in the multiset of solutions is the maximal number of distinct RDF instance mappings σ that yield a pattern instance mapping P = (μ, σ) for which μ is a solution. Please note that legal answers under RDF entailment are defined in a two-stage process. Intuitively, the possible answers are all answers that one would expect under RDF entailment, i.e., all mappings such that instantiating the basic graph patterns with them results in RDF triples that are RDF entailed by the queried graph. The set of possible answers is, however, not necessarily finite. The next step defines which of the possible answers are actually returned as answers to the query. In this step, we restrict answers to those that correspond to ground triples that are entailed by the Skolemized scoping graph (C1). This limits infinite answers from blank nodes, while still preserving most users' expectations of the cardinality of the answers. Condition (C2) further makes sure that the query answer contains only finitely many of the axiomatic triples. The two restrictions are further explained in the next section. The entailment regimes defined in this document are all defined analogously to the RDF entailment regime above. This section explains, therefore, the rationale behind the definition and the conditions (C1) and (C2), which are to a large extent shared among all the defined entailment regimes. Possible differences or additional constraints for the following regimes are defined in the respective sections. The third condition for extensions of basic graph pattern matching G: ex:a ex:b _:c . G 1 ex:a ex:b _:b1 . G 2 ex:a ex:b _:b2 . G 3 ex:a ex:b _:b1 . _:d ex:e ex:f . _:b2 ex:e ex:f . _:b1 ex:e ex:f . _:b1 ex:e ex:f . Figure 2 The graph G G 1 G 2 G 3 ex:a ex:b ?x . ?y ex:e ex:f . When taking just the possible answers, without applying condition (C1) and (C2), a solution multiset for BGP would include x y μ 1 _:b1 _:b2 μ 2 _:b2 _:b1 Thus, we have μ 1 G 1 2 G 2 G condition 4 condition 3 G 1 2 G G 3 condition 3 The use of Skolemization in the definition of an entailment regime makes this understanding of blank nodes explicit while still allowing for inferred triples that are not necessarily present in the queried graph. For the above example, condition (C1) works as follows: let skol G G ex:a ex:b skol:c . skol:d ex:e ex:f . The Skolem function maps _:c skol:c _:d skol:d _:c _:d G x _:c y _:d G SG G _:c skol:c _:c Note that (C1) still permits derived solutions. If we assume RDFS entailment G ex:b rdfs:subPropertyOf ex:b' . the BGP ex:a ex:b' ?x . ?y ex:e ex:f . still yields the same one solution. Materialization is a common implementation technique (e.g., for the RDF or RDFS regime) and it is worth pointing out that new blank nodes introduced in the saturation process are not to be returned in the solutions. Consider the following graph and RDFS entailment ex:s ex:p "<a/>"^^rdf:XMLLiteral . If the system were to follow the RDFS inference rules ex:s ex:p _:lit . _:lit rdf:type rdfs:Literal . being added to the graph, where _:lit "<a/>"^^rdf:XMLLiteral ?x rdf:type rdfs:Literal _:lit _:lit x _:lit [RDFSENTAILMENT] The following example mainly illustrates the use of condition (C2). Consider the query SELECT ?x WHERE { ?x rdf:type rdf:Property } against a (scoping) graph containing only the triples ex:a ex:b ex:c . ex:d rdf:type rdf:Bag . ex:d rdf:_1 ex:a . One of the possible solutions is x μ 1 ex:b since ex:a ex:b ex:c ex:b a rdf:Property RDF entailment rule rdf1 x μ 2 rdf:type μ 3 rdf:subject μ 4 rdf:_1 μ 5 rdf:_2 ... There are even more possible answers since ex:b rdf:type rdf:Property _:exb1 rdf:type rdf:Property _:exb1 allocated ex:b _:exb1 (C2) For each variable x in V(BGP), μ(x) occurs in SG or in rdfV-Minus. The possible answers μ 2 5 For the possible solution μ 2 2 rdf:type For the possible solution μ 3 3 rdf:subject For the possible solution μ 4 4 rdf:_1 For the possible solution μ 5 5 rdf:_2 Similar arguments as for rdf:_2 rdf:_n ex:b rdf:_1 X rdf:type rdf:Property X Please note that solution mappings that map variables that occur in the subject position of the basic graph pattern BGP to literals will not be returned as solutions. Indeed, although there might be a pattern instance mapping P for the solution mapping such that P(BGP) is RDF entailed by the queried graph, but P(BGP) is not well-formed as required (see also the SPARQL triple patterns definition SELECT ?x WHERE { ?x rdf:type rdf:XMLLiteral } even the empty graph would RDF entail all statements xxx rdf:type rdf:XMLLiteral for xxx x "<a>abc</a>"^^rdf:XMLLiteral Please note that triples with literals in the subject positions are currently not considered well-formed RDF, but this might change in future versions of RDF The two conditions (C1) and (C2) also have an effect on the answers to Boolean queries. For Boolean queries that contain variables, e.g., ASK { ?x rdf:type rdf:Property } The query answer is yes no ASK { rdf:type rdf:type rdf:Property } against the empty graph. Since rdf:type rdf:type rdf:Property ( ) yes no yes Note that even though rdf:_n n ASK { rdf:_n a rdf:Property } yes rdf:_n SPARQL 1.1 Query allows for aggregates in queries such as COUNT MIN SELECT ?publication (COUNT(?author) AS ?numAuthors) WHERE { ?author ex:writes ?publication . } GROUP BY ?publication evaluated over the data: _:a1 ex:writes ex:book1 . ex:author2 ex:writes ex:book1 . _:a1 ex:writesBook ex:book2 . ex:author3 ex:writesBook ex:book2 . _:a4 ex:writesBook ex:book2 . ex:writesBook rdfs:subPropertyOf ex:writes . Under simple and RDF entailment, basic graph pattern matching finds two solutions: author publication μ 1 _:a1 ex:book1 μ 2 ex:author2 ex:book1 The results are then grouped and aggregated by algebra operators. In this case, there is only one group for ex:book1 COUNT author publication numAuthors ex:book1 2 RDFS further gives semantics to rdfs:subPropertyOf author publication μ 1 _:a1 ex:book1 μ 2 ex:author2 ex:book1 μ 3 _:a1 ex:book2 μ 4 ex:author3 ex:book2 μ 5 _:a4 ex:book2 These solutions are then processed by the algebra operators. Again, the authors for each book (now there are two groups) are counted due to the COUNT author publication numAuthors ex:book1 2 ex:book2 3 Note that the algebra operator just takes the solutions returned by the basic graph pattern matching mechanism. If, for example, blank nodes should not be counted or counted only once, this would mean that in general the entailment regimes must be modified to return no blank nodes or collapse blank nodes in results. A consequence of this would be that, for instance, under a such modified entailment regime for RDF(S) one could get less results than with simple entailment. For example, if no blank nodes were to be returned, then the books would have just one author under non-simple entailment. Under RDFS entailment there are not only more entailments than with just RDF, which result in possibly more query answers, but RDF graphs can also be inconsistent under RDFS interpretations. Without any restrictions, this can result in infinite solutions since an inconsistent graph RDFS entails any consequence. The restrictions to guarantee finite query answers are the same as for RDF and they are repeated here so that the description of the entailment regime is self-contained. Note that, as apposed to the general condition 1 Name RDFS IRI http://www.w3.org/ns/entailment/RDFS Legal Graphs Any legal RDF graph. Legal Queries Any legal SPARQL query. Illegal Handling In case the query is illegal (syntax errors), the system MUST MalformedQuery MUST QueryRequestRefused Entailment RDFS Entailment [RDF Semantics] Inconsistency The scoping graph is graph-equivalent to the active graph even if the active graph is RDFS-inconsistent RDFS-inconsistent MAY QueryRequestRefused SHOULD Query Answers Let G be the queried RDF graph, BGP be a basic graph pattern, V(BGP) the set of variables in BGP, B(BGP) the set of blank nodes in BGP, SG the scoping graph Skolemization RDFS vocabulary rdf:_n n {1, 2, ... } A solution mapping μ is a possible solution for BGP from G under RDFS entailment A possible solution μ is a solution for BGP from SG under RDFS entailment (C1) The RDF triples sk(P(BGP)) are ground and RDFS entailed by sk(SG). (C2) For each variable x in V(BGP), μ(x) occurs in SG or in rdfsV-Minus. The multiplicity of μ in the multiset of solutions is the maximal number of distinct RDF instance mappings σ that yield a pattern instance mapping P = (μ, σ) for which μ is a solution. As under RDF entailment, answers under RDFS entailment are defined in a two-stage process. Possible answers are all answers that one would expect under RDFS entailment, i.e., all mappings such that instantiating the basic graph patterns with them results in RDF triples that are RDFS entailed by the queried graph. To obtain always a finite set of answers, analogous conditions (C1) and (C2) as for the RDF entailment regime are used. An RDFS-inconsistent graph RDFS entails ex:a ex:b "<"^^rdf:XMLLiteral . in combination with a range restriction on the property, e.g., ex:b rdfs:range rdf:XMLLiteral . The first triple alone does not cause an inconsistency. It only requires that the literal "<"^^rdf:XMLLiteral rdfs:Literal rdfs:Literal rdf:XMLLiteral (1) ex:a rdfs:subClassOf rdfs:Literal . (2) ex:b rdfs:range ex:a . (3) ex:c rdfs:subPropertyOf ex:b. (4) ex:d ex:c "<"^^rdf:XMLLiteral . Here we can derive an inconsistency as follows: (5) ex:d ex:b "<"^^rdf:XMLLiteral . (e.g., by applying rule rdfs7 rule rdfs3 rule rdfs9 At this point, the inconsistency can be detected since "<" rdfs:Literal rdfs:Literal Please note that the above definition of the RDFS entailment regimes does not require that systems MUST MAY SHOULD If a system did not raise an error for an inconsistent active graph, it will most likely just return answers that would be answers from a consistent subgraph of the active graph. Since the scoping graph is taken to be equivalent to the active graph irrespective of inconsistencies, a query could still have infinitely many possible answers because an inconsistent graph (trivially) entails any RDF triple. Conditions (C1) and (C2) guarantee, however, finiteness even when a system tries to generate all answers without checking for consistency. In particular condition (C2) restricts query answers such that only answers over the (finite) vocabulary of the queried graph plus the finite subset of the RDFS vocabulary in rdfsV-Minus are returned. The above definition of the RDFS entailment regime is chosen such that it can be implemented efficiently. Consider, for example, a default graph containing the following triples ex:b ex:s ex:y1 . ex:b ex:s ex:y2 . ... ex:b ex:s ex:y10000 . ex:a ex:d "<"^^rdf:XMLLiteral . ex:d rdfs:range rdf:XMLLiteral . and a query SELECT * WHERE { ex:b ex:r ?x . ?x ex:s ?y } which requires a join operation in the query processor. This graph is RDFS-inconsistent due to the last two triples, but the query processor might know (after parsing) that there is no ex:r ex:b ex:s ex:y n Another motivation comes from queries that require a union. For example, the query SELECT * WHERE { {BGP1} UNION {BGP2} } can be executed by dispatching BGP1 and BGP2 in parallel to some processing element, streaming results back to the caller from either side of the UNION as they become available. The use of HTTP for streaming results places some constraints on what can be done, e.g., the error or success code must be transmitted before starting streaming the results. However, discovering the inconsistency from the dispatched processors might be too late for the main processor to communicate the error back to the client in a conformant manner. The D-entailment regime is defined for datatyped interpretations, which give semantics to datatypes. A datatype a non-empty set of character strings called the lexical space of d; a non-empty set called the value space of d; a mapping from the lexical space of d to the value space of d, called the lexical-to-value mapping of d. Datatyped interpretations for an RDF graph are relativized to a datatype map While the datatypes often have a single lexical representation for each data value (i.e., each value in the datatype's value space is denoted by a single representation in its lexical space), this is not always the case. A canonical mapping canonical representation It is possible to define one datatype as a refinement of another one. For example, in the XML Schema Datatypes specification [XML Schema Datatypes] long integer decimal decimal "2"^^xsd:integer "2"^^xsd:long xsd:decimal xsd:integer xsd:long ex:s ex:p "01"^^xsd:long . and a query SELECT * WHERE { ex:s ex:p ?x } The graph D-entails any triple ex:s ex:p "l"^^dt dt l "1.0"^^xsd:decimal "1"^^xsd:integer "1"^^xsd:long The D-entailment regime assumes, therefore, that for each literal there is a well-defined canonical literal. For D a datatype map, a canonical datatype mapping maps each data value v dt dc dc v "l"^^dt "l"^^dt "lc"^^dc lc "l" dc Apart from the datatype support, the entailment regime is a straightforward extension of the RDF and RDFS entailment regimes and the same conditions are used to guarantee the finiteness of the result set, only adapted such that the vocabulary also includes the datatype URIs from the datatype map. Furthermore, all literals in solutions must be the canonical representation of the corresponding data value. The use of D-entailment means that further inconsistencies could arise due to datatype clashes and the same mechanisms as for handling inconsistencies as in the RDFS entailment regime are applied. Name D-Entailment IRI http://www.w3.org/ns/entailment/D Legal Graphs Any legal RDF graph. Legal Queries Any legal SPARQL query. Illegal Handling In case the query is illegal (syntax errors), the system MUST MalformedQuery MUST QueryRequestRefused Entailment D-Entailment [RDF Semantics] Inconsistency The scoping graph is graph-equivalent to the active graph even if the active graph is D-inconsistent D-inconsistent MAY QueryRequestRefused SHOULD Query Answers Systems MUST MUST Let D be the supported datatype map, G the queried RDF graph, BGP be a basic graph pattern, V(BGP) the set of variables in BGP, B(BGP) the set of blank nodes in BGP, SG the scoping graph Skolemization "lc"^^dc "l"^^dt "lc"^^dc "l"^^dt RDFS vocabulary rdf:_n n {1, 2, ... } A solution mapping μ is a possible solution for BGP from G under D-entailment A possible solution μ is a solution for BGP from SG under D-entailment (C1) The RDF triples sk(P(BGP)) are ground and D-entailed by sk(SG). (C2) For each variable x in V(BGP), if μ(x) is a literal with "lc"^^dc "lc"^^dc The multiplicity of μ in the multiset of solutions is the maximal number of distinct RDF instance mappings σ that yield a pattern instance mapping P = (μ, σ) for which μ is a solution. Most XML Schema Datatypes [XML Schema Datatypes] decimal 100.5 +100.5 0100.5 100.50 100.500 100.5000 For the above data values, the canonical lexical form 100 +100 0100 100.0 100.00 100.000 the canonical lexical form XSD 1.1 XSD 1.1 XSD 1.0 XSD 1.0 1.0 1 1.0 XSD 1.0 1 1 1.0 XSD 1.1 Non-primitive datatypes in the XSD are always based on some primitive datatype, e.g., integer, byte, and short are all based on decimal and are obtained by restricting the value space to values without decimal point for integer and by further specifying minimal and maximal values for byte and short. Thus, if "2"^^xsd:integer "+02"^^xsd:short "+2"^^xsd:byte "2"^^xsd:decimal Condition (C2) uses the set Lit(SG) to make sure that only the canonical literals can occur in solutions, which guarantees finiteness of the answers. For example, if the queried graph contains ex:s ex:p "0100.50"^^xsd:decimal . ex:s ex:p "100.00"^^xsd:decimal . ex:s ex:p "+100"^^xsd:short . and the BGP is ex:s ex:p ?x then Lit(SG) contains "100.5"^^xsd:decimal "100"^^xsd:decimal ?x "100.5"^^xsd:decimal "100"^^xsd:decimal ?x "0100"^^xsd:decimal "00100"^^xsd:decimal "100"^^xsd:integer "00100"^^xsd:short Implementations will typically achieve the desired behavior by transforming the lexical forms of data values into a canonicalized form when loading an RDF graph. In contrast to the RDF and RDFS semantics, an RDF graph does no longer admit a unique canonical model that can be used to compute answers under the RDF-Based and Direct Semantics of OWL, i.e., one can no longer imagine queries to act on a unique "completed" version of the active graph. This affects the reasoning algorithms, but has only little effect on the definition of the OWL entailment regimes. The OWL 2 RDF-Based Semantics entailment regime assumes that queries are answered with respect to an OWL 2 RDF-Based datatype map Name OWL 2 RDF-Based Semantics IRI http://www.w3.org/ns/entailment/OWL-RDF-Based Legal Graphs Any legal RDF graph. Legal Queries Any legal SPARQL query. Illegal Handling In case the query is illegal (syntax errors), the system MUST MalformedQuery MUST QueryRequestRefused Entailment OWL 2 RDF-Based Entailment [OWL 2 RDF-Based Semantics] Inconsistency The scoping graph is graph-equivalent to the active graph even if the active graph is OWL 2 RDF-Based inconsistent OWL 2 RDF-Based inconsistent MAY QueryRequestRefused SHOULD Query Answers Systems MUST MUST Let D be a finite OWL 2 RDF-Based datatype map scoping graph Skolemization "lc"^^dc "l"^^dt "lc"^^dc "l"^^dt OWL 2 RDF-based vocabulary datatype names facet names rdf:_n n {1, 2, ... } A solution mapping μ is a possible solution for BGP from G under OWL 2 RDF-Based entailment A possible solution μ is a solution for BGP from SG under OWL 2 RDF-Based entailment with respect owl2V and D (C1) The RDF triples sk(P(BGP)) are ground and OWL 2 RDF-Based entailed by sk(SG) with respect to D. (C2) For each variable x in V(BGP), if μ(x) is a literal, then μ(x) is in Lit(SG) and μ(x) occurs in SG or in owl2V-Minus otherwise. The multiplicity of μ in the multiset of solutions is the maximal number of distinct RDF instance mappings σ that yield a pattern instance mapping P = (μ, σ) for which μ is a solution. The OWL 2 RDF-Based entailment regime is a straightforward extension of the RDF, RDFS, and D-entailment regimes and the same conditions (adapted to work with the a finite subset of the OWL 2 RDF-Based vocabulary) are used to guarantee the finiteness of the result set. Before the restrictions on solutions are explained, a general note about the RDF-Based Semantics is given. The OWL 2 RDF-Based Semantics treats classes as individuals that refer to elements of the domain. Each such element is then associated with a subset of the domain, called the class extension. This means that semantic conditions on class extensions are only applicable to those classes that are actually represented by an element of the domain which can lead to less consequences than expected. An example is given by the following graph G ex:a rdf:type ex:C and basic graph pattern BGP ?x a [ rdf:type owl:Class ; owl:unionOf ( ex:C ex:D ) ] The graph G states that ex:a ex:C ex:C ex:D x ex:a [OWL 2 RDF-Based Semantics] Sec. 7.1 ex:C ex:D ex:E owl:unionOf ( ex:C ex:D ) is added to G. In the OWL 2 Direct Semantics, in contrast, classes denote sets and not domain elements, so G entails μ(BGP) under the Direct Semantics where, formally, G must first be extended with an ontology header to become well-formed. In this section the restrictions on solutions are explained. As the previously defined regimes, a Skolemization of the queried graph and the BGP is used to limit answers that just differ in blank node labels (C1). An explanation for this restriction is given in the General Notes D-entailment ex:x owl:sameAs "5"^^xsd:decimal . A query, which asks for all things that are different to ex:x SELECT ?l WHERE { ex:x owl:differentFrom ?l .} Note that triples which are seemingly unrelated to the query can still influence the query results. For example, if we add to the queried ontology the triple: ex:Mary ex:hasAge "6"^^xsd:int . Then the query no longer has an empty answer but returns one answer with binding "6"^^xsd:int l The standard reasoning problems in OWL under the OWL 2 RDF-Based Semantics are semidecidable, which means that although the query answers are guaranteed to be finite, it cannot be guaranteed that the computation of the query results will finish in a finite amount of time. Guaranteed termination might be achieved by returning an incomplete solution sequence for certain queries. The OWL 2 Profiles specification [OWL 2 Profiles] OWL 2 DL describes the largest subset of RDF graphs for which the OWL 2 Direct Semantics is defined. Systems that support OWL 2 DL can also handle ontologies that satisfy the restrictions of the OWL 2 EL, QL, and RL profiles because these profiles are even more restrictive. OWL 2 EL is particularly useful in applications employing ontologies that contain very large numbers of properties and/or classes. The profile captures the expressive power used by many ontologies and is a subset of OWL 2 DL for which the basic reasoning problems can be performed in time that is polynomial with respect to the size of the ontology. OWL 2 QL is aimed at applications that use very large volumes of instance data, and where query answering is the most important reasoning task. In OWL 2 QL, conjunctive query answering can be implemented using conventional relational database systems. Using a suitable reasoning technique, sound and complete conjunctive query answering can be performed in LOGSPACE with respect to the size of the data (assertions). As in OWL 2 EL, polynomial time algorithms can be used to implement the ontology consistency and class expression subsumption reasoning problems. OWL 2 RL defines a syntactic subset of OWL 2 DL, which is amenable to implementation using rule-based technologies The OWL 2 RDF-Based Semantics can, in general, be used with arbitrary RDF graphs (OWL 2 Full ontologies) and, therefore, with all above described profiles. Taking this into account, the OWL 2 Conformance [OWL 2 Conformance] entailment checkers OWL 2 Full entailment checkers, which take OWL 2 Full ontology documents as input; OWL 2 DL entailment checkers, which takes OWL 2 DL ontology documents as input; OWL 2 EL entailment checkers, which takes OWL 2 EL ontology documents as input; OWL 2 QL entailment checkers, which takes OWL 2 QL ontology documents as input; OWL 2 RL entailment checkers, which takes OWL 2 Full ontology documents as input. The OWL 2 RL entailment checker is slightly different in that OWL 2 RL entailment checkers work, as OWL 2 Full entailment checkers, on OWL 2 Full Ontologies, whereas the others make restrictions on the allowed input. The first four entailment checkers should not return Unknown Unknown True SPARQL 1.1 Service Descriptions sd:defaultEntailmentRegime sd:entailmentRegime sd:defaultSupportedEntailmentProfile sd:supportedEntailmentProfile http://www.w3.org/ns/owl-profile/Full http://www.w3.org/ns/owl-profile/DL http://www.w3.org/ns/owl-profile/EL http://www.w3.org/ns/owl-profile/QL http://www.w3.org/ns/owl-profile/RL The property sd:supportedEntailmentProfile For the OWL 2 RL profile, the OWL 2 RL/RDF rules can be used to compute the answers to a query. In this case, the above definition of query answers can be simplified: Let G be the queried RDF graph, BGP a basic graph pattern, SG the scoping graph for G and BGP, R the OWL 2 RL/RDF rules [OWL 2 Profiles] [OWL 2 Profiles] s p o T(s, p, o) possible solution for BGP from G Condition (C1) does not need to be applied in this case because blank nodes are treated as constants under the first-order semantics anyway. OWL 2 RL implementations are not required to include the axiomatic triples of RDF and RDFS, but they may do so. Thus, in most cases, condition (C2) does not have to be applied. Imposing (C2) does not, however, do any harm and guarantees finiteness should the problematic axiomatic triples be inferred and also guards the behavior on inconsistent ontologies. The fact that (C2) also takes the OWL 2 RDF-Based vocabulary into account means that query answers that use terms not present in the scoping graph may be returned, too. Consider, for example, an ontology containing only the triples: _:o1 rdf:type owl:ontology . ex:C rdf:type owl:Class . ex:D rdf:type owl:Class . ex:C rdfs:subClassOf ex:D . ex:D rdfs:subClassOf ex:C . The first three triples are required for a valid OWL 2 RL ontology and introduce an identifier for the ontology ( _:o1 ex:C ex:D ex:C owl:equivalentClass ex:D OWL RL rule scm-eqc2 owl:equivalentClass SELECT ?rel WHERE { ex:C ?rel ex:D . } has the answers: rel rdfs:subClassOf owl:equivalentClass Intuitively, in the OWL 2 Direct Semantics entailment regime the queried graph must correspond to an OWL 2 DL ontology. The basic graph pattern of the query must correspond to an extended OWL 2 DL ontology, allowing variables in place of class names, object property names, datatype property names, individual names, or literals. Solutions are mappings of variables into IRIs, blank nodes, or literals for which the instantiated basic graph pattern corresponds to a set of OWL 2 DL axioms or an OWL 2 DL ontology that is compatible with the queried ontology and also entailed by it under the OWL 2 Direct Semantics. For the OWL 2 Direct Semantics entailment regime, semantic conditions are defined with respect to ontology structures (i.e., instances of the Ontology [OWL 2 Structural Specification] mapping the queried RDF graph into an OWL 2 ontology [OWL 2 Mapping to RDF Graphs] An OWL 2 DL ontology contains a set of axioms. In this section, OWL axioms are stated both in Turtle and in the functional-style syntax (FSS) that is used in the OWL 2 structural specification [OWL 2 Structural Specification] ex:Peter rdf:type _:x . _:x rdf:type owl:Restriction ; owl:onProperty ex:hasFather ; owl:someValuesFrom ex:Person . corresponds to FSS syntax axiom ClassAssertion(ObjectSomeValuesFrom(ex:hasFather ex:Person) ex:Peter) The FSS may still contain blank nodes, but these correspond to OWL individuals that have no explicit names and are called anonymous individuals ex:Peter ex:hasBrother _:y . corresponds to the FSS axiom ObjectPropertyAssertion(ex:hasBrother ex:Peter _:y) While parsing an input document (containing RDF triples) into an OWL ontology, it can be necessary to rename blank nodes/anonymous individuals and there is no guarantee that the blank node identifier _:y ObjectPropertyAssertion(ex:hasBrother ex:Peter _:somethingelse) Some RDF triples that are well-formed for OWL 2 DL are mapped to OWL 2 DL axioms that carry no semantics. Axioms (triples) that carry no semantics are Annotations, Entity Declarations, Ontology Properties (imports, ontology IRIs). Such axioms are called non-logical axioms logical axioms OWL provides an import directive, which allows one ontology to incorporate axioms from another ontology. Thus, if the queried RDF graph G contains a triple of the form ont owl:imports imported . where ont imported canonical parsing process As said above, an import directive is a non-logical statement under the OWL 2 Direct Semantics, i.e., whether the statement is present in the ontology obtained by the parsing process or not has no effect on the logical consequences of the ontology. The statement does, however, influence the outcome of mapping an RDF graph into an OWL ontology. In the process of mapping a graph G into the ontology structure O(G) the directly and indirectly imported axioms are taken into account. SPARQL 1.1 Query [SPARQL 1.1 Query] Since the OWL 2 Direct Semantics is defined in terms of OWL objects, it is necessary to map from the triple-based BGP representation into an OWL object representation that additionally allows for variables. The appendix [OWL 2 Mapping to RDF Graphs] Class ObjectProperty DataProperty Individual Literal OWL 2 functional-style syntax grammar [OWL 2 Structural Specification] Var SPARQL grammar Class IRI Var ObjectProperty IRI Var DataProperty IRI Var Individual NamedIndividual AnonymousIndividual Var Literal typedLiteral stringLiteralNoLanguage stringLiteralWithLanguage Var The Direct Semantics entailment regime requires extra triples in a basic graph pattern that give typing information for the variables. Let x ?x rdf:type TYPE TYPE owl:Class owl:ObjectProperty owl:DatatypeProperty owl:NamedIndividual ?x TYPE typing constraints SELECT ?s ?p ?o WHERE { ?s ?p ?o } Without any restrictions this query could be a query for object property assertions of the form ObjectPropertyAssertion(?p ?s ?o) data property assertions of the form DataPropertyAssertion(?p ?s ?o) inverse object properties, i.e., the BGP maps to ObjectInverseOf(?o) s p owl:inverseOf subclasses, i.e., the BGP maps to SubClassOf( ?s ?o ) p rdfs:subClassOf equivalent classes, i.e., the BGP maps to EquivalentClasses(?s ?o) p owl:equivalentClass disjoint classes, i.e., the BGP maps to DisjointClasses(?s ?o) p owl:disjointWith ... In order to answer the query without any typing constraints, all possible ways of mapping the BGP into ontology structures have to be considered. Even if variables can only occur in the position of function parameters of the functional-style syntax, the BGP from the above query can still be mapped to ObjectPropertyAssertion(?p ?s ?o) DataPropertyAssertion(?p ?s ?o) AnnotationAssertion(?p ?s ?o) The inclusion of type declarations from the queried ontology means that at least the non-variable terms in the query can be disambiguated without additional typing information in the query. For example, the BGP of the query SELECT ?x WHERE { ?x ex:p ?y } is parsed into ObjectPropertyAssertion(ex:p ?x ?y) if ex:p DataPropertyAssertion(ex:p ?x ?y) if ex:p Note that variable declarations are local to a basic graph pattern, i.e., a declaration in one BGP is not visible within another BGP and, within different BGPs, variables can also be declared to be of different types. Name OWL 2 Direct Semantics IRI http://www.w3.org/ns/entailment/OWL-Direct Legal Graphs Any RDF graph which can be mapped into an OWL 2 DL ontology document Legal Queries Let Q be a legal SPARQL query, BGP a basic graph pattern in Q, G the queried graph, and O(G) the ontology for G. A basic graph pattern is legal for O(G) if it satisfies the typing constraints of the entailment regime and can be mapped extended OWL structural specification Illegal Handling In case the query is illegal due to syntax errors, the system MUST MalformedQuery MUST QueryRequestRefused MAY QueryRequestRefused Entailment OWL 2 Direct Semantics [OWL 2 Direct Semantics] Inconsistency If the queried ontology is inconsistent under OWL 2 Direct Semantics, the system MUST Query Answers Systems MUST MUST Let G be a legal RDF graph for the entailment regime, BGP a legal basic graph pattern, V(BGP) the set of variables in BGP, SG the scoping graph Skolemization "lc"^^dc "l"^^dt "lc"^^dc "l"^^dt Let O E mapping BGP into the extension of the OWL 2 structural specification E E OWL 2 RDF-Based vocabulary datatype names facet names rdf:_n n {1, 2, ... } A solution mapping μ is a possible solution for BGP from G under the OWL 2 Direct Semantics A possible solution μ is a solution for BGP from SG under OWL 2 Direct Semantics (C1) Each logical axiom ax in sk(O E (C2) For each variable x in V(BGP), if μ(x) is a literal, then μ(x) is in Lit(SG) and μ(x) occurs in O(SG) or in owl2V-Minus otherwise. (C3) Adding all axioms in O E The multiplicity of μ in the multiset of solutions is the maximal number of distinct RDF instance mappings σ that yield a pattern instance mapping P = (μ, σ) for which μ is a solution. In this section the restrictions on solutions are explained. As the previously defined regimes, a Skolemization of the queried graph and the BGP is used to limit answers that just differ in blank node labels (C1). An explanation for this restriction is given in the RDF entailment regime Condition (C2) is also applied as in the previously defined regimes and guarantees finite answers. The use of owl2V-Minus is purely for consistency with the other regimes, but could be omitted completely since under the Direct Semantics there are no axiomatic triples and variables can only bind to built-in terms that are also built-in entities. Built-in entities such as owl:Thing Table 5 [OWL 2 Structural Specification] OWL 2 RDF-Based Semantics entailment regime D-entailment regime Condition (C3) requires that the axioms from the instantiated BGP satisfy the restrictions for OWL 2 DL ontologies, i.e., if they where added to the queried ontology, then the resulting ontology satisfies the restrictions of OWL 2 DL. These restrictions are in place to guarantee that the key reasoning tasks in OWL 2 with Direct Semantics are decidable. For example, for owl:topDataProperty following requirement The owl:topDataProperty superDataPropertyExpression SubDataPropertyOf (C3) guarantees that the restrictions that are applied to the queried ontology are equally applied to the query. Since an OWL reasoner for the Direct Semantics might have to work with the axioms in O(SG) and the axioms from O(BGP) simultaneously, this condition also prevents that, for example, a non-simple property from O(SG) is used in a FunctionalObjectProperty axioms or within a cardinality restriction in O(BGP). This would violate the restrictions on non-simple properties. Individuals can be related to a data value although this is not explicitly stated and the actual value might not occur in any axiom of the ontology. Although the example given for the RDF-Based Semantics ex:dp ClassAssertion(DataExactCardinality(2 ex:dp DatatypeRestriction(xsd:int xsd:minExclusive "5"^^xsd:int xsd:maxExclusive "8"^^xsd:int)) ex:Peter) The axiom states that Peter has exactly 2 ex:dp ex:Peter a [ a owl:Restriction ; owl:onProperty ex:dp ; owl:qualifiedCardinality "2"^^xsd:nonNegativeInteger ; owl:onDataRange [ a rdfs:Datatype ; owl:onDatatype xsd:int ; owl:withRestrictions ( [ xsd:minExclusive "5"^^xsd:int ] [ xsd:maxExclusive "8"^^xsd:int ] ) ] ] Under OWL 2 Direct Semantics, an ontology containing the above axiom entails DataPropertyAssertion(ex:dp ex:Peter "6"^^xsd:int) DataPropertyAssertion(ex:dp ex:Peter "7"^^xsd:int) ex:Peter ex:dp "6"^^xsd:int ex:Peter ex:dp "7"^^xsd:int SELECT ?s ?d WHERE { ?s ex:dp ?d } DataPropertyAssertion(ex:dp ?s ?d) This query has an empty answer. Assume now, that the ontology is extended with the assertion: DataPropertyAssertion(ex:dp ex:Mary "6"^^xsd:int) in Turtle: ex:Mary ex:dp "6"^^xsd:int . The same query has now two answers: s d ex:Peter "6"^^xsd:int ex:Mary "6"^^xsd:int Adding an assertion that is not related to the assertion regarding ex:Peter ex:Peter "6"^^xsd:int Since there are infinitely many data values, (C2) has the advantage that a SPARQL endpoint can compute the answers to a query with BGP ex:Peter ex:dp ?x x DataPropertyAssertion(ex:dp ex:Mary "6"^^xsd:int) SHOULD OWL's Direct Semantics is rooted in standard First-Order Logic, but it might seem as if the OWL Direct Semantics entailment regime goes beyond First-Order queries. For example, one can use the BGP ?x rdfs:subClassOf ?y some all SELECT ?x WHERE { ex:Peter rdf:type [ rdf:type owl:Restriction ; owl:onProperty ex:hasBrother ; ?x ex:Person . ] } In functional-style syntax the BGP of the query corresponds to the axiom ClassAssertion( ?x(ex:hasBrother ex:Person) ex:Peter ) Here the variable occurs in the position of a quantifier and not just in the position of OWL entities such as class names or individual names. Due to the restriction that variables can only bind to terms from a finite vocabulary, any query can be reduced to a finite set of Boolean queries that can be answered under OWL's First-Order semantics. For example, the subclass query above can be answered, by asking for all pairs of class names from the queried ontology, whether the instantiated (hence, variable-free) pattern is entailed by the queried ontology under the OWL Direct Semantics. Thus, the SPARQL queries in the entailment regime still have a First-Order semantics. The OWL 2 Direct Semantics is not defined for arbitrary RDF graphs, but only for graphs that satisfy the OWL 2 DL constraints. The OWL 2 profiles further restrict the allowed inputs. As for the RDF-Based Semantics SPARQL 1.1 Service Descriptions entailment checkers sd:defaultEntailmentRegime sd:entailmentRegime sd:defaultSupportedEntailmentProfile sd:supportedEntailmentProfile http://www.w3.org/ns/owl-profile/DL http://www.w3.org/ns/owl-profile/EL http://www.w3.org/ns/owl-profile/QL http://www.w3.org/ns/owl-profile/RL The profile IRI together with the semantics then indicates what kind of entailment checker The RIF RDF Compatibility document [RIF RDF] 8.4 s p o s[p->o] These conditions are enforced on a common RIF-RDF interpretation satisfies model and generalized RDF graphs RIF-Simple-entails [OWL2-RL-RIF] The compatibility document defines 3 additional notions of RIF satisfiability with respect to a combination that builds on simple entailment: RIF-RDF, RIF-RDFS, and RIF-D satisfiability. We define answers with respect to RDF graphs that are RIF-Simple-entailed RIF-Core [RIF Core] Name (Simple) RIF Core Entailment Regime IRI http://www.w3.org/ns/entailment/RIF Legal Graphs RDF graphs containing a triple with rif:usedWithProfile 8.4 Legal Queries Any legal SPARQL query. Illegal Handling In case the query is illegal (syntax errors), the system MUST MalformedQuery MUST QueryRequestRefused Entailment RIF-Simple entailment [RIF RDF] Inconsistency As with the RDF entailment regime, any legal RDF graph (by itself) is satisfiable; no explicit inconsistency handling is required. Query Answers Let G be the merge of the queried RDF graph (without the rif:usedWithProfile scoping graph Skolemization A solution mapping μ is a solution for BGP from G under RIF-Simple entailment RIF-RDF combination rif:usedWithProfile The multiplicity of μ in the multiset of solutions is the maximal number of distinct RDF instance mappings σ that yield a pattern instance mapping P = (μ, σ) for which μ is a solution. For example, consider the Class_Membership presentation syntax (1) ex:Adrian ex:isChildOf ex:Uwe . (2) ex:Adrian rdf:type ex:Male . (3) ex:Uwe rdf:type ex:Male . (4) <Class_Membership_rule.rifps> rif:usedWithProfile <http://www.w3.org/ns/entailment/Simple> . Group ( Forall ?X ?Y ( ?Y [ ex:isFatherOf -> ?X ] :- And( ?X [ ex:isChildOf -> ?Y ] ?Y [ rdf:type -> ex:Male ] ) ) ) The SPARQL query below can be dispatched against the graph using the (Simple) RIF Core Entailment Regime: SELECT ?father ?child WHERE { ?father ex:isFatherOf ?child . } producing the single solution: father child μ 1 ex:Uwe ex:Adrian This follows from the fact that the result of applying a pattern instance mapping comprised of the solution μ 1 RDF vocabulary such as RDFS and OWL 2 RL can be interpreted within this entailment regime through the use of custom rulesets. For example, RDFS entailment can be implemented by using the R RDFS [RIF RDF] [OWL2-RL-RIF] Traditionally, one of the ways to ensure that the underlying decision problems associated with a Horn clause knowledge representation are decidable is to prevent the use of function symbols. RIF-Core's syntax permits built-in functions in the body of a rule. A Horn Clause query is said to be safe it it has a finite set of answers. In order to ensure that a Horn Clause logic programming language is complete (i.e., it guarantees all answers to every query) it is necessary to test whether a given query is safe [SAFETY] Certain safety conditions finite grounding Consider the following strongly safe RIF Core document, scoping graph, and query, for which an answer set can be determined from the unique, minimal, and finite RIF-RDF model of the combination (despite the use of a built-in predicate). In this query, the user asks for all hospital episodes (or visits) and the various health care events they subsume (as indicated by the ex:hasHospitalization ex:hasHospitalization Forall ?x ?y ?z ?u ( ?EVT[ ex:hasHospitalization -> ?HOSP] :- And( ?HOSP # ex:HospitalEncounter ?HOSP [ ex:startsNoEarlierThan -> ?ENCOUNTER_START ex:stopsNoLaterThan -> ?ENCOUNTER_STOP ] ?EVT # ex:HealthCareEvent ?EVT [ ex:startsNoEarlierThan -> ?EVT_START_MIN ] pred:dateTime-greater-than(xsd:dateTime(?EVT_START_MIN) xsd:dateTime(?ENCOUNTER_START)) pred:dateTime-less-than(xsd:dateTime(?EVT_START_MIN) xsd:dateTime(?ENCOUNTER_STOP))) ) (1) <.. path to above document ..> rif:usedWithProfile <http://www.w3.org/ns/entailment/Simple>. (2) ex:Operation1 rdf:type ex:HealthCareEvent; (3) ex:startsNoEarlierThan "2000-12-01T05:00:00"^^xsd:dateTime ; (4) ex:startsNoEarlierThan "2000-12-11T16:31:00"^^xsd:dateTime . (5) ex:Episode1 rdf:type ex:HospitalEncounter; (6) ex:startsNoEarlierThan "2000-11-31T12:00:00"^^xsd:dateTime ; (7) ex:stopsNoEarlierThan "2000-12-26T05:36:00"^^xsd:dateTime . (8) ex:XRay1 rdf:type ex:HealthCareEvent; (9) ex:startsNoEarlierThan "1960-01-10T03:00:00"^^xsd:dateTime ; (10) ex:stopsNoEarlierThan "1960-01-11T07:00:00"^^xsd:dateTime . SELECT ?EVT ?HOSP WHERE { ?EVT ex:hasHospitalization ?HOSP } This should result in the following bindings as a result of the rules and the triples (2)-(7) from a SPARQL service that implements the RIF Core entailment regime: EVT HOSP ex:Operation1 ex:Episode1 RIF RDF and OWL Compatibility [RIF RDF] For the inverse of such a reference, i.e., the import of a RIF document into an RDF graph the designated RDF predicate rif:usedWithProfile In the simple usage the graph G is a plain RDF graph and rif:usedWithProfile rif:usedWithProfile [RIF RDF] The semantics of rif:usedWithProfile rif:usedWithProfile A RIF-aware processor shall treat any RDF graph G [RIF RDF] Let G' G rif:usedWithProfile G R Document ( Imports( R 1 R n P 1 P n where R i P i R i P i and R i R i Remark: G' P 1 P n G' P 1 P n [RIF RDF] Note that this specification does not define how an RDF store refers to or stores the RIF document R i R i HTTP dereferencing Encoding RIF documents within named graphs within the dataset We will sketch both methods in the following. This method assumes that R i R i In some scenarios, one may want to access RIF rulesets from the same RDF store where the queried RDF graphs are stored. This method therefore needs an encoding of RIF documents into an RDF graph, such as for instance the one sketched in [RIF-in-RDF] [RIF-in-RDF] RDF datasets R i R i For instance, assuming that the IRI reference <http://example.org/r1> Document( Prefix(foaf <http://xmlns.com/foaf/0.1/>) Prefix(rel <http://purl.org/vocab/relationship/>)
Group ( Forall ?S ?O ( ?S [ foaf:knows ?O ] :- ?S [ rel:worksWith ?O ] ) ) ) which can be encoded in RDF according to [RIF-in-RDF] @prefix : <http://www.w3.org/2007/rif#> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix rel: <http://purl.org/vocab/relationship/> .
<http://example.org/r1> a :Document; :directives () ; :payload [ rdf:type :Group ; :sentences ( [ rdf:type :Forall; :formula [ a :Implies ; :if [ rdf:type :Frame ; :object [ rdf:type :Var; :varname "S" ] ; :slots ( [ rdf:type :Slot; :slotkey [ rdf:type :Const ; :constIRI "http://purl.org/vocab/relationship/worksWith" ]; :slotvalue [ rdf:type :Var; :varname "O" ] ] ) ]; :then [ rdf:type :Frame ; :object [ rdf:type :Var; :varname "S" ] ; :slots ( [ rdf:type :Slot; :slotkey [ rdf:type :Const ; :constIRI "http://xmlns.com/foaf/0.1/knows" ]; :slotvalue [ rdf:type :Var; :varname "O" ] ] ) ] ] ; :vars ( [rdf:type :Var; :varname "S" ] [ rdf:type :Var; :varname "O" ] ) ] ) ] . Let the dataset consist of the single named graph <http://example.org/r1> @prefix : <http://www.example.org/> . @prefix rel: <http://purl.org/vocab/relationship/> . @prefix rif: <http://www.w3.org/2007/rif#> .
:bob rel:worksWith :alice . <http://example.org/r1> rif:usedWithProfile <http://www.w3.org/ns/entailment/Simple> . then the SPARQL query SELECT * WHERE { ?S ?P ?O } returns S P O :bob foaf:knows :alice :bob rel:worksWith :alice <r1> PREFIX rif: <http://www.example.org/> SELECT DISTINCT ?N WHERE { GRAPH <r1> { [ rif:varname ?N ] } } N "S" "O" Many RDF data stores hold multiple RDF graphs and applications can make queries that involve information from more than one graph. This section clarifies how entailment regimes behave in the presence of named graphs. As defined in the SPARQL specification, a SPARQL query is executed against an RDF Dataset conditions on extensions for basic graph matching For example, we consider a data set which consists of an empty default graph, a named graph graphA with IRI http://example.org/a.rdf http://example.org/b.rdf http://example.org/a.rdf: ex:p rdfs:domain ex:A . http://example.org/b.rdf: ex:x ex:p ex:y . If we ask the following query under RDFS entailment SELECT ?g WHERE { GRAPH ?g { ?inst rdf:type ex:A } } the answer sequence is empty because neither the default graph, nor the named graphs on their own entail a triple that would provide the required binding for ?inst. In order to evaluate a query over the merge of the triples in the named graphs, one can use several FROM SELECT ?inst FROM <http://example.org/a.rdf> FROM <http://example.org/b.rdf> WHERE { ?inst rdf:type ex:A } has the answer { (inst, ex:x) } SPARQL 1.1 introduces property paths ex:a rdf:type ex:C . ex:C rdfs:subClassOf ex:D . ex:a ex:p1 ex:b . ex:b ex:p2 ex:c . ex:p2 rdfs:subPropertyOf ex:p3 . and the following query: SELECT ?type ?c WHERE { ex:a rdf:type ?x . ?x rdfs:subClassOf* ?type . ex:a ex:p1/ex:p3 ?c } The WHERE clause of the above query contains one triple pattern and two property path patterns. For the query processing, the property path patterns are first translated to algebra objects simplified rdfs:subClassOf* ex:p1/ex:p3 ZeroOrMorePath(link(rdfs:subClassOf)) seq(link(ex:p1), link(ex:p3)) Path(?x, ZeroOrMorePath(link(rdfs:subClassOf)), ?type) ex:a ex:p1 ?tmp1 . ?tmp1 ex:p3 ?c . with ?tmp1 Path(.) ZeroOrMorePath(.) evaluation semantics Path(?x, ZeroOrMorePath(link(rdfs:subClassOf)), ?type) x type ex:a ex:a ex:b ex:b ex:c ex:c ex:C ex:C ex:D ex:D ex:C ex:D The evaluation of Bgp(ex:a rdf:type ?x) x ex:C ex:D We can now compute the join to obtain x type ex:C ex:C ex:D ex:D ex:C ex:D Evaluating Bgp(ex:a ex:p1 ?tmp1 . ?tmp1 ex:p3 ?c) tmp1 c ex:b ex:c We can now compute the final result for the query pattern under RDFS entailment by joining the last two solution sets: x type tmp1 c ex:C ex:C ex:b ex:c ex:D ex:D ex:b ex:c ex:C ex:D ex:b ex:c The overall query result can then be obtained by projecting x tmp1 type c ex:C ex:c ex:D ex:c ex:D ex:c In the presence of a particular entailment regime, path expressions are sometimes redundant as their semantics is already captured by the entailment relation. This is often the case when applying path expressions to terms of the special vocabulary for the entailment regime that is used. In the above example, rdfs:subClassOf Bgp(ex:a rdf:type ?x) ex:C ex:D type D ex:a rdf:type ?x . ex:a ex:p1/ex:p3 ?c can be used. This also avoids the computation of several intermediate results. Since property paths are evaluated without entailment, the evaluation under an entailment regime can yield counter-intuitive results. Assuming the use of the RDFS entailment regime and the query SELECT * WHERE { ?s (ex:p3+) ?o } over the above given example data, the result is empty. Although the data contains ex:b ex:p2 ex:c ex:p2 rdfs:subPropertyOf ex:p3 ex:b ex:p3 ex:c ex:p+ Since property path evaluation works directly on the active graph, the OWL Direct Semantics entailment regime is unlikely to support queries where the query pattern contains path expressions since systems that apply the Direct Semantics of OWL do not work with the graph directly, but translate the triples into OWL structural objects. Combining the other entailment regimes with property path expressions is, however, relatively straightforward. Future versions of SPARQL may define further extensions to the handling of property paths together with entailment regimes that handle property paths in a specific way, which is why the present section is kept informative. SPARQL 1.1 also describes an update language (see SPARQL 1.1/Update SPARQL 1.1/HTTP RDF Update OWL 2 Web Ontology Language Conformance OWL 2 Web Ontology Language Direct Semantics OWL 2 Web Ontology Language Mapping to RDF Graphs OWL 2 Web Ontology Language Profiles OWL 2 Web Ontology Language RDF-Based Semantics OWL 2 Web Ontology Language Structural Specification and Functional-Style Syntax Resource Description Framework (RDF): Concepts and Abstract Syntax rdf:PlainLiteral: A Datatype for RDF Plain Literals RDF Semantics RIF Core Dialect (Second Edition) RIF RDF and OWL Compatibility (Second Edition) SPARQL 1.1 Query Language Latest version W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes Answer-Set Programming for the Semantic Web. PhD thesis OWL 2 RL in RIF Completeness, decidability and complexity of entailment for RDF Schema and a semantic extension involving the OWL vocabulary RIF In RDF Safety of recursive Horn clauses with infinite relations Stable models and an alternative logic programming paradigm Turtle: Terse RDF Triple Language Latest version This appendix specifies how a legal basic graph pattern BGP of a SPARQL query can be parsed into the extension of the OWL 2 Structural specification [OWL 2 Structural Specification] x ?x rdf:type TYPE $x rdf:type TYPE TYPE owl:Class owl:ObjectProperty owl:DatatypeProperty owl:NamedIndividual x TYPE typing constraints For the purpose of this parsing process, we assume that BGP is seen as an RDF graph G which may also contain variables in any position. A tool MAY MUST structurally equivalent Objects o 1 o 2 structurally equivalent If o 1 o 2 If o 1 o 2 If o 1 o 2 o 1 o 2 If o 1 o 2 o 1 o 2 If o 1 o 2 both o 1 o 2 each association of o 1 o 2 The following table defines the steps that are involved in the mapping process from basic graph patterns to extended OWL objects. CP 1 If BGP contains no triple of the form x rdf:type owl:Ontology x _:x rdf:type owl:Ontology _:x CP 2 Compute Decl(BGP) as specified in Section 3.1 SG SG CP 3 Create an instance O E Ontology CP 4 Analyze BGP and populate O E MUST A canonical definition for Step CP 4 Parsing BGPs into OWL objects as required in CP 4 Section 3.2 [OWL 2 Mapping to RDF Graphs] *:x or a variable _:x x or a variable lt or a variable xlt or a variable Note that as for the OWL 2 mapping, variations of the above scheme are also taken to be defined as above, e.g., *:y *:x i *:x _:x The functions CE(x) DR(x) OPE(x) DPE(x) Mapping to RDF graphs [OWL 2 Mapping to RDF Graphs] [OWL 2 Mapping to RDF Graphs] If AllDecl(G) ...then perform this assignment. Declaration( Class( *:x ) ) CE(*:x) := a class variable with name *:x Declaration( Datatype( *:x ) ) DR(*:x) := a datatype variable with name *:x Declaration( ObjectProperty( *:x ) ) OPE(*:x) := an object property variable with name *:x Declaration( DataProperty( *:x ) ) DPE(*:x) := a data property variable with name *:x Declaration( AnnotationProperty( *:x ) ) AP(*:x) := an annotation property with name *:x Parsing then continues as described in [OWL 2 Mapping to RDF Graphs] Table 12 *:w i n The SPARQL Query specification [SPARQL 1.1 Query] 1 -- The scoping graph All entailment regimes use the same definition of scoping graph as simple entailment, i.e., the scoping graph is graph-equivalent to the active graph AG of the data set DS for the query but shares no blank nodes with DS or with the basic graph pattern of the query. The same scoping graph is used for all solutions to a single query. Thus, E-equivalence to AG up to RDF graph equivalence is immediate. In case AG is inconsistent, it is not required that a scoping graph is defined and although most of the regimes define SG also in the presence of an inconsistency, it is not required that the above condition is satisfied. 2 -- For any basic graph pattern BGP and pattern instance mapping P, P(BGP) is well-formed for E. BGPs that can only be instantiated into malformed triples, e.g., because they require a literal in the subject position, do not have a valid pattern instance mapping and the condition is satisfied. Only the OWL 2 Direct Semantics regimes restricts the well-formedness of the queried graph and the basic graph patterns further. Since graphs and queries that are malformed for OWL 2 Direct Semantics are rejected with errors and, thus, do not have pattern instance mappings, the condition is satisfied. 3 -- For any scoping graph 1 n 1 n SG E-entails (SG union P 1 1 n n Before giving a proof, the following example illustrates how this condition could be violated. Assume SG contains the triples: ex:s ex:p _:b1 . _:b2 ex:p ex:o ?x ex:p ?y The graph (even simply) entails the triple ex:s ex:p _:1 _:1 ex:p ex:o 1 ex:s _:1 2 _:1 ex:o 1 2 SG E-entails (SG union P 1 1 2 2 { ex:s ex:p _:b1 . _:b2 ex:p ex:o ex:s ex:p _:b1 . _:b2 ex:p ex:o . ex:s ex:p _:1 . _:1 ex:p ex:o This is clearly not the case because SG does not entail ex:s ex:p _:1 . _:1 ex:p ex:o All the entailment regimes satisfy this restriction since blank nodes are treated as Skolem constants, i.e., although both of the triples in the above example are possible 4 -- Each SPARQL extension MUST SHOULD All entailment regimes, but the RIF entailment regime, require that bindings are only taken from a vocabulary defined for the regime. Since the defined vocabularies are finite, it is immediate that any BGP over any AG results in finite answers. The answer set is unique up to RDF graph equivalence since the entailed answers can only vary in their blank node identifiers, which still preserves graph equivalence. For the RIF entailment regime finiteness and uniqueness follows from the safety conditions Changes since Proposed Recommendation Updated RIF references, given publication of RIF Second Edition Changes since Last Call Since last call, the following changes have been made: Since XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes [XML Schema Datatypes] In the informative section "Entailment Regimes and Property Paths", the link to the property path translation in SPARQL Query 1.1 has been fixed and the example has been updated to reflect the new algebra operators that SPARQL 1.1 Query introduced for property path expressions. Since Candidate Recommendation, the only change has been to remove the "At Risk" notes, which labeled sections of the text which might potentially have been removed during Candidate Recommendation (but were not).