SPARQL 1.1 Entailment Regimes

1 Introduction

The SPARQL 1.1 Query specification [SPARQL 1.1 Query] defines the evaluation of a basic graph pattern by means of subgraph matching. This form of basic graph pattern evaluation is also called simple entailment since it can equally be defined in terms of the simple entailment relation between RDF graphs. In order to use more elaborate entailment relations, which also allow for retrieving solutions that implicitly follow from the queried graph, this document defines several entailment regimes. An entailment regime specifies how an entailment relation such as RDF Schema entailment can be used to redefine the evaluation of basic graph patterns from a SPARQL query making use of SPARQL's extension point for basic graph pattern matching. In order to satisfy the conditions that SPARQL places on extensions to basic graph pattern matching, an entailment regimes specifies conditions that limit the number of entailments that contribute solutions for a basic graph pattern. For example, only a finite number of the infinitely many axiomatic triples can contribute solutions under RDF Schema entailment. The entailment relations used in this document are common semantic web entailment relations: RDF entailment, RDF Schema entailment, D-Entailment, OWL 2 RDF-Based Semantics entailment, OWL 2 Direct Semantics entailment, and RIF-Simple entailment.

SPARQL Entailment Regimes is closely related to the following specifications:

The SPARQL 1.1/Query specification, which extends the first SPARQL query language specification.
The SPARQL 1.1/Update specification, which describes an update language for RDF graphs.
The SPARQL 1.1/Protocol specification, which extends the SPARQL Protocol specification.
The SPARQL Query Results XML Format specification defines an XML document format for representing the results of SPARQL SELECT and ASK queries.
The SPARQL 1.1/Service Descriptions, a method for discovering and vocabulary for describing SPARQL services made available via the SPARQL Protocol.
The SPARQL 1.1/HTTP RDF Update specification, which describes a uniform HTTP protocol for managing RDF graphs.

References to RDF or RDFS entailment rules from the RDF Semantics specification are in some places used in an informative way and implementations are not expected to implement these rules as they are used here.

1.1 Document Conventions

Throughout the document, certain conventions are used, which are outlined below.

1.1.1 Graph Syntax

This document uses the Turtle [TURTLE] data format to show triples explicitly. This notation uses a node identifier (nodeID) convention to indicate blank nodes in the triples of a graph. While node identifiers such as _:xxx serve to identify blank nodes in the surface syntax, these expressions are not considered to be the label of the graph node they identify; they are not names, and do not occur in the actual graph. In particular, the RDF graphs described by two Turtle documents which differ only by re-naming their blank node identifiers will be understood to be equivalent. This re-naming convention should be understood as applying only to whole documents, since re-naming the node identifiers in part of a document may result in a document describing a different RDF graph. A generated blank node may also be denoted with [].

IRIs are written enclosed in < and > and may be absolute RDF IRI References or relative to the current base IRI. IRIs may also be abbreviated by using Turtle's @prefix directive that allows declaring a short prefix name for a long prefix of repeated IRIs. Once a prefix such as @prefix foo: <http://example.org/ns#> is defined, any mention of an IRI later in the document may use a qualified name that starts foo: to stand for the longer IRI. For example, the qualified name foo:bar is a shorthand for the IRI <http://example.org/ns#bar>.

For example, the following triples use prefixes and abbreviated IRIs and also the non-abbreviated IRI <book2>, which is relative to the base IRI of the document.

@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 are taken to be expanded into their full form in the queried graph and the query. Since the entailment regimes use the vocabulary of the queried graph to constrain the solutions, this means that, e.g., when a is used in a predicate position it is considered to be expanded to rdf:type before the query is answered. Similarly, abbreviations for lists etc. in the queried graph are considered to be expanded into their full form. E.g., if a Turtle document contains a list of the form ( ex:a ex:b ), it is assumed that vocabulary of the queried graph contains rdf:first, rdf:rest, and rdf:nil because the expanded form of the list is [ rdf:first ex:a; rdf:rest [ rdf:first ex:b; rdf:rest rdf:nil ] ].

1.1.2 Namespaces

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#>`
`fn:`	`<http://www.w3.org/2005/xpath-functions#>`

In the interests of brevity, the prefix ex: is also used in the examples. The prefix is assumed to be bound to an imaginary IRI such as <http://www.example.org/>.

1.1.3 Preliminary Definitions

This document uses the same definitions as the SPARQL Query Language specification. Important terms are recaptured below for clarity. In the case of any differences, the SPARQL Query Language definitions are the normative ones.

The term I denotes the set of all IRIs, RDF-L the set of all RDF Literals, and RDF-B the set of all blank nodes in RDF graphs.

The set of RDF Terms, RDF-T, is I ∪ RDF-L ∪ RDF-B.

The set of query variables is denoted as V and V is assumed to be countable, infinite, and disjoint from RDF-T. A triple pattern is member of the set:

