This document uses the 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 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 made 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 non-abbreviated IRIs such as <book2>, which are relative to the base IRI of the document.

Examples assume the following namespace prefix bindings unless otherwise stated:

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

This document uses the same definitions as the SPARQL Query Language specification and we recapture the most important terms here for clarity. In the case of any difference, the SPARQL Query Language definitions are the normative ones.

We use RDF-L for the set of all RDF Literals, RDF-B for the set of all blank nodes in RDF graphs, and RDF-T for the set of RDF Terms, which is a union of the set of all IRIs, RDF-L, and RDF-B.

We use V for the set of query variables, where V is infinite and disjoint from RDF-T. A triple pattern is member of the set:

A Basic Graph Pattern is a set of Triple Patterns.

The following example illustrates the use of both conditions C1 and C2. Consider the query

against a graph containing only the triples

The scoping graph is assumed to be the same as the active graph, i.e., the graph for the triples shown above. One of the possible solutions is { (x, ex:b) } since according to the RDF entailment rule rdf1

entails

Further, the axiomatic triples, give the possible solutions such as { (x, rdf:type) } or { (x, rdf:subject) } and { (x, rdf:_1) }, { (x, rdf:_2) }, ... There are even more possible answers since the simple entailment rule se2 means that

RDF entails

for some blank node _:exb1 allocated to ex:b and { (x, _:exb1) } is a possible solution. The rule se2 can be applied again to the just mentioned triple, showing that the following triple is also entailed by the queried graph

for some blank node _:exb2 allocated to _:exb1 and { (x, _:exb2) } is a possible solution too. One can, in fact, infer infinitely many blank nodes to be possible solutions for the query.

Clearly, the set of possible solutions is infinite in this case, but for a possible solution to actually be a solution, the two conditions C1 and C2 have to be met: (C1) each subject s of a triple ( s, p, o ) in P(BGP) occurs in the scoping graph and (C2) each blank node b in the range of μ and σ occurs in the scoping graph SG.

In this case, condition C1 limits the answers from the axiomatic triples. We consider the examplary possible answers { (x, rdf:type) }, { (x, rdf:subject) }, { (x, rdf:_1) }, and { (x, rdf:_2) }.

• For the possible solution μ: x -> rdf:type, take an empty RDF instance mapping σ to obtain a pattern instance mapping P=(μ, σ) with P(BGP) = rdf:type rdf:type rdf:Property .

Since the subject rdf:type occurs in the scoping graph (here the scoping graph and the active graph are equal) and condition C2 is trivially satisfied, this solution mapping is actualy a solution.

• For the possible solution μ: x -> rdf:subject, take again an empty RDF instance mapping σ to obtain a pattern instance mapping P=(μ, σ) with P(BGP) = rdf:subject rdf:type rdf:Property .

Since the subject rdf:subject does not occur in the scoping graph, this possible solution mapping is excluded and nor part of the actual solutions although the triple is entailed.

• For the possible solution μ: x -> rdf:_1, take again an empty RDF instance mapping σ to obtain a pattern instance mapping P=(μ, σ) with P(BGP) = rdf:_1 rdf:type rdf:Property .

Since the subject rdf:_1 occurs in the scoping graph and condition C2 is trivially satisfied, this solution mapping is actualy a solution.

• For the possible solution μ: x -> rdf:_2, take again an empty RDF instance mapping σ to obtain a pattern instance mapping P=(μ, σ) with P(BGP) = rdf:_2 rdf:type rdf:Property .

Since the subject rdf:_2 does not occur in the scoping graph, this solution mapping is not a solution. Similar arguments can be used for rdf:_n with n > 2 and for other bindings from axiomatic triples such as rdf:first from the axiomatic triple rdf:first rdf:type rdf:Property ..

The second condition rules out { (x, _:exb1) }, { (x, _:exb2) }, ... since the blank nodes _:exb1, _:exb2, ... do not occur in the scoping graph (again the scoping graph equals the active graph here). Thus, the only answers are { (x, ex:b) }, { (x, rdf:type) }, and { (x, rdf:_1) }.

