W3C

SPARQL 1.1 Entailment Regimes

W3C Working Draft 1 June 2010

This version:
http://www.w3.org/TR/2010/WD-sparql11-entailment-20100601/
Latest version:
http://www.w3.org/TR/sparql11-entailment/
Previous version:
http://www.w3.org/TR/2010/WD-sparql11-entailment-20100126/
Editors:
Birte Glimm, Oxford University Computing Laboratory <birte.glimm@comlab.ox.ac.uk>
Chimezie Ogbuji, Cleveland Clinic <ogbujic@ccf.org>
Contributors:
Sandro Hawke, W3C <sandro@w3.org>
Ivan Herman, W3C <ivan@w3.org>
Bijan Parsia, University of Manchester <bparsia@cs.manchester.ac.uk>
Axel Polleres, Digital Enterprise Research Institute <axel@polleres.net>
Andy Seaborne, Talis Information Limited <andy.seaborne@talis.com>

Abstract

SPARQL is a query language for data that is stored natively as RDF or viewed as RDF via middleware. What the correct answers to a SPARQL query are, depends on the used entailment regime and the vocabulary from which the resulting answers can be taken. SPARQL 1.1 Query [SPARQL 1.1 Query] defines basic graph pattern matching only for simple entailment, but it defines a set of conditions that have to be met when defining what correct results are for SPARQL queries under different entailment regimes. The goal of this document is to specify conditions such that SPARQL can be used with some other entailment regimes beyond simple entailment.

Change Summary

The first public working draft defined the semantics of SPARQL queries under RDF and RDFS entailment. In the second public working draft the RDF and RDFS entailment regimes have been changed to use a Skolemized version of the queried RDF triples to limit the possible answers to a finite set of answers. This prevents non-local effects that caused additional results for existing triples from unrelated newly added triples that contain new blank nodes. Further, an entailment regime for OWL Direct Semantics was added, which covers the OWL 2 DL, EL, and QL Profiles.

The current working draft also includes entailment regimes for D-entailment, OWL with RDF-Based Semantics including the OWL 2 RL Profile, and an entailment regime for the (safe) core dialect of the rule interchange format RIF. All regimes now take answers from the vocabulary of the queried graph and a vocabulary for the regime. As a consequence, very few entailed triples are omitted from the answers, while finiteness is preserved even under inconsistencies. The OWL Direct Semantics regime has been revised to make the mapping from triples in the basic graph pattern to OWL objects more precise. A grammar is used to define well-formed queries for the regime, which simplifies the conditions on answers. The OWL RL profile has also been added for the OWL 2 Direct Semantics entailment regimes. The previous modifications to the OWL Direct Semantics entailment relation have been removed. Queries for annotations might be added in a future version of the specification in a regime that extends the OWL 2 Direct Semantics regime.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is a Editors' Working Draft.

Comments on this document should be sent to public-rdf-dawg-comments@w3.org, a mailing list with a public archive. Questions and comments about SPARQL that are not related to this specification, including extensions and features, can be discussed on the mailing list public-sparql-dev@w3.org, (public archive).

This document was produced by the SPARQL Working Group, which is part of the W3C Semantic Web Activity.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

1 Introduction
    1.1 Document Conventions
        1.1.1 Graph Syntax
        1.1.2 Namespaces
        1.1.3 Preliminary Definitions
        1.1.4 Result Descriptions
    1.2 Effects of Different Entailment Regimes
    1.3 Extensions to Basic Graph Pattern Matching
2 RDF Entailment Regime
    2.1 Blank Nodes in the Queried Graph (Informative)
    2.2 Answers from Axiomatic Triples (Informative)
    2.3 Literals in the Subject Position (Informative)
    2.4 Boolean Queries (Informative)
3 RDFS Entailment Regime
    3.1 Inconsistencies (Informative)
        3.1.1 Effects of Unchecked Inconsistencies
    3.2 Aggregates and Blank Nodes (Informative)
4 D-Entailment Regime
    4.1 Canonical Lexical Representations (Informative)
5 OWL 2 RDF-Based Semantics Entailment Regime
    5.1 Restriction on Solutions
    5.2 Computing Query Answers under the RDF-Based Semantics (Informative)
    5.3 The OWL 2 RL Profile
        5.3.1 Computing Query Answers for the OWL 2 RL Profile with RDF-Based Semantics (Informative)