(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 P is the combination of an RDF instance mapping σ and solution mapping μ. For a BGP x, P(x) denotes the result of replacing blank nodes b in x for which σ is defined with σ(b) and all variables v in x for which μ is defined with μ(v), denoted P(x) = μ(σ(x)).

1.1.4 Result Descriptions

Result sets are illustrated in tabular form.

x	y	z
"Alice"	`<http://example/a>`

A 'binding' is a pair (variable, RDF term). In this result set, there are three variables: x, y, and z (shown as column headers). Each solution is shown as one row in the body of the table. Here, there is a single solution, in which variable x is bound to "Alice", variable y is bound to <http://example/a>, and variable z is not bound to an RDF term. Variables are not required to be bound in a solution.

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 μ₁:

	x	y	z
μ₁	"Alice"	`<http://example/a>`

1.2 Effects of Different Entailment Regimes

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 a ex:Publication .
(2) ex:book2 a ex:Article .
(3) ex:Article rdfs:subClassOf ex:Publication .
(4) ex:publishes rdfs:range ex:Publication .
(5) ex:MITPress ex:publishes ex:book3 .

The following query asks for a list of all publications:

SELECT ?pub WHERE { ?pub a ex:Publication }

Clearly, ex:book1 is an answer due to triple (1). Intuitively, we can expect that ex:book2 is also a publication because it is an article (2) and all articles are publications (3). Even ex:book3 is a publication because it is published by MIT Press (5) and everything that is published is a publication (4). Under simple and RDF entailment, ex:book1 is the only answer because a system that uses simple entailment will not perform any of the reasoning steps that were required to find that ex:book2 and ex:book3 are publications. Under simple entailment, the basic graph pattern ?pub a ex:Publication is mapped to the queried graph and variables act as a kind of wild-card, e.g., by mapping ?pub to ex:book1 the BGP matches. RDF already supports a few inferences, but not those that are required to derive that ex:book2 and ex:book3 are publications. In order to retrieve ex:book2 and ex:book3, one would need a system that supports RDFS entailment. RDFS entailment rules can be used to illustrate which new consequences can be derived from the given data. E.g., the rule rdfs9 can be applied to the triples (3) and (2) to derive

(6) ex:book2 a ex:Publication .

The rule rdfs3 can be applied to (4) and (5) to derive

(7) ex:book3 a ex:Publication .

The triples (6) and (7) can then be used to find that ex:book2 and ex:book3 are also answers to the query under an RDFS entailment regime. The difference between RDF and simple entailment is less significant since RDF supports only few inferences. Consider, for example, the following query:

SELECT ?prop WHERE { ?prop a rdf:Property }

Under simple entailment the query has an empty answer when querying the above graph. Under RDF entailment, the RDF rule rdf1 can be used on (5) to derive the triple ex:publishes a rdf:Property which means that ex:publishes is a valid binding for ?prop and will be returned as an answer for the query from a system that uses RDF entailment. The OWL 2 Web Ontology Language allows for even more inferences and the Rule Interchange Format RIF allows for customizing the inferences by specifying custom rule sets. The remainder of this document specifies what correct answers are for the different entailment regimes.

1.3 Extensions to Basic Graph Pattern Matching

The SPARQL Query specification [SPARQL 1.1 Query] gives a set of conditions that have to be met when extending the basic graph pattern matching beyond simple entailment:

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 of 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 for extensions of the basic graph pattern matching. These conditions do not cover the case of inconsistent graphs. The effect of a query on an inconsistent graph has to be covered by the particular entailment regimes. The relevant details for each of the specified entailment regimes can be found in the corresponding section for that entailment regime. The SPARQL Query conditions for consistent active graphs are repeated below for clarity and are followed by an overview of how the different entailment regimes satisfy them.

The scoping graph, SG, corresponding to any consistent active graph AG is uniquely specified up to RDF graph equivalence and is E-equivalent to AG.
For any basic graph pattern BGP and pattern instance mapping P, P(BGP) is well-formed for E.
For any scoping graph SG and answer set {P₁ ... P_n} for a basic graph pattern BGP, and where {BGP₁ .... BGP_n} is a set of basic graph patterns all equivalent to BGP, none of which share any blank nodes with any other or with SG
SG E-entails (SG ∪ P₁(BGP₁) ∪ ... ∪ P_n(BGP_n))
These conditions do not fully determine the set of possible answers, since RDF allows unlimited amounts of redundancy. In addition, therefore, the following must hold.
Each SPARQL extension MUST provide conditions on answer sets which guarantee that the set of triples obtained by instantiating BGP with each solution μ is uniquely specified up to RDF graph equivalence, and SHOULD provide further conditions to prevent trivial infinite answers as appropriate to the regime.

This specification does not change any of the existing entailment relations, but rather defines the vocabulary from which possible answers can be taken and which answers are legal answers in order to guarantee that query answers are always finite. The set of legal graphs, i.e., graphs that can be queried, is also unrestricted apart from the restriction to graphs that are legal under the entailment regime in question. E.g., under the RDFS entailment regime, one can query all legal RDF graphs, while under OWL 2 Direct Semantics, one can query all graphs that correspond to legal OWL 2 DL ontologies. Further, it is defined which queries are legal and how illegal queries, illegal graphs, and inconsistencies are handled. All defined entailment regimes satisfy the above conditions as follows:

All entailment regimes specified here use the same definition of a scoping graph as given for simple entailment. Thus, the required equivalence is immediate.
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 DL 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 as simple entailment. The condition is satisfied since a form of Skolemization is used to restrict the answers containing blank nodes.
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 a rdf:Property, rdf:_2 a rdf:Property, ... Thus, a query with BGP { ?x a rdf:Property . } would, without further restrictions, have infinitely many answers. Such answers are to be understood as trivial infinite answers. Other sources of trivial infinite answers are answers that only differ in blank node labels. In order to exclude such sources of infinity, the entailment regimes will define a (finite) vocabulary from which bindings can be taken. These restrictions are explained in greater detail in the following sections.

1.4 Parts of an Entailment Regime

Each entailment regime is defined in a table describing the following items:

Name: A name for the entailment regime, usually the same as the entailment relation used to define the evaluation of a basic graph pattern.
IRI: The IRI for the regime, which can be used in the service description of a SPARQL endpoint.
Legal Graphs: Describes which graphs are legal for the regime.
Legal Queries: Describes which queries are legal for the regime.
Illegal handling: Describes what happens in case of an illegal graph or query.
Entailment: Specifies which entailment relation is used in the evaluation of basic graph patterns.
Inconsistency: Defines what happens if the queried graph is inconsistent under the used semantics.
Query Answers: Defines how a basic graph pattern is evaluated, i.e., what the solutions are for a given graph and basic graph pattern of a query.

2 RDF Entailment Regime

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 forth condition on extensions of basic graph pattern matching. Further explanation 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 raise a MalformedQuery fault. In case the queried graph is illegal (syntax errors), the system MUST raise a QueryRequestRefused fault.
Entailment	RDF Entailment
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 for G and BGP, sk(SG) a Skolemization of SG with respect to a vocabulary disjoint from the vocabulary of SG and BGP. Applying sk to a term t, written sk(t), yields sk(t) if sk is defined for t and t otherwise; applying sk to a BGP, written sk(BGP), replaces each blank node b in BGP for which sk is defined with sk(b). The term rdfV refers to the RDF vocabulary and rdfV-Minus is the set of URI references in rdfV minus URI references of the form `rdf:_n` with `n` in `{1, 2, ... }`. A solution mapping μ is a possible solution for BGP from G under RDF entailment if dom(μ) = V(BGP) and there is an RDF instance mapping σ from B(BGP) to RDF-T such that dom(σ)=B(BGP) and the pattern instance mapping P=(μ, σ) is such that P(BGP) are well-formed RDF triples that are RDF entailed by SG. A possible solution μ is a solution for BGP from SG under RDF entailment if: (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 below.

2.1 Blank Nodes in the Queried Graph (Informative)

The third condition for extensions of basic graph pattern matching requires that if blank node names are returned as bindings for a variable, then the same blank node name occurs in different solutions only if it corresponds to the same blank node in the graph. To illustrate why this is required, consider the following graphs:

G:	ex:a ex:b _:c .	G₁:	ex:a ex:b _:b1 .	G₂:	ex:a ex:b _:b2 .	G₃:	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 .

The graph G simply entails G₁ and G₂, but not G₃ where the two blank nodes are identified. Now consider a basic graph pattern BGP:

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
μ₁	_:b1	_:b2
μ₂	_:b2	_:b1

Thus, we have μ₁(BGP)=G₁ and μ₂(BGP)=G₂, and both solutions are entailed by G. In fact, the set of possible solutions is clearly infinite in this case, which is problematic with respect to condition 4 from the SPARQL Query specification since the use of different blank node labels is considered a trivial source of infinite answers. Furthermore, condition 3 requires that G ∪ μ₁(BGP) ∪ μ₂(BGP) is also entailed by G, and this is not the case in the example since this union contains G₃. The reason is that the solutions have unintended co-references of blank nodes that condition 3 does not allow. SPARQL’s basic subgraph matching semantics respects these conditions by requiring solution mappings to refer to blank nodes that actually occur in the active graph, which essentially treats blank nodes as (Skolem) constants.

Intuitively, Skolemization changes blank nodes into resource identifiers that are not affected by entailment. Clearly, the Skolemized blank nodes should not occur in query results, but Skolemization can be used to restrict solution mappings μ for which sk(G) entails sk(μ(BGP)) (C1), i.e, the use of Skolemization is made explicit so that it can also be applied to triples not explicitly present in the input graph. In order to apply (C1) to the above example, let skol be a prefix that denotes a fresh IRI not occurring in G and let sk(G) be the following (Skolemized) graph:

ex:a ex:b skol:c .
skol:d ex:e ex:f .

The Skolem function maps _:c to skol:c and _:d to skol:d. In order to satisfy (C1), the only blank nodes that can be used in the range of μ are _:c and _:d, since other blank nodes will either cause sk(μ(BGP)) to be non-ground since sk is not defined for the blank nodes or they might be Skolemized to terms not occurring in G, leading to non-entailed triples sk(μ(BGP)). Furthermore, we can only use a solution mapping that maps ?x to _:c and ?y to _:d because otherwise the entailment does not hold. Note that (C1) still permits derived solutions, e.g., for the same graph G and the BGP ?x a rdf:Property, we would get ex:b among other solutions using RDF entailment.

In fact, we could have directly used a Skolemized version of the scoping graph to define the answers under RDF entailment. Since the Skolemized scoping graph sk(SG) is, however, not RDF-equivalent to SG, this violates the first condition that the SPARQL Query specification places on extensions of the basic graph pattern matching.

2.2 Answers from Axiomatic Triples (Informative)

The following example mainly illustrates the use of condition (C2). Consider the query

SELECT ?x WHERE { ?x a rdf:Property }

against a (scoping) graph containing only the triples

ex:a ex:b ex:c . 
ex:d a rdf:Bag .
ex:d rdf:_1 ex:a .

One of the possible solutions is

	x
μ₁	ex:b

since ex:a ex:b ex:c RDF entails ex:b a rdf:Property (see also the RDF entailment rule rdf1). Further, the axiomatic triples give possible solutions such as

	x
μ₂	rdf:type
μ₃	rdf:subject
μ₄	rdf:_1
μ₅	rdf:_2
	...

There are even more possible answers since ex:b a rdf:Property RDF entails _:exb1 a rdf:Property for some blank node _:exb1 allocated to ex:b, i.e., _:exb1 is a possible solution. As shown above, condition (C1) prevents such possible solutions from newly introduced blank nodes to be returned as solutions. To limit the answers from the axiomatic triples condition (C2) is used:

(C2) For each variable x in V(BGP), sk(μ(x)) occurs in sk(SG) or in rdfV-Minus.

The possible answers μ₂ to μ₅ are considered here in greater detail. Since all these solution mappings lead to (ground) axiomatic triples when instantiating the BGP, (C1) is trivially satisfied. Since the queried graph contains no blank nodes, sk(SG) = SG and sk(μ_i(?x)) = μ_i(?x) for any solution mapping μ_i, which is used to simplify the checking of (C2) below.

For the possible solution μ₂, take an empty RDF instance mapping σ₂ to obtain a pattern instance mapping P₂=(μ₂, σ₂) with P₂(BGP) = rdf:type a rdf:Property. Since μ₂(?x)=rdf:type occurs in SG (and also in rdfV-Minus), condition (C2) is also satisfied and this solution mapping is a solution.
For the possible solution μ₃: take again an empty RDF instance mapping σ₃ to obtain a pattern instance mapping P₃=(μ₃, σ₃) with P₃(BGP) = rdf:subject a rdf:Property. Although μ₃(?x)=rdf:subject does not occur in SG, it occurs in rdfV-Minus and this possible solution mapping is, therefore, also returned as an answer.
For the possible solution μ₄: take again an empty RDF instance mapping σ₄ to obtain a pattern instance mapping P₄=(μ₄, σ₄) with P₄(BGP) = rdf:_1 a rdf:Property. Since μ₄(?x)=rdf:_1 occurs in SG, this is a solution.
For the possible solution μ₅: take again an empty RDF instance mapping σ₅ to obtain a pattern instance mapping P₅=(μ₅, σ₅) with P₅(BGP) = rdf:_2 a rdf:Property. Since μ₅(?x)=rdf:_2 occurs neither in SG nor in rdfV-Minus, this solution mapping is not a solution.

Similar arguments as for rdf:_2 can be used for rdf:_n with n > 2. Thus the query answer contains ex:b, rdf:_1, and the subjects of RDF axiomatic triples of the form X rdf:type rdf:Property with X in rdfV-Minus.

Editorial note 21 Sep 2010

The Working Group is particularly interested in feedback from implementors regarding the treatmeant of axiomatic triples with subjects of the form rdf:_1, rdf:_2, ...

Condition (C2) could also be changed such that terms of the form rdf:_n cannot be used as bindings at all:

(C2') For each variable x in V(BGP), μ(x) in (SG ∪ rdfV) \ {rdf:_n | n is a natural number }.

Currently a BGP ?x a rdf:Property would yield rdf:_1 as solution over the graph with triple ex:a ex:b rdf:_1 because _:1 occurs in SG and the triple is an axiomatic triple, but, for n > 1, rdf:_n is not a solution. Under the modified condition not even rdf:_1 would be a solution and even the BGP ex:a ex:b ?x . would have an empty solution. The modified condition might, however, be easier to implement since rules to materialize entailments do not depend on the input graph.

2.3 Literals in the Subject Position (Informative)

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). E.g., given a query

SELECT ?x WHERE { ?x a rdf:XMLLiteral }

even the empty graph would RDF entail all statements

xxx a rdf:XMLLiteral

for xxx a well-formed RDF XML literal, but any solution that maps x to an XML literal such as "<a>abc</a>"^^rdf:XMLLiteral would result in a triple that is not a valid RDF triple.

Please note that triples with literals in the subject positions are currently not considered well-formed RDF, but this might be changed in the future. If literals were allowed in the subject position, condition (C2) would still guarantee finite answers.

2.4 Boolean Queries (Informative)

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 a rdf:Property }

The query answer is yes (true) if there is at least one solution mapping (i.e., a solution that satisfies also conditions (C1) and (C2)) and it is no (false) otherwise. For example, if the queried graph is the empty graph, the query pattern has four solution triples from rdfV-Minus and hence the answer is true. For Boolean queries without variables the situation is slightly different. Consider, for example, the query

ASK { rdf:type a rdf:Property }

against the empty graph. Since rdf:type a rdf:Property is an axiomatic triple, even the empty graph RDF entails the triple. We have two possible outcomes for such a Boolean query: there is a solution sequence containing a mapping ( μ ) where μ has an empty domain (it does not map any variable to anything) or there is only an empty solution sequence ( ). In the first case, the query answer is yes (true), whereas in the second case the query answer is no (false). Since (C2) only operates on the variables in the query, only (C1) is relevant in this case. Since neither the BGP nor the queried (empty) graph contains a blank node, also (C1) holds and the query answer is yes (true).

Note that even though rdf:_n is not in rdfV-Minus for any n, this means that queries such as ASK { rdf:_n a rdf:Property } will always be answered with yes (true) even if rdf:_n does not occur in the scoping graph.

3 RDFS Entailment Regime

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 answer sets 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. The definition of the scoping graph is, however, extended to also cover the case when the queried graph is RDFS-inconsistent.

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 raise a MalformedQuery fault. In case the queried graph is illegal (syntax errors), the system MUST raise a QueryRequestRefused fault.
Entailment	RDFS Entailment
Inconsistency	The scoping graph is graph-equivalent to the active graph even if the active graph is RDFS-inconsistent. If the active graph is RDFS-inconsistent, an implementation MAY raise a QueryRequestRefused fault or issue a warning and it SHOULD generate such a fault or warning if, in the course of processing, it determines that the data or query is not compatible with the request. In the presence of an inconsistency the conditions on solutions still guarantee that answers are finite.
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 for G and BGP, sk(SG) a Skolemization of SG with respect to a vocabulary disjoint from the vocabulary of SG and BGP. Applying sk to a term t, written sk(t), yields sk(t) if sk is defined for t and t otherwise; applying sk to a BGP, written sk(BGP), replaces each blank node b in BGP for which sk is defined with sk(b). The term rdfsV refers to the RDFS vocabulary and rdfsV-Minus is the set of URI references in rdfsV minus URI references of the form `rdf:_n` with `n` in `{1, 2, ... }`. A solution mapping μ is a possible solution for BGP from G under RDFS entailment if dom(μ) = V(BGP) and there is an RDF instance mapping σ from B(BGP) to RDF-T such that dom(σ)=B(BGP) and the pattern instance mapping P=(μ, σ) is such that P(BGP) are well-formed RDF triples that are RDFS entailed by SG. A possible solution μ is a solution for BGP from SG under RDFS entailment if: (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 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, the same conditions (C1) and (C2) as for the RDF entailment regime are used.

3.1 Inconsistencies (Informative)

An RDFS-inconsistent graph RDFS entails any graph, but there are limited possibilities to express an inconsistency in RDFS. Every inconsistency is due to a literal of type rdf:XMLLiteral, where the lexical form is a malformed XML string, e.g.,

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 is interpreted as something that is not in the extension of rdfs:Literal. Since rdfs:Literal contains rdf:XMLLiteral, the second triple together with the first one results in an inconsistency. The following example illustrates that an inconsistency is not always as directly visible as in the example above and one might need to apply some inference rules to detect it. E.g., consider the following triples (numbers are only given to explain the inferences later):

(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 to derive the inconsistency as follows:

(5) ex:d ex:b "<"^^rdf:XMLLiteral .    (e.g., by applying rule rdfs7 to (3) and (4))
(6) "<"^^rdf:XMLLiteral a ex:a.   (e.g., by applying rule rdfs3 to (2) and (5))
(7) "<"^^rdf:XMLLiteral rdf:type rdfs:Literal .   (e.g., by applying rule rdfs9 to (1) and (6))

At this point, the inconsistency can be detected since "<" is not a valid lexical form for an RDF XML literal and has to be interpreted as some element that is NOT in rdfs:Literal, but at the same time it should be of type rdfs:Literal. The triple derived last is characteristic for an RDFS inconsistency.

3.1.1 Effects of Unchecked Inconsistencies

Please note that the above definition of the RDFS entailment regimes does not require that systems MUST generate an error or a warning in the case of an inconsistency, but systems MAY generate an error or warning. A system SHOULD generate such an error or warning if, in the course of processing, it determines that the data or query is not compatible with the request.

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 sub-graph 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 property at all in the graph. Thus, the processor knows that it does not have to evaluate the query. However, if a consistency check was required, the processor would have to parse and process the query nevertheless and return an error. Such a test could be very costly (there could be more than 10,000 ex:b ex:s ex:y_n tuples).

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.

3.2 Aggregates and Blank Nodes (Informative)

SPARQL 1.1 Query allows for aggregates in queries such as COUNT, MIN, etc. Aggregates apply expressions over groups of solutions, e.g., by counting the number of solutions. Thus, aggregation is layered on top of basic graph pattern matching and all solutions computed for the basic graph pattern of the query and the entailment regime in use are passed on to the algebra functions. For the RDF (and RDFS) entailment regime this means that since blank nodes are treated as Skolem constants due to condition (C1), each blank node contributes one value for the aggregates. Assume, for example, the query

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
μ₁	_:a1	ex:book1
μ₂	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 and the authors for the group are counted due to the COUNT aggregate over ?author resulting in the query answer:

publication	numAuthors
ex:book1	2

RDFS further gives semantics to rdfs:subPropertyOf and the basic graph pattern matching under RDFS entailment finds five solution mappings:

	author	publication
μ₁	_:a1	ex:book1
μ₂	ex:author2	ex:book1
μ₃	_:a1	ex:book2
μ₄	ex:author3	ex:book2
μ₅	_: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 aggregate over ?author, which leads to the following result for the query under RDFS entailment:

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 under entailment regimes such as RDF(S) one could get less results than with simple entailment. E.g., if no blank nodes were to be returned, then the books would have just one author under non-simple entailment.

4 D-Entailment Regime

The D-entailment regime assumes that queries are answered with respect to a (finite) datatype map D. 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. 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 raise a MalformedQuery fault. In case the queried graph is illegal (syntax errors), the system MUST raise a QueryRequestRefused fault.
Entailment	D-Entailment
Inconsistency	The scoping graph is graph-equivalent to the active graph even if the active graph is D-inconsistent. If the active graph is D-inconsistent with respect to the datatype map D, an implementation MAY raise a QueryRequestRefused fault or issue a warning and it SHOULD generate such a fault or warning if, in the course of processing, it determines that the data or query is not compatible with the request. In the presence of an inconsistency the conditions on solutions still guarantee that answers are finite.
Query Answers	Let D be a finite 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 for G and BGP, sk(SG) a Skolemization of SG with respect to a vocabulary disjoint from the vocabulary of SG and BGP. Applying sk to a term t, written sk(t), yields sk(t) if sk is defined for t and t otherwise; applying sk to a BGP, written sk(BGP), replaces each blank node b in BGP for which sk is defined with sk(b). The term dV refers to the RDFS vocabulary plus the datatype names, i.e., the URI references, for the datatypes in D; dV-Minus is the set of URI references in dV minus URI references of the form `rdf:_n` with `n` in `{1, 2, ... }`. A solution mapping μ is a possible solution for BGP from G under D-entailment if dom(μ) = V(BGP) and there is an RDF instance mapping σ from B(BGP) to RDF-T such that dom(σ)=B(BGP) and the pattern instance mapping P=(μ, σ) is such that P(BGP) are well-formed RDF triples that are D-entailed by SG. A possible solution μ is a solution for BGP from SG under D-entailment if: (C1) The RDF triples sk(P(BGP)) are ground and D-entailed by sk(SG). (C2) For each variable x in V(BGP), μ(x) occurs in SG or in dV-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.

4.1 Canonical Lexical Representations (Informative)

Depending on the datatype map D, it can happen that a datatype from D allows for infinitely many lexical forms that denote the same data value. E.g., if D includes the decimal datatype from the XML Schema Datatypes [XSD], then all of the following lexical forms represent the same value:

100
+100.0
0100.0
100.0
100.00
100.000

SPARQL queries are answered with respect to a graph and any triple serialization format such as RDF/XML or Turtle has to be parsed into a graph representation. During this parsing process systems may or may not transform the lexical forms of data values into a canonicalized form. E.g., for the above data value, the canonical lexical form is: 100.0.

Whether or not a parser performs canonicalization can have an effect on query answers. Consider the query

SELECT ?x WHERE { ex:s ex:p ?x }

over the graph obtained from the triples

ex:s ex:p "100.0"ˆˆxsd:decimal .
ex:s ex:p "100.00"ˆˆxsd:decimal .

If the parsing process involves canonicalization, then the obtained graph will contain just two nodes (one for ex:s and one for the data value 100.0) connected by one edge (for ex:p), whereas without canonicalization, the graph contains one extra node for 100.00 and an extra edge connecting the node for ex:s with the node for the data value 100.00. In the first case, the query has one answer, whereas in the second case, the query has two answers.

Whether or not canonicalization takes place depends on the parsing process, which is not part of this specification. Thus, the answers of systems that use the D-Entailment regimes can vary according to how parsing is implemented and canonicalization during parsing is encouraged in order to obtain more intuitive answers.

5 OWL 2 RDF-Based Semantics Entailment Regime

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 D.

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 raise a MalformedQuery fault. In case the queried graph is illegal (syntax errors), the system MUST raise a QueryRequestRefused fault.
Entailment	OWL 2 RDF-Based Entailment
Inconsistency	The scoping graph is graph-equivalent to the active graph even if the active graph is OWL 2 RDF-Based inconsistent. If the active graph is OWL 2 RDF-Based inconsistent with respect to D, an implementation MAY raise a QueryRequestRefused fault or issue a warning and it SHOULD generate such a fault or warning if, in the course of processing, it determines that the data or query is not compatible with the request. In the presence of an inconsistency the conditions on solutions still guarantee that answers are finite.
Query Answers	Let D be a finite OWL 2 RDF-Based 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 for G and BGP, sk(SG) a Skolemization of SG with respect to a vocabulary disjoint from the vocabulary of SG and BGP. Applying sk to a term t, written sk(t), yields sk(t) if sk is defined for t and t otherwise; applying sk to a BGP, written sk(BGP), replaces each blank node b in BGP for which sk is defined with sk(b). The term owl2V refers to the OWL 2 RDF-based vocabulary, which is taken to include the RDF and RDFS vocabularies and the OWL 2 datatype names and facet names; owl2V-Minus is the set of URI references in owl2V minus URI references of the form `rdf:_n` with `n` in `{1, 2, ... }`. A solution mapping μ is a possible solution for BGP from G under OWL 2 RDF-Based entailment if dom(μ) = V(BGP) and there is an RDF instance mapping σ from B(BGP) to RDF-T such that dom(σ)=B(BGP) and the pattern instance mapping P=(μ, σ) is such that P(BGP) are well-formed RDF triples that are OWL 2 RDF-Based entailed by SG with respect to owl2V and D. A possible solution μ is a solution for BGP from SG under OWL 2 RDF-Based entailment with respect owl2V and D if: (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), μ(x) occurs in sk(SG) or in owl2V-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.

The OWL 2 RDF-Based entailment regime is a straightforward extension of the RDF and RDFS 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.

5.1 Entailments under the OWL 2 RDF-Based Semantics (Informative)

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 a ex:C

and basic graph pattern BGP

?x a [ a owl:Class ; owl:unionOf ( ex:C ex:D ) ]

The graph G states that ex:a has type ex:C, while the BGP asks for instances of the complex class denoting the union of ex:C and ex:D. One might expect that a solution mapping μ that maps ?x to ex:a is a solution, but this is not the case under the OWL 2 RDF-Based Semantics (see also [OWL 2 RDF-Based Semantics], Sec. 7.1). It is guaranteed that the union of the class extensions for ex:C and ex:D exists as a subset of the domain; no statement in G implies, however, that this union is the class extension of any domain element. Thus, μ(BGP) is not entailed by G. The entailment holds, however, when the statement

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.

5.2 Restriction on Solutions

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 section. Under OWL 2 RDF-Based Semantics the axiomatic triples are not included and owl2V-Minus could equally be replaced by owl2V. Without (C2), infinite answers can, however, easily occur due to the powerful OWL 2 datatype reasoning. Since the datatype literals are not part of the vocabulary owl2V-Minus, only the values explicitly present in the queried ontology have to be considered, which again guarantees finite answers. Consider, for example, an ontology containing an axiom that states that all the data values to which Peter is related with the property ex:dp are in the singleton set containing the integer 5:

ex:Peter a [
    a owl:Restriction ;
    owl:onProperty ex:dp ;
    owl:allValuesFrom [
      a rdfs:Datatype ;
      owl:oneOf ("5"^^xsd:integer) 
    ]
]

A query, which asks for all data values to which ex:Peter cannot be related with the ex:dp property, has infinitely many possible answers since any literal different from 5 will satisfy these constraints. This can be formulated by the following query:

SELECT ?x WHERE { 
    ex:Peter a [
      a owl:Restriction ;
      owl:onProperty ex:dp ;
      owl:allValuesFrom [
        a rdfs:Datatype ;
        owl:datatypeComplementOf [
          a rdfs:Datatype ; 
          owl:oneOf (?x)
      ]
    ]
  ]
}

Editorial note 21 Sep 2010

It could be the case that this example only applies to the OWL 2 Direct Semantics and that for the RDF-Based Semantics one would have to introduce axioms that force a domain element to exist for each extension of the class expression obtained by substituting ?x with a literal different from 5. Since G must be finite, one can only have finitely many such axioms and, consequently, the answers are always finite.

Note that a similar query for data ranges instead of literals has a finite answer even without (C2). E.g., if the same ontology is queried with:

SELECT ?x WHERE { 
    ex:Peter a [
      a owl:Restriction ;
      owl:onProperty ex:dp ;
      owl:allValuesFrom [
        a rdfs:Datatype ;
        owl:datatypeComplementOf ?x .
    ]
  ]
}

The answer to this query consists of all datatypes of the datatype map that are disjoint from xsd:integer, e.g., xsd:string, xsd:double, etc. Note that complex data ranges, which are derived from datatypes by applying facet restrictions to them, are not valid bindings. E.g., the data range

[
  a rdfs:Datatype ;
  owl:onDatatype xsd:double ;
  owl:withRestrictions (
    [ xsd:minExclusive "0.2"^^xsd:double ]
    [ xsd:maxExclusive "0.8"^^xsd:double ]
  )
]

cannot be used as a binding for the variable ?x

With (C2), only the literals and datatypes that occur in the queried graph can be used as bindings. In order to drop (C2), one would have to precisely characterize which queries can cause infinite answers, e.g, by analyzing which variables bind to literals and occur under negation. Such queries could then be excluded. Condition (C2) is, however, easier to understand and it is easy to see that it achieves finiteness.

5.3 Computing Query Answers under the RDF-Based Semantics (Informative)

The standard reasoning problems in OWL under the OWL 2 RDF-Based Semantics are undecidable, 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.

5.4 The OWL 2 RL Profile

OWL 2 RL defines a syntactic subset of OWL 2, which is amenable to implementation using rule-based technologies. The OWL 2 RL specification presents a partial axiomatization of the OWL 2 RDF-Based Semantics in the form of first-order implications for this purpose. For RDF graphs that can be mapped into OWL 2 RL ontologies, a suitable rule-based implementation has desirable computational properties. For RDF graphs that cannot be mapped into an OWL 2 RL ontology, the proposed rule set can still be used to compute query answers, but the result set might not contain all query answers that are entailed under the RDF-Based Semantics.

Endpoints that implement the OWL 2 RL profile can use the URI http://www.w3.org/ns/owl-profile/RL to describe this in their service description.

If the input ontology satisfies certain restrictions, the rules can also be used to compute all and only the answers that are entailed under the OWL 2 Direct Semantics. Thus, OWL 2 RL can also be used with the Direct Semantics of OWL 2.

5.4.1 Computing Query Answers for the OWL 2 RL Profile with RDF-Based Semantics (Informative)

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], and FO(SG) the translation of SG into a first-order theory according to the OWL 2 Profiles specification [OWL 2 Profiles], i.e., each triple s p o in SG is represented by a predicate T(s, p, o) in FO(SG). Let P=(μ, σ) a pattern instance mapping. The solution mapping μ is a possible solution for BGP from G if dom(μ) = V(BGP), dom(σ)=B(BGP) and FO(SG) union R entails FO(P(BGP)) under the standard first-order semantics.

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 a owl:ontology .
ex:C a owl:Class . 
ex:D a 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) and typing information (ex:C and ex:D are classes). The ontology entails ex:C owl:equivalentClass ex:D and the OWL RL rule scm-eqc2 derives this consequence from the ontology. Since owl:equivalentClass is in owl2V-Minus, the query

SELECT ?rel WHERE { ex:C ?rel ex:D . }

has the answers:

rel
rdfs:subClassOf
owl:equivalentClass

6 OWL 2 Direct Semantics Entailment Regime

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.

6.1 Introduction

For the OWL 2 Direct Semantics entailment regime, semantic conditions are defined with respect to ontology structures (i.e., instances of the Ontology class as defined in the OWL 2 structural specification [OWL 2 Structural Specification]). Given an RDF graph G, the ontology structure for G, denoted O(G), is obtained by mapping the queried RDF graph into an OWL 2 ontology [OWL 2 Mapping to RDF Graphs]. This mapping is only defined for OWL 2 DL ontologies, i.e., ontologies that satisfy certain syntactic conditions.

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]. A FSS axiom can correspond to several RDF triples, and the RDF triples might contain auxiliary blank nodes that are not part of the corresponding OWL objects and are not visible in the corresponding FSS axiom. E.g., the triples