We give another example for RDFS entailment that shows the behavior if the query contains blank nodes and for the case where entailment really makes a difference other than adding some axiomatic triples.

Please note that solution mappings that map variables that occur in the subject in the basic graph pattern BGP to literals will not be returned as solutions even though 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

even the empty graph would RDF entail all statements xxx rdf:type rdf:XMLLiteral for xxx a well-formed RDF XML literal, but applying a solution mapping such as μ : x -> "<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 C1 would still guarantee finite answers.

The two conditions C1 and C2 also have an effect on the answers to Boolean queries. For Boolean queries that contain variables, e.g.,

this is straighforward. The query answer is yes (true) if x has at least one solution and it is no (false) otherwise. For Boolean queries without variables it is less clear how the answer is determined. We have two possible outcomes for a Boolean query without variables: 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). Thus we can still apply the two conditions on possible solutions and check whether the solution mapping is indeed a solution. For example, if we ask the above query against the empty graph, we find that the solution mapping μ with empy domain is a possible solution, but condition C1 rules this solution mapping out as an answer and the query answer is no (false).

For RDFS entailment, we consider an example that uses RDFS entailment to derive implicit consequences and we also consider a query with blank nodes in it. The active graph in this example is for the triples

The scoping graph is again assumed to be the the same as the active graph. The query is

We deliberately use a blank node in the query that has the same label as one of the blank nodes in the active graph. Since we consider RDFS entailment, the active graph entails a number of interesting triples such as

just to name some. The active graph does, however, not entail

since it is not the case that every RDFS interpretation must map _:a to an element that is the ex:r successor of something. The graph does also not entail

since ex:t is not a subproperty of ex:s.

From the entailed triples, we get a number of possible solutions, e.g.,

etc., but we do not get P=(μ, σ) with μ : x->_:x and σ : _:a->_:a since P(BGP) is not entailed by the scoping graph as argued above. To be solutions, the possible solution have to satisfy C1 and C2:

(C1) each subject s of a triple ( s, p, o ) in P(BGP) occurs in the scoping graph and

(C2) each blank node b in the range of μ and σ occurs in the scoping graph SG.

Here we have

and P₁ and P₃ do satisfy condition C1, but condition C2 rules out P₃ and we have a single answer { (x, _:a) } from P₁. Interestingly, it is not the case that the result of instantiating the BGP ?x ex:r _:a with the solution mapping (_:a ex:r _:a) results in a triple that is RDFS entailed by the active graph because we would have to use an appropriate RDF instance mapping too. Such an instance mapping, e.g., σ₁, maps _:a from the BGP to a suitable blank node in the scoping graph. Although the label _:a is used in the BGP and in the queried graph, the semantics of blank nodes and their local scope means that the two labels are not required to refer to the element. We can equally use the query

We only need names for the blank nodes in the query to enforce co-references. E.g., in the query

we ask for elements that start an ex:r ex:s chain. If the queried graph contains also a blank node _:b, then the name _:b in the query is, however, not necessarily mapped to the same element as the _:b in the queried graph.

We can consider the above example again, but this time with a scoping graph that does use different names for the blank nodes in the active graph and the query. E.g., assume that the scoping graph SG contains the triples

The query is again

The scoping graph entails a number of intersting triples such as

just to name some. The scoping graph does, however, not entail

since it is not the case that every RDFS interpretation must map _:sga to an element that is the ex:r successor of something. The graph does also not entail

since ex:t is not a subproperty of ex:s.

From the entailed triples, we get a number of possible solutions, e.g.,

etc., but we do not get P=(μ, σ) with μ : x->_:x and σ : _:a->_:sga since P(BGP) is not entailed by the scoping graph as argued above. To be solutions, the possible solution have to satisfy C1 and C2:

(C1) each subject s of a triple ( s, p, o ) in P(BGP) occurs in the scoping graph and

(C2) each blank node b in the range of μ and σ occurs in the scoping graph SG.

Here we have

and P₁ and P₃ do satisfy condition C1, but condition C2 rules out P₃ and we again have a single answer { (x, _:sga) } from P₁.

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 mal-formed XML string, e.g.,

in combination with a range restriction on the property, e.g.,

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