6 OWL 2 Direct Semantics Entailment Regime
    6.1 Introduction
        6.1.1 OWL Import Directives
        6.1.2 Extended Grammar for OWL 2 Direct Semantics BGPs
        6.1.3 Variable Typing
    6.2 The OWL 2 Direct Semantics Entailment Regime
    6.3 Restrictions on Solutions (Informative)
        6.3.1 BGP Constraints for OWL 2 DL
        6.3.2 Restriction on Data Property Assertions
    6.4 Higher Order Queries (Informative)
    6.5 OWL 2 Profiles for Direct Semantics
        6.5.1 OWL 2 DL
        6.5.2 The OWL 2 EL Profile
        6.5.3 The OWL 2 QL Profile
        6.5.4 The OWL 2 RL Profile
7 RIF Core Entailment
    7.1 Referencing a RIF Core document
    7.2 (Simple) RIF Core Entailment Regime
    7.3 Custom Rulesets for Common Vocabulary Interpretations (Informative)
    7.4 Finite Answer Set Conditions (Informative)
8 Entailment Regimes and Data Sets (Informative)
9 Entailment Regimes and Updates (Informative)

Appendices

A Related Issues
B References
    B.1 Normative References
    B.2 Other References
C Appendix: Mapping from BGPs to the extended OWL 2 Structural Specification
    C.1 Parsing BGPs into Objects of the Extended OWL 2 Structural Specification
D Appendix: Proofs
E CVS History


1 Introduction

The SPARQL 1.1 Query specification [SPARQL 1.1 Query] defines only simple entailment, which allows for finding answers by matching the triple pattern of the query onto the RDF graph of the queried data. Other entailment regimes, such as RDFS entailment, allow for finding answers to a query that are not directly specified in the queried graph, but can be inferred using a set of inference rules. In this document, we specify how SPARQL can be used with some other entailment regimes beyond simple entailment.

SPARQL Entailment Regimes is closely related to the following specifications:

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 abbreviatens 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:

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

1.1.4 Result Descriptions

Result sets are illustrated in tabular form.

xyz
"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 μ1:

xyz
μ1"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. 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 to other entailment regimes:

An entailment regime specifies

  1. A subset of RDF graphs called well-formed for the regime
  2. 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.

  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.
  2. For any basic graph pattern BGP and pattern instance mapping P, P(BGP) is well-formed for E.
  3. For any scoping graph SG and answer set {P1 ... Pn} for a basic graph pattern BGP, and where {BGP1 .... BGPn} 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 P1(BGP1) union ... union Pn(BGPn))

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

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:

  1. All entailment regimes specified here use the same definition of a scoping graph as given for simple entailment. Thus, the required equivalence is immediate.
  2. 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.
  3. 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.
  4. 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. We explain these restrictions in greater detail in the following sections.

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.

NameRDF
URIhttp://www.w3.org/ns/entailment/RDF
Legal GraphsAny legal RDF graph.
Legal QueriesAny legal SPARQL query.
Illegal handlingIn 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.
EntailmentRDF Entailment
InconsistencyRDF 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, and P=(μ, σ) a pattern instance mapping. Let P(BGP) denote the result of replacing each variable v from V(BGP) for which μ is defined with μ(v) and each blank node b from B(BGP) for which σ is defined with σ(b). Applying sk to a term t, written sk(t), yields sk(t) if sk is defined for t and t otherwise. Let sk(P(BGP)) denote the result of replacing each blank node b in P(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), sk(μ(x)) occurs in sk(SG) or in rdfV-Minus.

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 following example illustrates the use of condition C1. Consider the query

SELECT ?s ?o WHERE { ?s ex:b ?o } 

against a (scoping) graph containing only the triples

ex:a1 ex:b _:c1 . 
ex:a1 ex:b _:c2 .
ex:a2 ex:b _:c3 .

Simple entailment would give the solutions

so
μ1ex:a1_:c1
μ2ex:a1_:c2
μ3ex:a2_:c3

Since blank nodes only denote the existence of something and the actual blank node names do not matter, the following solution mappings are also possible solutions under RDF entailment (simple entailment restricts solutions to subgraphs of the queried graph):

so
μ4ex:a1_:c3
μ5ex:a1_:whatever
ex:a1...