ex:Peter a _:x . 
_:x a 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. For example, the triple

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 from the above triple is used as an identifier for Peter's brother in the ontology structure. Thus, the above RDF triple could also be represented by the OWL axiom

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, whereas axioms that do carry semantics under OWL 2 Direct Semantics are called logical axioms.

6.1.1 OWL Import Directives

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 is the ontology IRI or a blank node that identifies the ontology, and imported is the IRI of the imported ontology, then the canonical parsing process defined for OWL 2 ontologies makes sure that the axioms from directly and indirectly imported ontologies are taken into account.

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.

6.1.2 Extended Grammar for OWL 2 Direct Semantics BGPs

SPARQL 1.1 Query [SPARQL 1.1 Query] is only defined for basic graph patterns using a triple-based syntax. For OWL 2 Direct Semantics, an alternative syntax for BGPs based on the functional-style syntax or other popular OWL syntaxes seems natural, but is not part of this specification.

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 precisely specifies how the OWL 2 mapping from RDF graphs [OWL 2 Mapping to RDF Graphs] can be extended to basic graph patterns. The result of this mapping is an instance of an extended OWL 2 DL grammar, where the productions for Class, ObjectProperty, DataProperty, Individual, and Literal of the OWL 2 functional-style syntax grammar [OWL 2 Structural Specification] are extended to alternatively produce variables, i.e., instances of the Var production from the SPARQL grammar.