Here we can to derive the inconsistency as follows:

At this point, we can detect the inconsistency since "<" is not a valid lexical form for an RDF XML literal and we have to interpret it as some element tha 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.

If the BGP cannot be instantiated into a complete OWL 2 DL ontology, then it must be possible to instantiate the BGP extended with _:o a owl:Ontology for a fresh blank node _:o into an OWL 2 DL ontology or the BGP will result in an empty answer. Thus, the requirements for declarations as for OWL 2 DL ontologies also apply to BGPs.

For axioms to be parsed into an OWL 2 DL ontology or from a BGP, the types of resources must be clear. This is why there must be a declaration for each property in an ontology. E.g., from the triple :a :r :b. it is not clear whether :r is an object or an annotation property. Depending on the type, the triple would be parsed as ObjectPropertyAssertion(:r :a :b) or AnnotationAssertion(:r :a :b), but without type information the triple cannot be mapped into an OWL object. If the predicate is not a variable, then one could use the queried ontology to determine the type of :r. If the BGP contains a triple such as :a ?p ?o, however, this is not possible. It is required, therefore, that the BGP also contains the required declaration, i.e., a BGP such as :a ?p ?o . ?p a owl:ObjectProperty . is a valid and parsable BGP.

Anonymous individuals can be used in the solution mapping. For example, let O be an ontology containing the axioms

The query for O is

An anonymous or named individual i is in the solution sequence as binding for ?x if O entails ClassAssertion(:Person i), where ClassAssertion(:Person i) is the ontology axiom that corresponds to the triple i rdf:type :Person. Consider the following pattern instance mappings each for the empty RDF instance mapping σ : {} -> {}:

Applied to the BGP ?x rdf:type:Person of the query this yields (in the form of OWL axioms)

The ontology O entails P(BGP) if and only if each model of O that interprets also the vocabulary of the query is a model for P(BGP). Thus, μ₁ is a solution. Similarly, μ₂ is a solution. For P₃(BGP), we can build a model for O that interprets _:2 as an element that does not belong to the interpretation of the class :Person and μ₃ is not a solution. Finally, μ₄ is also not a solution since _:neither1nor2 can also be interpreted as an element that does not belong to the extension of the class :Person.

Thus, the solution sequence contains two solutions: (x, :Peter) and (x, _:1). This illustrates that anonymous individuals can be returned as part of the answer and that the anonymous individuals from the queried ontology behave like named individuals. It should be noted, however, that the RDF graph or input document from which the ontology O was built does not have to contain the blank nodes _:1 and _:2. These blank nodes could have used different identifiers, e.g., _:x and _:y.

Anonymous individuals in the query play a slightly different role. For example, the query

for the same ontology O as above has a single answer (x, _:1). Since the anonymous individual _:1 is the only individual occurring in the subject position for the :hasBrother predicate, the only reasonable solution mapping is μ : x->_:1. For μ to be a solution, there has to be an RDF instance mapping and σ₁ : _:y -> :Peter or σ₂ : _:y -> _:2 could both be used. Although there are two possible instance mappings, the cardinality of the solution sequence is one.

Using the same blank nodes in the query and in the ontology has no effect on the query answer, although for clarity we assume that the ontology is obtained from a scoping graph that uses only blank nodes that do not occur in the query and in the input RDF graph. If we assume that the query has the BGP ?x :hasBrother _:1, the answer is still as before since we can use the RDF instance mapping σ : _:1 -> :Peter or σ : _:1 -> _:2.

The semantics of SPARQL queries under OWL 2 Direct Semantics is slightly different from the standard First-Order conjunctive query semantics. For standard First-Order semantics, one would not use an RDF instance mapping but map from anonymous individuals (blank nodes) in the query to elements of the object and data domain for each model of O:

At the time of writing it is unknown whether conjunctive query entailment is decidable under this semantics and the SPARQL semantics seams a more natural choice that allows for practical implementations.

Without restrictions on the use of owl:topDataProperty that connects all objects with all literals, queries such as