Observe that, for instance, the inclusion of solution μ4 invalidates condition 3 from the SPARQL Query specification. This condition requires that SG entails the union of SG with all possible instantiations of BGP. Since BGP does not contain blank nodes, the blank node renaming as required by the condition is obsolete. Furthermore, we can use the empty RDF instance mapping σ to obtain the pattern instance mappings P3=(μ3, σ) and P4=(μ4, σ), which applied to BGP yield: P3(BGP) = ex:a2 ex:b _:c3 . and P4(BGP) = ex:a1 ex:b _:c3 .

The union of the two triples is not entailed by SG and adding further triples does not change that. This is because the reuse of the same blank node in different solutions has introduced an unintended co-reference, whereas the queried graph does not support the fact that both ex:a1 and ex:a2 are related to the same element.

Furthermore, 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 infinie answers. For a possible solution to actually be a solution, however, the two additional conditions C1 and C2 have to be met:

(C1) The RDF triples sk(P(BGP)) are ground and RDF entailed by sk(SG).

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

In this case, condition C1 limits the answers by checking entailments against a Skolemization of SG. Thus, let skol be a prefix that denotes a fresh IRI not occurring in the triples for SG and sk(SG) the following (Skolemized) graph:

ex:a1 ex:b skol:c1 . 
ex:a1 ex:b skol:c2 .
ex:a2 ex:b skol:c3 .

The Skolem function maps _:c1 to skol:c1, _:c2 to skol:c2, and _:c3 to skol:c3. Consider the pattern instance mapping P1=(μ1, σ1) with μ1 as given above and σ1 an empty RDF instance mapping. In this case, P1(BGP) = ex:a1 ex:b _:c1. Since sk(P(BGP)) = ex:a1 ex:b skol:c1 is a ground triple that is RDF entailed by the Skolemized scoping graph, C1 is satisfied. Since both sk(μ1(?s)) = sk(ex:a1) = ex:a1 and sk(μ1(?o)) = sk(_:c1) = skol:c1 occur in the Skolemized scoping graph, C2 is satisfied too and μ1 is a solution. Similarly, it can be shown that μ2 and μ3 are solutions. The other possible solutions are, however, not returned as solutions. For example, consider the pattern instance mapping P4=(μ4, σ4) for an empty RDF instance mapping σ4. In this case P4(BGP) = ex:a1 ex:b _:c3 and although sk(P(BGP)) = ex:a1 ex:b skol:c3 is ground, it is not RDF entailed by the Skolemized scoping graph. The pattern instance mapping P5=(μ5, σ5) for an empty RDF instance mapping σ5 leads to P5(BGP) = ex:a1 ex:b _:whatever. Since sk is not defined for _:whatever, sk(P(BGP)) = ex:a1 ex:b _:whatever is not a ground triple, which violates C1.

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
μ1ex: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
μ2rdf:type
μ3rdf:subject
μ4rdf:_1
μ5rdf:_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 μ2 to μ5 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.

  1. For the possible solution μ2, take an empty RDF instance mapping σ2 to obtain a pattern instance mapping P2=(μ2, σ2) with P2(BGP) = rdf:type a rdf:Property. Since μ2(?x)=rdf:type occurs in SG (and also in rdfV-Minus), condition C2 is also satisfied and this solution mapping is a solution.
  2. For the possible solution μ3: take again an empty RDF instance mapping σ3 to obtain a pattern instance mapping P3=(μ3, σ3) with P3(BGP) = rdf:subject a rdf:Property. Although μ3(?x)=rdf:subject does not occur in SG, it occurs in rdf-Minus and this possible solution mapping is, therefore, also returned as an answer.
  3. For the possible solution μ4: take again an empty RDF instance mapping σ4 to obtain a pattern instance mapping P4=(μ4, σ4) with P4(BGP) = rdf:_1 a rdf:Property. Since μ4(?x)=rdf:_1 occurs in SG, this is a solution.
  4. For the possible solution μ5: take again an empty RDF instance mapping σ5 to obtain a pattern instance mapping P5=(μ5, σ5) with P5(BGP) = rdf:_2 a rdf:Property. Since μ5(?x)=rdf:_2 occurs neither in SG nor in rdf-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.

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 has no solution since even if a pattern instance mapping yields an axiomatic triple, condition C2 cannot be satisfied.

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.

Editorial note14/10/2009