6.1.3 Variable Typing

The Direct Semantics entailment regime requires extra triples in a basic graph pattern that give typing information for the variables. Let ?x be a variable from BGP. If BGP contains a triple ?x rdf:type TYPE, where TYPE is one of owl:Class, owl:ObjectProperty, owl:DatatypeProperty, or owl:NamedIndividual, ?x is declared to be of type TYPE. BGP satisfies the typing constraints of the entailment regime if no variable is declared as being of more than one type. Without type declarations for variables, parsing a BGP into ontology structures would be very difficult. Consider the following query

SELECT ?s ?p ?o WHERE { ?s ?p ?o }

Without any restrictions this query could be a query for

declarations, i.e., the BGP maps to a declaration such as Declaration(Class(?s)) where ?p binds to rdf:type, ?o to owl:Class, and bindings for ?s have to be computed or Declaration(ObjectProperty(?s)) where ?p binds to rdf:type and ?o to owl:ObjectProperty, or any other type of declaration,
inverse object properties, i.e., the BGP maps to ObjectInverseOf(?o) where ?s maps to a blank node and ?p to owl:inverseOf,
subclasses, i.e., the BGP maps to SubClassOf( ?s ?o ) where ?p binds to rdfs:subClassOf,
equivalent classes, i.e., the BGP maps to EquivalentClasses(?s ?o) where ?p binds to owl:equivalentClass,
disjoint classes, i.e., the BGP maps to DisjointClasses(?s ?o) where ?p binds to 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), or AnnotationAssertion(?p ?s ?o) without variable typing information.

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. E.g., the BGP of the query