would result in infinite solutions. Unlike for RDF and RDFS entailment, where restrictions are placed on possible solutions to restrict the set of actual solutions to a finite set, OWL 2 itself defines restrictions that guarantee finite answers. For owl:topDataProperty, the following requirement has to be met:

Thus, any solution mapping applied to the BGP ?o owl:TopObjectProperty ?d results in an RDF triple that cannot be parsed into an OWL 2 DL axiom as required for the solution mapping to be a solution.

Under OWL 2 Direct Semantics 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. For example an ontology containing the axioms

entails DataPropertyAssertion(:hasAge :Peter "18"^^xsd:int). Since there are infinitely many integers, a SPARQL endpoint cannot answer a query with BGP :Peter :hasAge ?x . :hasAge a owl:DataProperty . by replacing all possible integer values for ?x and then testing entailment. It is also not possible to restrict candidate bindings to the set of data values that occur explicitly in the queried ontology since "18" does not occur in the ontology. One can, however, built one (arbitrary) model for the queried ontology (which is part of any consistency test) and from that model one can identify a finite set of candidate solutions. This finite set of candidates can be used to find the actual solutions for the query.

The defined semantics allows for certain forms of higher order queries. For example, one can use the BGP ?x rdfs:subClassOf ?y to query for pairs of sub- and superclass. Queries in which variables are used in positions that would require bindings from the OWL 2 reserved vocabulary will have an empty answer. This applies to variables that occur in the position of quantifiers. For example, the following query asks whether some or all brothers of Peter are persons:

In functional-style syntax this query corresponds to the axiom ClassAssertion( ?x(:hasBrother :Person) :Peter ). Any solution mapping for the above query must map ?x to owl:SomeValuesFrom or owl:AllValuesFrom in order to result in a set of triples that can be parsed into an OWL 2 DL ontology. Since the triples in the BGP are parsed into a logical annotation-free axiom, condition 2.d) applies, which forbids mappings that use the reserved vocabulary of OWL and the query has an empty answer.

Querying for non-logical axioms is possible due to the combined semantics used for the Direct Semantics entailment regime. For example, if the ontology contains a triple such as ex:myOntology rdf:type owl:Ontology (in FSS Ontology(ex:myOntology ...)), this means that the ontology has IRI ex:myOntology, but the triple ex:myOntology rdf:type owl:Ontology is not entailed by the ontology under Direct Semantics and a query such as

would have no answer when strictly applying the Direct Semantics. Similarly, under strict Direct Semantics it is not possible to query for annotations or declarations. The above definition of the Direct Semantics entailment regime uses, therefore, a kind of combined semantics. The BGP is to be separated into logical and non-logical parts, then Direct Semantics is applied to the logical parts and simple semantics to the non-logical parts. For logical axioms from the BGP that contain annotations, it only makes sense to apply simple semantics. Even when querying for sub- and superclass pairs from an annotated subclass axiom, it does not make sense to compute inferred pairs of sub- and superclasses since each sub- and superclass binding also has to match under simple entailment, which means all inferred sub- and superclass relationships are filtered out.

The EL and the QL profiles of OWL 2 are also defined for Direct Smeantics. 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 such ontologies and is a subset of OWL 2 DL for which the basic reasoning problems can be performed in time that is polynomial with respect to the size of the ontology. OWL 2 QL is aimed at applications that use very large volumes of instance data, and where query answering is the most important reasoning task. In OWL 2 QL, conjunctive query answering can be implemented using conventional relational database systems. Using a suitable reasoning technique, sound and complete conjunctive query answering can be performed in LOGSPACE with respect to the size of the data (assertions). As in OWL 2 EL, polynomial time algorithms can be used to implement the ontology consistency and class expression subsumption reasoning problems. Compared to OWL 2 DL, these two profiles place further restrictions the sets of RDF triples that consitute valid OWL 2 EL and OWL 2 QL ontologies. Thus, systems that support these entailment regimes may reject more inputs than systems that work with all of OWL 2 DL. Consequently, there are also more BGPs that will have an empty answer because the BGP cannot be parsed into axioms that belong to the OWL 2 EL or the OWL 2 QL profile. Nevertheless, OWL 2 DL, EL, and QL can all be used with the Direct Semantics entailment regime.