Other possible design choices for finite answers under RDF and the following RDFS entailment regime are:

  1. Instead of also allowing bindings from rdfV-Minus, condition C2 could be modified to only allow bindings to terms that occur in the (Skolemized) scoping graph. This would exclude more answers that involve terms from the RDF(S) vocabulary. For example, an RDF graph containing the triple
    ex:s ex:p ex:o 
    RDF entails
    ex:p a rdf:Property
    but under the modified conditions, the query
    SELECT ?t WHERE { ex:p a ?t } 
    against that graph would have an empty answer. This is because a solution mapping μ that maps ?t to rdf:Property would violate the condition because rdf:Property does not occur in the scoping graph and Skolemization has no effect in this example. If the modified condition would only apply to variables hat occur in subject position, the query would have an answer, but an inconsistent active graph could result in infinite answers for the RDFS and OWL RDF-Based entailment regimes.
  2. Instead of using the vocabulary of the graph plus the rdfV-Minus vocabulary to limit the number of axiomatic triples, axiomatic triples could simply be excluded from the query answers. Inconsistencies could, however, still cause infinite answers for example from datatypes since an inconsistent graph trivially entails any triple, e.g., rdf:type rdf:type "<a>x</a>"^^rdf:XMLLiteral, rdf:type rdf:type "<a>xx</a>"^^rdf:XMLLiteral, etc.
  3. Since, as long as literals are not allowed in subject positions, only subjects of the form rdf:_1, rdf:_2, ... can cause infinite answers, we could also look at what the largest n is in elements of the form rdf:_n and return axiomatic triples such as rdf:_m a rdf:Property only if m<=n. This falls apart, however, if literals are allowed in the subject position, since in that case
    xxx a rdf:XMLLiteral 
    is an answer to the query
    SELECT ?x WHERE {  ?x a rdf:XMLLiteral }
    for xxx a well-formed RDF XML literal. Further, this solution still has to define a suitable behavior for inconsistent graphs.

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.

NameRDFS
URIhttp://www.w3.org/ns/entailment/RDFS
Legal GraphsAny legal RDF graph.
Legal QueriesAny legal SPARQL query.
Illegal handlingIn 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.
EntailmentRDFS Entailment
InconsistencyThe 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, and P=(μ, σ) a pattern instance mapping. Let P(BGP) denote the result of replacing each variable v from V(BGP) for which μ is defined with μ(v) and each blank node b from B(BGP) for which σ is defined with σ(b). Applying sk to a term t, written sk(t), yields sk(t) if sk is defined for t and t otherwise. Let sk(P(BGP)) denote the result of replacing each blank node b in P(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), sk(μ(x)) occurs in sk(SG) or in rdfsV-Minus.

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:yn 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, discoverning 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.

Editorial note14/10/2009

The current understanding of the working group is that the first condition on extensions of basic graph pattern matching:

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

does not apply to inconsistent active graphs. This condition does, thus, not restrict how we define the scoping graph in case of an E-inconsistent active graph and at current we just define the scoping graph in the same way as for consistent graphs.

One alternative way would be to define the scoping graph only if the active graph is consistent. If the active graph is inconsistent, one then has to specify conditions independent of the scoping graph that prevent infinite answers (an inconsistent graph trivially RDFS entails any RDF triple).
Another possibility would be to specify an entailment regime for a subset of RDFS that cannot express inconsistencies, e.g., by defining well-formed graphs for the regime as those that contain only syntactically valid rdf XML literals.
The scoping graph could also be defined as graph equivalent to a "repaired" active graph in which malformed XML literals are replaced with well-formed ones. This would allow systems to more or less ignore inconsistencies and the behavior of systems is well-defined in any case since malformed XML literals are the only cause for inconsistencies in RDFS interpretations. This definition does, however, not extend to more expressive entailment relations such as OWL with RDF-Based Semantics.
Several other alternatives, including different, implementation-dependent behaviors for systems that do/do not check consistency are currently being under discussion in the working group.

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:

authorpublication
μ1_:a1ex:book1
μ2ex:author2ex: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:

publicationnumAuthors
ex:book12

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

authorpublication
μ1_:a1ex:book1
μ2ex:author2ex:book1
μ3_:a1ex:book2
μ4ex:author3ex:book2
μ5_:a4ex: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:

publicationnumAuthors
ex:book12
ex:book23

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.

NameD-Entailment
URIhttp://www.w3.org/ns/entailment/D
Legal GraphsAny legal RDF graph.
Legal QueriesAny legal SPARQL query.
Illegal handlingIn 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.
EntailmentD-Entailment
InconsistencyThe 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, and P=(μ, σ) a pattern instance mapping. Let P(BGP) denote the result of replacing each variable v from V(BGP) for which μ is defined with μ(v) and each blank node b from B(BGP) for which σ is defined with σ(b). Applying sk to a term t, written sk(t), yields sk(t) if sk is defined for t and t otherwise. Let sk(P(BGP)) denote the result of replacing each blank node b in P(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), sk(μ(x)) occurs in sk(SG) or in dV-Minus.

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 datatye 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

The OWL 2 RDF-Based Semantics entailment regime assumes that queries are answered with respect to an OWL 2 RDF-Based datatype map D.

NameOWL 2 RDF-Based Semantics
URIhttp://www.w3.org/ns/entailment/OWL-RDF-Based
Legal GraphsAny legal RDF graph.
Legal QueriesAny legal SPARQL query.
Illegal handlingIn 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.
EntailmentOWL 2 RDF-Based Entailment
InconsistencyThe 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, and P=(μ, σ) a pattern instance mapping. Let P(BGP) denote the result of replacing each variable v from V(BGP) for which μ is defined with μ(v) and each blank node b from B(BGP) for which σ is defined with σ(b). Applying sk to a term t, written sk(t), yields sk(t) if sk is defined for t and t otherwise. Let sk(P(BGP)) denote the result of replacing each blank node b in P(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), sk(μ(x)) occurs in sk(SG) or in owl2V-Minus.

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 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 interger 5:

ex:Peter a [
    a owl:Restriction ;
    owl:onProperty ex:dp ;
    owl:allValuesFrom [
      rdf:type 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 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)
      ]
    ]
  ]
}

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:int ;
  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 analysing 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.2 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.3 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.3.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

  1. Annotations,
  2. Entity Declarations,
  3. 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.

Class := IRI | Var

ObjectProperty := IRI | Var

DataProperty := IRI | Var

Individual := NamedIndividual | AnonymousIndividual | Var

Literal := typedLiteral | stringLiteralNoLanguage | stringLiteralWithLanguage | Var

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 the required 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

  1. 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,
  2. inverse object properties, i.e., the BGP maps to ObjectInverseOf(?o) where ?s maps to a blank node and ?p to owl:inverseOf,
  3. subclasses, i.e., the BGP maps to SubClassOf( ?s ?o ) where ?p binds to rdfs:subClassOf,
  4. equivalent classes, i.e., the BGP maps to EquivalentClasses(?s ?o) where ?p binds to owl:equivalentClass,
  5. disjoint classes, i.e., the BGP maps to DisjointClasses(?s ?o) where ?p binds to owl:disjointWith,
  6. ...

In order to answer the query without any restrictions, 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

NameOWL 2 Direct Semantics
URIhttp://www.w3.org/ns/entailment/OWL-Direct
Legal GraphsAny RDF graph which can be mapped into an OWL 2 DL ontology document.
Legal QueriesLet 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 handlingIn 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.
EntailmentOWL 2 Direct Semantics
InconsistencyIf 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), and P=(μ, σ) a pattern instance mapping.