SELECT ?x WHERE { ?x ex:p ?y }

is parsed into

ObjectPropertyAssertion(ex:p ?x ?y)

if ex:p is declared as an object property in the queried ontology and into

DataPropertyAssertion(ex:p ?x ?y)

if ex:p is declared as a data property.

6.2 The OWL 2 Direct Semantics Entailment Regime

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 into an OWL ontology or a set of OWL axioms from the extended OWL structural specification using the declarations from O(G). The query Q is legal for the regime and O(G) if all basic graph patterns in Q are legal for O(G).
Illegal handling	In case the query is illegal due to syntax errors, the system MUST raise a MalformedQuery fault. In case the queried graph is illegal due to syntax errors, the system MUST raise a QueryRequestRefused fault. If the queried ontology is not an OWL 2 DL ontology or the query is not legal for the ontology, the system MAY refuse the query and raise a QueryRequestRefused error or the system MAY use only a subset of the triples in the ontology or query.
Entailment	OWL 2 Direct Semantics
Inconsistency	If the queried ontology is inconsistent under OWL 2 Direct Semantics, the system MUST raise an error.
Query Answers	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 for G and BGP, O(SG) the ontology for SG, sk a total mapping from anonymous individuals in O(SG) to IRIs from a vocabulary disjoint from the vocabulary of O(SG) and BGP, sk(O(SG)) the resulting Skolemization of O(SG). Applying sk to a term t, written sk(t), yields sk(t) if sk is defined for t and t otherwise; applying sk to a BGP, written sk(BGP), replaces each blank node b in BGP for which sk is defined with sk(b). Let O_E(BGP) be the ontology obtained by mapping BGP into the extension of the OWL 2 structural specification. Let Ax be a function that takes an ontology O from the extended structural specification and returns all axioms in O. Let Ax(BGP) be the axioms in O_E(BGP), and AI(BGP) the set of anonymous individuals in O_E(BGP). The term owl2V refers to the OWL 2 RDF-based vocabulary, which is taken to include the RDF and RDFS vocabularies and the OWL 2 datatype names and facet names; owl2V-Minus is the set of URI references in owl2V minus URI references of the form `rdf:_n` with `n` in `{1, 2, ... }`. A solution mapping μ is a possible solution for BGP from G under the OWL 2 Direct Semantics if dom(μ) = V(BGP) and there is an RDF instance mapping σ from AI(BGP) to RDF-T such that dom(σ)=AI(BGP) and the pattern instance mapping P=(μ, σ) is such that P(BGP) are well-formed RDF triples that are legal for the regime (i.e., P(BGP) is a variable-free and legal basic graph pattern for O(SG)) and OWL 2 Direct Semantics entailed by O(SG). A possible solution μ is a solution for BGP from SG under OWL 2 Direct Semantics if: (C1) Each logical axiom ax in sk(O_E(P(BGP))) is ground and entailed by sk(O(SG)) under the OWL 2 Direct Semantics. (C2) For each variable x in V(BGP), μ(x) occurs in O(SG) or in owl2V-Minus. (C3) Adding all axioms in O_E(P(BGP)) to O(SG) results in a valid OWL 2 DL ontology. 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.

6.3 Restrictions on Solutions (Informative)

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 are assumed to be present in any ontology (see Table 5 [OWL 2 Structural Specification]), i.e., O(SG) automatically includes declarations for these built-in entities. As under the OWL 2 RDF-Based Semantics, (C2) prevents infinite answers that could otherwise come from the very powerful datatype reasoning. An example that illustrates this is given in the OWL 2 RDF-Based Semantics entailment regime section.

6.3.1 BGP Constraints for OWL 2 DL

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. E.g., for owl:topDataProperty, the following requirement has to be met in OWL 2 DL:

The owl:topDataProperty property occurs in Ax only in the superDataPropertyExpression part of SubDataPropertyOf axioms.

C3 guarantees that the restrictions that are applied to the queried ontology are equally applied to the query. Since an OWL reasoner for he 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.

6.3.2 Queries with Variables in Literal Positions

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. Condition (C2) might exclude some inferred solutions. For example, consider an ontology with a data property ex:dp containing the axiom

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 successors and these successors have to be integers greater than 5 and less than 8, which means that one successor must have the value 6 and the other one the value 7. This axiom can be expressed in Turtle as

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) and DataPropertyAssertion(ex:dp ex:Peter "7"^^xsd:int), which is ex:Peter ex:dp "6"^^xsd:int and ex:Peter ex:dp "7"^^xsd:int in Turtle, respectively. If the values 6 and 7 do not occur in other axioms, then restriction (C2) prevents such possible answers from actually being part of the solutions since the values occur neither in the ontology nor in the vocabulary owl2V-Minus. Consider, for example, the following query against the above ontology:

SELECT ?s ?d WHERE { ?s ex:dp ?d }

where the BGP is mapped to the following FSS element:

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, causes ex:Peter to also appears among the answers since "6"^^xsd:int occurs now in the queried ontology and (C2) is satisfied for both answers.

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 by replacing all possible data values for ?x with values that occur in the ontology. Since there still might be many literals that have to be tested and no goal directed procedure is currently known, systems might choose to use incomplete reasoning regarding literals and only return explicitly asserted literal values (such as DataPropertyAssertion(ex:dp ex:Mary "6"^^xsd:int) above) or enrich the explicitly asserted values with sub-property reasoning and sameAs individual reasoning. Systems SHOULD state in their accompanying documentation when incomplete reasoning is used.

6.4 Higher Order Queries (Informative)

The Direct Semantics entailment regime allows for certain (but not all) forms of higher order queries. For example, one can use the BGP ?x rdfs:subClassOf ?y to query for pairs of sub- and super-classes. I.e., variables can bind to classes (representing sets of individuals) and not just to individuals or data values. Queries in which variables are used in positions of a First-Order Logic quantifier, will, however, be illegal since such queries cannot be mapped to OWL objects as required. For example, the following (illegal) query asks whether some or all brothers of Peter are persons:

SELECT ?x WHERE {
    ex:Peter a [ 
        a 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.

6.5 OWL 2 Profiles for Direct Semantics

OWL 2 Direct Semantics is not defined for arbitrary RDF graphs and the OWL 2 QL and EL profiles further restrict the allowed inputs. Thus, SPARQL endpoints that use Direct Semantics can further describe what input they can process in their service description.

6.5.1 OWL 2 DL

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 and QL profiles because these profiles are even more restrictive. Endpoints that use the OWL 2 Direct Semantics entailment regime and that can handle all of OWL 2 DL but not RDF graphs outside of the OWL 2 DL fragment can use the IRI http://www.w3.org/ns/owl-profile/DL to describe this in their service description.

6.5.2 The OWL 2 EL Profile

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. Endpoints that use the OWL 2 Direct Semantics entailment regime and that support the OWL 2 EL profile can use the IRI http://www.w3.org/ns/owl-profile/EL to describe this in their service description.

6.5.3 The OWL 2 QL Profile

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. Endpoints that use the OWL 2 Direct Semantics entailment regime and that support the OWL 2 QL profile can use the IRI http://www.w3.org/ns/owl-profile/QL to describe this in their service description.

6.5.4 The OWL 2 RL Profile

OWL 2 RL defines a syntactic subset of OWL 2, which is amenable to implementation using rule-based technologies. For RDF graphs that can be mapped into OWL 2 RL ontologies, the OWL 2 Direct Semantics can also be applied. Endpoints that use the OWL 2 Direct Semantics entailment regime and that support the OWL 2 RL profile can use the IRI http://www.w3.org/ns/owl-profile/RL to describe this in their service description.

7 RIF Core Entailment

The RIF RDF Compatibility document [RIF-RDF] specifies the interoperation between RIF and the data and ontology languages RDF, RDF Schema, and OWL. Interoperation is defined with respect to the semantics of RIF-RDF combinations. RIF-RDF combinations (or simply, combinations) consist of a RIF document and a set of RDF graphs. For the purpose of RIF Core entailment, we will only be concerned with combinations involving the single RDF graph comprised of the Skolemization of the merge of the scoping graph and any graphs imported from the RIF document. The scoping graph considered does not include the statement that refers to the RIF document (more on this in 7.1). The semantics of combinations are defined in terms of pairs of RIF and RDF interpretations. Each pairing is governed by a number of conditions that maintain a correspondence between RIF semantic structures (interpretations) and RDF interpretations. This maintained correspondence ensures the proper interpretation of names. It also maintains a correspondence between RDF triples of the form s p o, RIF frames of the form s[p->o], and their respective terms.

These conditions are enforced on a common RIF-RDF interpretation that is the basis for the standard model-theoretic notions of satisfiability and entailment with respect to common RIF-RDF interpretations, and when they are a model of a combination. A common RIF-RDF interpretation satisfies a combination if the semantic multi-structure (the first component of the common interpretation) is a RIF BLD model of the RIF document and the simple interpretation satisfies the RDF graph(s) in the combination. Such a common RIF-RDF interpretation can also be said to satisfy generalized RDF graphs that are (intuitively) those RDF graphs satisfied by the simple interpretation modified to correspond with the interpretation of the RIF document. The RIF-Simple-entails relationship builds on this and is the basis for the semantics of answers to queries using this entailment regime. Other similar RIF entailment relationships can be built for profiles such as those that have already been defined in this document as entailment regimes (RDF, RDFS, OWL-DL, etc.). In addition and as described in [OWL2-RL-RIF], an OWL 2 RL ontology can be mapped to a customized RIF Core rule set.

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 by the combination formed from the (skolemized) scoping graph and a referenced RIF-Core [RIF-Core] document. These additional notions of RIF satisfiability can similarly be used as the basis for more expressive RIF Core entailment regimes.

7.1 Referencing a RIF Core document

The RIF RDF Compatibility document provides a way to import an RDF graph (into a RIF document) and specify a profile that determines which model theoretic notion of satisfiability and entailment should be used with the combination. However, for our scenario, the inverse of such a reference is needed and a specific IRI is designated: http://www.w3.org/ns/rif#imports. In the subsequent text, we will refer to this IRI as rif:imports. In the RDF triple with this predicate, the object (a URI reference) MUST be considered the location of the safe RIF Core document to use to form the RIF-RDF combination that entails the answers. Combinations used in this SPARQL entailment regime MUST be interpreted using the semantics specified in the Simple profile (http://www.w3.org/ns/entailment/Simple)

Editorial note	19 May 2010
The namespace and IRI used for rif:imports is still under discussion within the group

7.2 (Simple) RIF Core Entailment Regime

Name	(Simple) RIF Core Entailment Regime
IRI	http://www.w3.org/ns/entailment/RIF
Legal Graphs	RDF graphs containing a triple with rif:imports as predicate (see 7.1) and where the imported RIF document is safe and does not include a binary Import statement with a profile other than Simple. If the RIF document imports RDF graphs, they must also use the Simple profile and these graphs are considered along with a version of the scoping graph formed without this single triple.
Legal Queries	Any legal SPARQL query.
Illegal handling	In case the query is illegal (syntax errors), the system MUST raise a MalformedQuery fault. In case the queried graph is illegal (syntax errors), the system MUST raise a QueryRequestRefused fault.
Entailment	RIF-Simple entailment
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:imports statement) along with any RDF graphs included in the referenced RIF Core document, 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 for G and BGP, and sk(SG) a Skolemization of SG with respect to a vocabulary disjoint from the vocabulary of SG and BGP. Applying sk to a term t, written sk(t), yields sk(t) if sk is defined for t and t otherwise; applying sk to a BGP, written sk(BGP), replaces each blank node b in BGP for which sk is defined with sk(b). A solution mapping μ is a solution for BGP from G under RIF-Simple entailment if dom(μ) = V(BGP) and there is an RDF instance mapping σ from B(BGP) to RDF-T such that dom(σ)=B(BGP) and the pattern instance mapping P=(μ, σ) is such that sk(P(BGP)) are ground, well-formed RDF triples that are RIF-Simple entailed by the RIF-RDF combination formed with the safe RIF Core document referenced from SG via the object of the rif:imports statement. 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 test case from the RIF test cases repository comprised of the following RDF graph and imported RIF Core document (in the presentation syntax):

(1) ex:Adrian ex:isChildOf ex:Uwe .
(2) ex:Adrian rdf:type ex:Male .
(3) ex:Uwe rdf:type ex:Male  .
(4) <> rif:imports <Class_Membership_rule.rifps>

Group ( 
    Forall ?X ?Y ( 
        ?Y [ ex:isFatherOf -> ?X ] :- And( ?X [ ex:isChildOf -> ?Y] ?Y # 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
μ₁	`ex:Uwe`	`ex:Adrian`

This follows from the fact that the result of applying a pattern instance mapping comprised of the solution μ₁ above and an empty mapping for blank nodes against the BGP in the query - i.e., sk(P(?father ex:isFatherOf ?child)) - is RIF-Simple entailed by the RIF-RDF combination formed from the RIF Core document and a graph comprised of just statements (1) - (3).

7.3 Custom Rulesets for Common Vocabulary Interpretations (Informative)

RDF vocabulary such as RDFS and OWL2-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 ruleset specified in [RIF-RDF]. Similarly, the RIF Core rules in [OWL2-RL-RIF] can be used to capture an axiomatization of OWL2-RL.

7.4 Finite Answer Set Conditions (Informative)

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 on logic programs permit the use of cyclic references between built-in function symbols defined by an external procedure. RIF-Core's notion of strong safety facilitates the ability to construct a finite grounding which addresses both components of condition C4 regarding SPARQL extensions and their solution sets: uniqueness and finiteness.

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 predicate). The ex:hasHospitalization predicate is defined (in the strongly safe RIF Core document) as a relation between a health care event with the larger hospital encounter event it is a part of based on the ordering of the dates associated with the events. The ordering constraint is enforced through the use of the pred:dateTime-greater-than and pred:dateTime-less-than external built-in predicates.

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) <> rif:imports <.. path to above document ..> .
(2) ex:Operation1 a 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   a 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      a 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

8 Entailment Regimes and Data Sets (Informative)

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 which represents a collection of graphs. An RDF Dataset comprises one graph, the default graph, which does not have a name, and zero or more named graphs, where each named graph is identified by an IRI. The graph that is used for matching a basic graph pattern is the active graph. Under an entailment regime E other than simple entailment, we do not only consider the triples that are in the graph, but also triples that are E-entailed by the graph. The entailed triples must, however, be E-entailed by the active graph and not by a merge of the triples in all graphs. This follows from conditions 1 and 3 of the conditions on extensions for basic graph matching.

For an example, we consider a data set with consists of an empty default graph, a named graph graphA with IRI http://example.org/a.rdf, and a named graph graphB with IRI http://example.org/b.rdf. The named graphs contain the following data:

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 a 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 clauses, which result in the creation of a fresh default graph for the query that contains a merge of the triples, e.g.,

SELECT ?inst FROM <http://example.org/a.rdf> FROM <http://example.org/b.rdf> WHERE { ?inst a ex:A }

has the answer { (inst, ex:x) }. One cannot merge triples from several sources into a named graph (they will always be merged into a fresh default graph) and such an extension would require changes to the conditions for extensions of basic graph pattern matching in the existing SPARQL query language specification.

9 Entailment Regimes and Updates (Informative)

SPARQL 1.1 also describes an update language (see SPARQL 1.1/Update and SPARQL 1.1/HTTP RDF Update), which can be used to add, modify, or delete data in an RDF graph. Support for SPARQL 1.1/Update and SPARQL 1.1/HTTP RDF Update is optional. SPARQL endpoints that use an entailment regime other than simple entailment may support update queries, but the exact behavior of the system for such queries is not covered by this specification. SPARQL endpoints that use an entailment regime other than simple entailment and that do support update queries should describe the system behavior in the system's documentation.

A References

A.1 Normative References

OWL 2 Profiles: OWL 2 Web Ontology Language Profiles, eds. Boris Motik, Bernardo Cuenca Grau, Ian Horrocks, Zhe Wu, Achille Fokoue, Carsten Lutz. W3C Recommendation 27 October 2009. (See http://www.w3.org/TR/owl2-profiles/.)
OWL 2 Structural Specification: OWL 2 Web Ontology Language Structural Specification and Functional-Style Syntax, eds. Boris Motik, Peter F. Patel-Schneider, Bijan Parsia. W3C Recommendation 27 October 2009. (See http://www.w3.org/TR/owl2-syntax/.)
OWL 2 RDF-Based Semantics: OWL 2 Web Ontology Language RDF-Based Semantics, ed. Michael Schneider. W3C Recommendation 27 October 2009. (See http://www.w3.org/TR/owl-rdf-based-semantics/.)
OWL 2 Mapping to RDF Graphs: OWL 2 Web Ontology Language Mapping to RDF Graphs, eds. Peter F. Patel-Schneider, Boris Motik. W3C Recommendation 27 October 2009. (See http://www.w3.org/TR/owl2-mapping-to-rdf/.)
RIF-Core: RIF Core Dialect, eds. Harold Boley, Gary Hallmark, Michael Kifer, Adrian Paschke, Axel Polleres, and Dave Reynolds. W3C Recommendation June 2010 (See http://www.w3.org/TR/rif-core/.)
OWL2-RL-RIF: OWL 2 RL in RIF, eds. Dave Reynolds. W3C Working Group Note 22 June 2010 (See http://www.w3.org/TR/2010/NOTE-rif-owl-rl-20100622/.)
RIF-RDF: RIF RDF and OWL Compatibility, ed. Jos de Bruijn. W3C Recommendation 22 June 2010 (See http://www.w3.org/TR/rif-rdf-owl/.)
SPARQL 1.1 Query: SPARQL 1.1 Query, eds. Steve Harris, Andy Seaborne. W3C Working Draft 2009. (See http://www.w3.org/TR/sparql11-query/.)
XSD: XML Schema Part 2: Datatypes Second Edition, eds. Paul V. Biron, Ashok Malhotra. W3C Recommendation 28 October 2004. (See http://www.w3.org/TR/xmlschema-2/.)

A.2 Other References

RDFSENTAILMENT: Completeness, decidability and complexity of entailment for RDF Schema and a semantic extension involving the OWL vocabulary, ed. Herman J. ter Horst. Journal of Web Semantics, 3(2-3):79-115, 2005.
STABLEMODEL: Stable models and an alternative logic programming paradigm, eds. Victor W. Marek, Miroslaw Truszczynski. Arxiv preprint / Citeseer, 1998. (See http://arxiv.org/abs/cs.LO/9809032.)
ANSWERSET-SW: Answer-Set Programming for the Semantic Web. PhD thesis, Roman Schindlauer. Vienna University of Technology, Austria, December 2006. (See http://www.kr.tuwien.ac.at/staff/former_staff/roman/papers/thesis.pdf.)
SAFETY: Safety of recursive Horn clauses with infinite relations, R. Ramakrishnan, F. Bancilhon, and A. Silberschatz. ACM New York, NY 1987. (See http://doi.acm.org/10.1145/28659.28694.)
TURTLE: Turtle - Terse RDF Triple Language, eds. Dave Beckett, Tim Berners-Lee. W3C Team Submission 14 January 2008. (See http://www.w3.org/TeamSubmission/turtle/.)

B Appendix: Mapping from BGPs to the extended OWL 2 Structural Specification

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]. Let ?x be a variable from BGP. If BGP contains a triple ?x rdf:type TYPE, where TYPE is one of owl:Class, owl:ObjectProperty, owl:DatatypeProperty, or owl:NamedIndividual, ?x is declared to be of type TYPE. BGP satisfies the typing constraints of the entailment regime if no variable is declared as being of more than one type.

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 implement these steps in any way it chooses; however, the results MUST be structurally equivalent to the ones defined in the following sections, where structural equivalence is taken to be extended in the natural way to also allow for variables, i.e., the definition of structural equivalence is as follows:

Objects o₁ and o₂ from the extended structural specification are structurally equivalent if the following conditions hold:

If o₁ and o₂ are atomic values, such as strings or integers, they are structurally equivalent if they are equal according to the notion of equality of the respective UML type.
If o₁ and o₂ are variables, they are structurally equivalent if they are equal according to the notion of string equality.
If o₁ and o₂ are unordered associations without repetitions, they are structurally equivalent if each element of o₁ is structurally equivalent to some element of o₂ and vice versa.
If o₁ and o₂ are ordered associations with repetitions, they are structurally equivalent if they contain the same number of elements and each element of o₁ is structurally equivalent to the element of o₂ with the same index.
If o₁ and o₂ are instances of UML classes from the structural specification, they are structurally equivalent if
- both o₁ and o₂ are instances of the same UML class, and
- each association of o₁ is structurally equivalent to the corresponding association of o₂ and vice versa.

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` for `x` an IRI or a blank node, then extend BGP with `_:x rdf:type owl:Ontology` for `_:x` a fresh blank node not occurring in BGP and SG.
CP 2	Compute Decl(BGP) as specified in Section 3.1 of the OWL 2 Mapping to RDF graphs specification with the difference that import statements do not result in the addition of triples. Initialize AllDecl(BGP) as the union of Decl(BGP) and declarations from O(SG), i.e., AllDecl(D_SG) where D_SG is the ontology document from which O(SG) is obtained.
CP 3	Create an instance O_E(BGP) that corresponds to an instance of the Ontology class from the extended grammar for the OWL 2 Direct Semantics. I.e., the UML classes are taken to be extended such that entities can also be variables.
CP 4	Analyze BGP and populate O_E(BGP) by instantiating appropriate classes from the extended structural specification. Use the declarations in AllDecl(BGP) to disambiguate IRIs and variables if needed. It MUST be possible to disambiguate all IRIs and variables. Variables that are not declared as being of some type occur either only in individual positions or only in literal positions; otherwise BGP is not legal for the regime.

A canonical definition for Step CP 4 is given in the following section.

B.1 Parsing BGPs into Objects of the Extended OWL 2 Structural Specification

Parsing BGPs into OWL objects as required in CP 4 follows closely the parsing process described in Section 3.2 of [OWL 2 Mapping to RDF Graphs]. This document only states where the parsing differs from the mapping as defined by OWL 2. The main difference is that IRIs, anonymous individuals, and literals can also be variables. Thus, the notation used in the mapping specification is taken to be extended as follows:

*:x denotes an IRI or a variable;
_:x denotes a blank node;
x denotes a blank node, an IRI or a variable;
lt denotes a literal or a variable; and
xlt denotes a blank node, an IRI, a literal, 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 or *:x_i instead of *:x also denote an IRIs or a variables. Further, _:x remains unchanged and does not represent a variable.

The functions CE(x), DR(x), OPE(x), and DPE(x) extend the respective functions in the section Mapping to RDF graphs [OWL 2 Mapping to RDF Graphs] to map into instances of the extended grammar for OWL 2 Direct Semantics BGPs, i.e., the functions also take variables as input and they map to objects that correspond to the extended structural specification for BGPs. The functions are initialized as in Table 9 of [OWL 2 Mapping to RDF Graphs] for non-variable declarations (*:x is not a variable) and extended for the case where *:x is a variable as follows:

If AllDecl(G) contains this declaration...	...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] with the modification that objects can contain variables. Variables are not allowed in the mapping for facet restrictions in the last column of Table 12 for *:w_i and the n that denotes a non-negative integer in cardinality restrictions is not redefined, i.e., it cannot be replaced by a variable.

C Appendix: Proofs

The SPARQL Query specification [SPARQL 1.1 Query] lists four conditions that entailment regimes that extend the standard simple entailment must satisfy. The different conditions are considered below for all entailment regimes in this document.

1 -- The scoping graph, SG, corresponding to any consistent active graph AG is uniquely specified up to RDF graph equivalence and is E-equivalent to AG.

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 SG and answer set {P₁ ... P_n} for a basic graph pattern BGP, and where {BGP₁ .... BGP_n} is a set of basic graph patterns all equivalent to BGP, none of which share any blank nodes with any other or with SG

SG E-entails (SG union P₁(BGP₁) union ... union P_n(BGP_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

and the BGP of the query is

?x ex:p ?y

The graph (even simply) entails the triple ex:s ex:p _:1 and also the triple _:1 ex:p ex:o. If we were to take P₁: ?x/ex:s, ?y/_:1 and P₂: ?x/_:1, ?y/ex:o, then, since BGP does not contain blank nodes, we can take any two copies BGP₁, BGP₂ of BGP and we would have to show (only considering the two example solutions):

SG E-entails (SG union P₁(BGP₁) union P₂(BGP₂)) =

{ ex:s ex:p _:b1 . _:b2 ex:p ex:o } E-entails { 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. The use of the same blank node identifier across several solutions is only valid if also the corresponding blank nodes in SG are identical.

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 solutions, these are not part of the actual solutions.

4 -- Each SPARQL extension MUST provide conditions on answer sets which guarantee that the set of triples obtained by instantiating BGP with each solution μ is uniquely specified up to RDF graph equivalence, and SHOULD provide further conditions to prevent trivial infinite answers as appropriate to the regime.

All regimes 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.

D CVS History

$Log: Overview.html,v $
Revision 1.5  2018/10/09 13:23:51  denis
fix validation of xhtml documents

Revision 1.4  2017/10/02 10:42:13  denis
add fixup.js to old specs

Revision 1.3  2010/10/14 12:05:42  bertails
fix html

Revision 1.2  2010/10/14 00:29:10  bertails
~ http://lists.w3.org/Archives/Team/webreq/2010Oct/0064.html

Revision 1.4  2010/10/13 17:16:42  apollere2
Changed to Working Draft.

Revision 1.3  2010/10/12 17:57:05  apollere2
Removed "view-source"

Revision 1.2  2010/10/08 05:47:53  apollere2
Fixed proper "previous version" links.CVS: ----------------------------------------------------------------------

Revision 1.1  2010/10/08 05:45:43  apollere2
Moved gen.html to Overview.html.

Revision 1.2  2010/10/06 22:56:36  bglimm
fixed accessibility

Revision 1.58  2010/10/06 22:51:42  bglimm
more accessibility fixes

Revision 1.97  2010/10/06 22:45:10  bglimm
fixes for accessibility, date format in ednotes standardised

Revision 1.96  2010/10/06 17:07:06  bglimm
changed date to 14th

Revision 1.95  2010/10/06 13:46:46  bglimm
fixed broken link

Revision 1.94  2010/10/06 13:19:05  bglimm
fixed wrong dtd, double bib entries, multiple IDs for tables, new html version

Revision 1.93  2010/10/05 18:35:24  cogbuji
added simple example right after (Simple) RIF entailment regime definition

Revision 1.92  2010/10/05 15:53:53  bglimm
use shared files

Revision 1.91  2010/10/02 17:55:45  bglimm
removed old ed. notes and made links of ent. reg. hyperlinks

Revision 1.90  2010/09/27 10:08:53  bglimm
fixed a typo in Sec 2.1 example

Revision 1.89  2010/09/22 17:52:01  bglimm
olivier's comments, some added examples, C4 removed from OWL DS, two new ed notes, local css used

Revision 1.88  2010/09/14 23:56:25  cogbuji
Incorporated changes from Mike Dean's comments:

http://lists.w3.org/Archives/Public/public-rif-wg/2010Sep/0002.html

Revision 1.87  2010/08/25 18:20:42  cogbuji
updates to clarify 'URI-inclusion' statement

Revision 1.86  2010/08/07 04:04:11  cogbuji
addressed Jos' response and clarified the language in various parts

Revision 1.85  2010/07/13 14:02:51  bglimm
multiplicity explicated, def pattern instance mapping moved to
preliminary definitions, C4 for Direct Semantics was broken, fixed
and extended to allow for querying negative data property assertions

Revision 1.84  2010/06/01 15:05:47  cogbuji
changed RIF entailment regime URI to an existing namespace document and changed editorial note to reflect that.

Revision 1.83  2010/05/25 10:49:19  bglimm
more pubrule fixing

Revision 1.82  2010/05/25 10:38:24  bglimm
fixed HTML to validate

Revision 1.81  2010/05/25 10:32:41  bglimm
fixed HTML to validate

Revision 1.80  2010/05/25 10:15:19  bglimm
added the xmlproc generated html file and editied CVS log to include
line breaks so that horizontal scrolling is not necessary

Revision 1.79  2010/05/24 18:30:38  cogbuji
updated RIF query answer semantics to require that sk(P(BGP)) are ground as well as 
well-formed triples, per Birte's email 
http://lists.w3.org/Archives/Public/public-rdf-dawg/2010AprJun/0245.html

Revision 1.78  2010/05/23 14:15:14  cogbuji
minor changes

Revision 1.77  2010/05/22 17:31:10  cogbuji
updated editorial text and fixed some wording.  applied Birte's suggestion about 
using sk on P(BGP) instead of SG

Revision 1.76  2010/05/21 14:51:38  cogbuji
reverted back to rif:imports.  Added editorial note for URI of entailment regime. 
Clarified editorial note regarding safety and added additional links. 
Updated Finite Answer Set Conditions (Informative) with additional information 
regarding safety.

Revision 1.75  2010/05/21 10:29:29  bglimm
made local copies of the xsl, css and dtd files, renamed them from xmlspec* to entailments*

Revision 1.74  2010/05/20 21:40:43  cogbuji
round of update moving safe condition into entailment framework and elaborating on strong 
safety and the concern about uniqueness of answers using safe rules

Revision 1.73  2010/05/20 06:19:36  cogbuji
fixed wording

Revision 1.72  2010/05/20 06:13:30  cogbuji
fixed reference to profile

Revision 1.71  2010/05/20 06:11:26  cogbuji
addressed comments from Birte, Ivan, and Axel

Revision 1.70  2010/05/18 11:05:18  bglimm
removed the FSS from the RDF-Based semantics section

Revision 1.69  2010/05/17 19:15:22  cogbuji
removed reference to ter Horst

Revision 1.68  2010/05/17 19:13:39  cogbuji
added reference to ter Horst paper

Revision 1.67  2010/05/17 19:11:53  cogbuji
updated legal graph section to rule out RDF graphs that have more than one statement with rif:imports

Revision 1.66  2010/05/17 19:02:40  cogbuji
updated namespace

Revision 1.65  2010/05/17 18:56:39  cogbuji
updated section discussing rif:imports.  Added section about custom rulesets

Revision 1.64  2010/05/13 20:09:19  bglimm
more of Ivan's comments addressed

Revision 1.63  2010/05/13 03:33:46  bglimm
implemented Ivan's editorial review comments

Revision 1.62  2010/05/11 13:08:06  bglimm
fixed a typo

Revision 1.61  2010/05/10 18:46:03  bglimm
added a section about the effects of canonicalization for D-Entailment, 
added an introductory paragraph for the OWL 2 DS and a section that 
clarifies the handling of imports, corrected some typos

Revision 1.60  2010/05/05 21:37:44  bglimm
fixed circ problem in Firefox

Revision 1.59  2010/04/27 14:14:34  bglimm
adapted the conditions on extensions to BGP matching to reflect the 
changes in the query doc, added an informative section about 
canonicalization of data values

Revision 1.58  2010/04/09 18:54:17  bglimm
minor editorial changes

Revision 1.57  2010/03/26 13:33:26  bglimm
turned mu back into mu from question mark

Revision 1.56  2010/03/19 11:24:21  bglimm
fixed broken link, fragments, HTML etc to make pub rules go through

Revision 1.55  2010/03/19 09:59:42  bglimm
fixed a double table id so xsltproc works

Revision 1.54  2010/03/19 09:55:54  bglimm
added D entailment, reworked the Direct Semantics regime to include more 
precise mapping from triples to OWL objects, adapted the conditions, 
unified C2 also with Direct Semantics, added proof that the regimes 
satisfy the conditions on BGP matching extensions

Revision 1.53  2010/03/11 17:29:15  cogbuji
Incorporated consensus from last RIF entialment meeting and dialog on 
the mailing list from 10th of March 2010

Revision 1.52  2010/03/08 22:08:51  cogbuji
incorporated Birte's changes regarding C2 along with other minor changes

Revision 1.51  2010/03/08 20:23:12  bglimm
modified C2 condition to limit the not nice non-local effects in particular 
under OWL RDF-Based regimes, more explicit mapping to error from the 
protocol spec

Revision 1.50  2010/03/07 02:15:35  cogbuji
various editorial updates

Revision 1.49  2010/03/07 01:43:11  cogbuji
Updated editorial section.  Added RIF Core Entailment section along with 
informative sections, an example, and updated the references.

Revision 1.48  2010/02/23 17:06:42  bglimm
corrected CVS log

Revision 1.47  2010/02/23 17:04:23  bglimm
fixed quote typo

Revision 1.46  2010/02/17 14:47:19  bglimm
corrected typos and unified C2 wording

Revision 1.45  2010/02/16 17:30:21  bglimm
added OWL RDF-Based Semantics incl. OWL 2 RL profile, added OWL 2 RL to Direct 
Semantics profile, added note about aggregate functions, corrected minor typos, 
adapted inconsistency handling

Revision 1.44  2010/01/28 16:12:14  bglimm
middle-ware -> middleware

Revision 1.43  2010/01/26 16:07:48  bglimm
fixed broken inks and fragments

Revision 1.42  2010/01/24 14:55:07  apollere2
Added prevloc.

Revision 1.41  2010/01/24 12:10:28  bglimm
also fixed xml version and not just the generated html file

Revision 1.40  2010/01/23 01:43:09  bglimm
tried to improve HTML markup to pass the validator check

Revision 1.39  2010/01/22 14:59:52  apollere2
Regenerated from xmlspec. Date was wrong.

Revision 1.38  2010/01/22 14:50:03  apollere2
Generated first version of next WD from xsltproc.

Revision 1.37  2010/01/13 14:17:30  bglimm
fixed HTML mark-up and informative subsections of informative sections are 
no longer explicitly marked as informative

Revision 1.36  2010/01/13 12:19:13  bglimm
Changed the editorial note on inconsistencies to reflect that the conditions 
on extensions to BGP matching do not apply to inconsistent graphs.

Revision 1.35  2010/01/12 01:06:38  bglimm
rephrased a sentence in the higher order queries paragraph

Revision 1.34  2010/01/11 17:01:28  bglimm
implemented Axel's comments part 2 (mainly adding some editorial notes to 
explain alternative design choices for Direct Semantics)

Revision 1.33  2010/01/08 15:00:04  bglimm
made it clearer that update support is optional even under simple entailment

Revision 1.32  2010/01/07 17:53:28  bglimm
improved grammar in the updates section

Revision 1.31  2010/01/07 17:50:55  bglimm
added a section about behaviour with update queries

Revision 1.30  2010/01/07 16:44:12  bglimm
improved Turtle syntax for examples and consistent use of FSS and Turtle 
in the Direct Semantics section

Revision 1.29  2010/01/05 19:42:10  bglimm
added a heading for the change summary

Revision 1.28  2010/01/05 18:37:08  bglimm
Small changes suggested by Axel in his review.

Revision 1.27  2010/01/05 17:07:12  bglimm
restructured the Direct Semantics sections according to Ivan's suggestions and 
corrected minor typos and rephrasings as suggested in Ivan's review

Revision 1.26  2009/12/22 12:05:23  bglimm
changed RDF to RDFS in the definition of answers for RDFS entailment

Revision 1.25  2009/12/22 11:18:24  bglimm
spell-checked the document

Revision 1.24  2009/12/19 12:57:46  bglimm
Added profile sections for Direct Semantics that mention service descriptions

Revision 1.23  2009/12/18 12:42:37  bglimm
added CVS log command