Let OE(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 OE(BGP), and AI(BGP) the set of anonymous individuals in OE(BGP). Let P(BGP) denote the result of replacing each variable v from V(BGP) for which μ is defined with μ(v) and each anonymous individual i from AI(BGP) for which σ is defined with σ(i). Let sk(P(BGP)) denote the result of replacing each anonymous individual i in AI(BGP) for which sk is defined with sk(i). 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 OE(sk(P(BGP))) is ground and entailed by sk(O(SG)) under the OWL 2 Direct Semantics.

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

(C3) Adding all axioms in OE(P(BGP)) to O(SG) results in a valid OWL 2 DL ontology.

An implementation of the OWL 2 Direct Semantics entailment regime MAY impose the additional restriction

(C4) Each axiom ax in OE(BGP) with a variable ?x that occurs in the position of a datatype literal, is either of the form

  • DataPropertyAssertion(DP I ?x) with DP a data property or a variable and I an individual or a variable, or
  • ClassAssertion(C I) with I an individual or a variable and C a concept of the form DataOneOf(?x).

Implementations that impose this additional restriction MUST provide a means to determine this – they could, for example, list this in their supporting documentation.

6.3 Restrictions on Solutions (Informative)

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.

Condition C2 is also applied as in the previously defined regimes and guarantees finite answers. Due to the absence of the RDF(S) axiomatic triples, owl2V-Minus could equally be replaced by owl2V. 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 also equally applied to the query.

6.3.2 Restriction on Data Property Assertions

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. The optional condition C4 will exclude such 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. 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 without C4 has now two answers:

sd
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. Systems that also use C4 will only return one answer:

sd
ex:Mary"6"^^xsd:int

With C4, only asserted data values are considered, which prevents these non-local effects, but further limits the inferences used to retrieve the query answers.

Since there are infinitely many data values, C2 and the optional C4 have the additional 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. Testing all possible values no matter whether they occur in the ontology or not is not feasible given that there are infinitely many possible data values to choose from and terminating query answering procedures without such restrictions are not readily available.

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

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 URI 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 URI 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 URI 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 URI 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 a single RDF graph, the Skolemization of the scoping graph. 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 and 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, each of which define how a common RIF-RDF interpretation is 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.

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 to interpret 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 note05/19/2010
The namespace and URI used for rif:imports is still under discussion within the group

7.2 (Simple) RIF Core Entailment Regime

Name(Simple) RIF Core Entailment Regime
URIhttp://www.w3.org/ns/entailment/RIF
Legal GraphsRDF graphs with exactly one triple with a rif:imports as a 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.
Legal QueriesAny legal SPARQL query.
Illegal handlingIn 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.
EntailmentRIF-Simple entailment
InconsistencyAs 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 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, and P=(μ, σ) a pattern instance mapping. We write P(BGP) to denote the result of replacing each variable v from V(BGP) for which μ is defined with μ(v) and each blank node b from B(BGP) for which σ is defined with σ(b). Applying sk to a term t, written sk(t), yields sk(t) if sk is defined for t and t otherwise. With sk(P(BGP)) we denote the result of replacing each blank node b in P(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 rif:imports predicate.

Editorial note05/19/2010

It is unclear whether safe RIF-Core rules used to form combinations for this entailment regime guarantee uniqueness (up to RDF graph equivalence) on answer sets. Safeness by itself is known to not guarantee that it is possible to construct a finite grounding without additional (stronger) safety conditions.

Intuitively, the grounding of a rule is the set of all possible ways ground versions of its atomic formulae and external predicates can be obtained by replacing variables with referents from the domain [ANSWERSET-SW]. Variable subsititutions essentially correspond to SPARQL solution mapping, so an infinite grounding corresponds to a infinite solution set. If the solution mappings in such a set differred only by blank node renaming, then safeness would be sufficient for condition 4. However, it is not clear if this is the case for all combinations formed from safe RIF-Core rules.

Without strongly safe restrictions, there may be interoperability issues with Datalog engines (for instance) that can only process rules that can be finitely grounded.

However, strong safety restrictions are only defined in the informative sections of the RIF-Core specification

Editorial note21/05/2010
Should that entailment URI be something like http://www.w3.org/ns/entailment/RDF-RIF-Core instead, since the profile being used for this entailment regime is more restricted ( RIF-Simple entailment)?

RIF-Core conformance is defined with respect to safe rules and so this entailment regime is defined with respect to combinations formed from safe RIF documents.

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 RRDFS 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 and (with possibly infinite) predicates 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 a query) it is necessary to test whether a given query is safe [SAFETY].

Without strong safety conditions, cyclic references can rule out the existence of a unique, minimal Herbrand model of the combination. With strong safety conditions, even in the face of a cycle, the output of a built-in predicate cannot grow infinitely, since the size of its input is fixed prior to entering the cycle [ANSWERSET-SW] and the evaluation of a built-in predicate with a possibly infinite extension (such as pred:numeric-less-than or pred:dateTime-greater-than) is determined only by the terms from a collection of finite predicates. Restrictions such as these are traditionally enforced through the use of a dependency graph [STABLEMODEL] to determine if a ruleset is stratified. Stratification is typically applied to logic programs with negated literals and RIF-Core does not allow negated literals. However, logic programs restricted in this way permit the use of built-in function symbols such that the truth of a predicate is well-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 the forth requirement of SPARQL extensions on their answer 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:

EVTHOSP
ex:Operation1ex: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 { ex:x a ?type } }

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 ?type.

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 ?t FROM <http://example.org/a.rdf> FROM <http://example.org/b.rdf> WHERE { ex:x a ?t } 

has the answer { (t, ex:A) }. One can not 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 Related Issues

B References

B.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 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 Proposed Recommendation May 2010 (See http://www.w3.org/TR/rif-core/.)
RIF-RDF
RIF RDF and OWL Compatibility, ed. Jos de Bruijn. W3C Proposed Recommendation May 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/.)

B.2 Other References

OWL2-RL-RIF
OWL 2 RL in RIF, eds. Dave Reynolds. W3C Working Draft 11 May 2010. (See http://www.w3.org/TR/2010/WD-rif-owl-rl-20100511.)
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/.)

C 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 o1 and o2 from the extended structural specification are structurally equivalent if the following conditions hold:

The following table defines the steps that are involved in the mapping process from basic graph patterns to extended OWL objects.

CP 1 Initialize AllDecl(BGP) to contain all declarations from O(SG) including the declarations for the OWL 2 built-in entities.
CP 2 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 3 Create an instance OE(BGP) that corresponds to an instance of the Ontology class from the extended grammar for 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 OE(BGP) by instantiating appropriate classes from the extended structural specification. Use the declarations in AllDecl(D) and the variable types 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.

C.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 the Mapping to RDF graphs section of OWL 2 [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. An IRI that denotes a class name can only be replaced by a variable ?x such that type(?x)=owl:Class, an IRI that denotes an object property can only be replaced by a variable ?x such that type(?x)=owl:ObjectProperty, etc.

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. Note that the mapping for annotation properties is left unchanged, since annotations are non-logical and using variables in an annotation or in place of an annotation property does not make sense under Direct Semantics. The functions are initialized as in Table 9 of [OWL 2 Mapping to RDF Graphs] and extended as follows:

  • CE(x) = CE(x) UNION { (x, x) | x in V(BGP) and type(x)=owl:Class },
  • DR(x) = DR(x) UNION { (x, x) | x in V(BGP) and type(x)=rdfs:Datatype },
  • OPE(x) = OPE(x) UNION { (x, x) | x in V(BGP) and type(x)=owl:ObjectProperty },
  • DPE(x) = DPE(x) UNION { (x, x) | x in V(BGP) and type(x)=DatatypeProperty },

Parsing then continues as described in [OWL 2 Mapping to RDF Graphs] with the modification that objects can contain variables. In particular, the notation is 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 *:xi instead of *:x also denote an IRIs or a variables. Further, _:x remains unchanged and does not represent a variable.

Variables are not allowed in the mapping for facet restrictions in the last column of Table 12 for *:wi and lti, and they are not allowed in the mapping for negative data property assertions for lt of Table 16. Further, the n that denotes a non-negative integer in cardinality restrictions is not redefined, i.e., it cannot be replaced by a variable.

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

Editorial note11/03/2010
The RIF regime might need careful consideration here since the scoping graph should not be taken to include the rules from the imported rule sets unless this preserves E-equivalence.

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 {P1 ... Pn} for a basic graph pattern BGP, and where {BGP1 .... BGPn} 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 P1(BGP1) union ... union Pn(BGPn))

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 P1: ?x/ex:s, ?y/_:1 and P2: ?x/_:1, ?y/ex:o, then, since BGP does not contain blank nodes, we can take any two copies BGP1, BGP2 of BGP and we would have to show (only considering the two example solutions):

SG E-entails (SG union P1(BGP1) union P2(BGP2)) =

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

E CVS History

$Log: Overview.html,v $
Revision 1.3  2010/06/02 13:33:22  bertails
(bertails) Changed through Jigsaw on edit.w3.org

Revision 1.2  2010/06/01 17:47:14  bertails
(bertails) Changed through Jigsaw on edit.w3.org

Revision 1.2  2010/06/01 17:15:03  lfeigenb
fix link to css

Revision 1.1  2010/06/01 15:41:01  lfeigenb
initial checkin

Revision 1.53  2010/05/25 18:13:48  lfeigenb
for publication

Revision 1.52  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