RDF-star and SPARQL-star

People coming to RDF-star may have wrong ideas about what it is or how to use it. The purpose of this section is to dispel the most common misconceptions.

RDF-star is not syntactic sugar for standard reification . While the latter is a vocabulary that fits into the standard RDF model (abstract syntax), RDF-star extends that model (see 2. Concepts and Abstract Syntax ) with a new construct, namely quoted triples . Note also that the two are not mutually exclusive: standard reification can be used in conjunction with RDF-star.

Unlike reified statements, RDF-star quoted triples are unique: wherever << :employee38 :jobTitle "Assistant Designer" >> appears, it always denotes one and the same thing. This impacts the modeling choices one has to make when using RDF-star; this is further discussed in 2.3 Triples and occurrences .

Finally, quoted triples are referentially opaque. This means that two quoted triples containing distinct but equivalent terms (i.e., coreferences, known to denote the same thing) are nonetheless considered to be different triples. 6.4.4 Referential opacity and the following sections discuss the rationale for this design, and how some form of referential transparency can still be added to RDF-star if and when needed.

For the remainder of this document, examples will assume that the following prefixes have been declared to represent the IRIs shown with them here:

This specification covers many aspects of RDF-star, and not all sections will be of interest to all readers.

Section 2 first defines the concepts and the abstract syntax of RDF-star, to which all following sections refer. The next three sections focus on how users will interact with the abstract syntax, defining the concrete syntaxes , the query language SPARQL-star and its counterpart for updates . Section 6 then defines RDF-star's formal semantics, which lays the foundation for reasoning with RDF-star data. Finally, Section 7 defines an RDF vocabulary capturing the main concepts of RDF-star.

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY , MUST , MUST NOT , and OPTIONAL in this document are to be interpreted as described in BCP 14 [ RFC2119 ] [ RFC8174 ] when, and only when, they appear in all capitals, as shown here.

A system supports RDF-star for input if it supports an input syntax for an RDF 1.1 standard syntax that has additional syntax for quoted triples . Such input syntaxes include those in the RDF-star test suite ( N-Triples-star syntax tests , Turtle-star syntax tests , or TriG-star syntax tests ).

A system supports RDF-star for output if it supports an output syntax for an RDF 1.1 standard syntax that has additional syntax for quoted triples . Such output syntaxes include those in the RDF-star test suite ( N-Triples-star syntax tests , Turtle-star syntax tests , or TriG-star syntax tests ).

A system supports SPARQL-star if it passes the SPARQL-star syntax test suite and the SPARQL-star evaluation test suites.

In the example below, there is a quoted triple, :a :name "Alice" , which is used as the subject for an asserted triple:

PREFIX : <http://www.example.org/> 
:bob :name "Bob" .
<<
:a
:name
"Alice"
>>
:statedBy
:bob
.

The graph of this example has two asserted triples:

1. :bob :name "Bob" .
2. << :a :name "Alice" >> :statedBy :bob .

This graph does not have an asserted triple, :a :name "Alice" , because that triple is not an element of the set of triples.

On the other hand, the graph in the example below contains three asserted triples: the same two as the previous example, and :a :name "Alice" . The latter is used both as an asserted triple and a quoted triple in this graph.

PREFIX : <http://www.example.org/> 
:bob :name "Bob" .
:a :name "Alice" .
<<
:a
:name
"Alice"
>>
:statedBy
:bob
.

There are syntax additions for quoted triples and also for annotation syntax which provides a convenient shortcut in Turtle-star and TriG-star syntaxes. It is used to both assert a triple and have that triple be the subject of further triples. It uses delimiters {| and |} following an asserted triple to make that triple, as a quoted triple , the subject of the RDF-star triples formed by combining it with the enclosed RDF predicate(s) and object(s).

Annotation syntax does not appear in the RDF-star abstract data model. It is only a syntactic short cut and the RDF-star abstract data model does not distinguished how the triples were written.

:a
:name
"Alice"
{|
:statedBy
:bob
;
:recorded
"2021-07-07"^^xsd:date
|}
.

is the same set of triples as:

<< :a :name "Alice" >> :statedBy :bob .
<< :a :name "Alice" >> :recorded "2021-07-07"^^xsd:date .
:a
:name
"Alice"

and RDF-star graph contains three asserted triples.

In this section, we present Turtle-star, an extension of the Turtle format [ TURTLE ] allowing the representation of RDF-star graphs . For the sake of conciseness, we only describe here the differences between Turtle-star and Turtle.

BASE <http://example.org/>
PREFIX : <#> 
_:a :name "Alice" .
<<
_:a
:name

"Alice"

>>
:statedBy
:bob
.

BASE <http://example.org/>
PREFIX : <#>
_:a
:name

"Alice"

{|
:statedBy
:bob
|}
.

This section describes TriG-star, a minimal extension of the TriG format [ TRIG ] using the same production updates described in 3.2 Turtle-star .

A TriG-star document defines an RDF-star dataset , composed of a single default graph and zero or more named graphs , all of which are RDF-star graphs .

BASE <http://example.org/>
PREFIX : <#>
:G {
  _:a :name "Alice" {| :statedBy :bob |} .
}

This section describes N-Triples-star, a minimal extension of the N-Triples format [ N-TRIPLES ] allowing a subject or an object of an RDF-star triple to be a quoted triple .

The [ N-QUADS ] format is extended to describe the N-Quads-star format using the same production updates described in the N-Triples-star Grammar .

An N-Quads-star document defines an RDF-star dataset , composed of a single default graph and zero or more named graphs , all of which are RDF-star graphs .

A conforming N-Quads-star parser MUST parse any valid N-Quads document and additionally parse the subject and object productions from N-Triples-star to generate RDF-star triples which are added to either the default graph or associated named graph , as appropriate.

In the following, we introduce a number of SPARQL-star-specific definitions, which rely on the following notions, defined in SPARQL 1.1 Query Language  [ SPARQL11-QUERY ]: query variable , triple pattern , property path pattern , property path expression , and solution mapping .

A SPARQL-star triple pattern is a 3-tuple that is defined recursively as follows:

1. Every SPARQL triple pattern is a SPARQL-star triple pattern;
2. If t and t' are SPARQL-star triple patterns, x is an RDF term or a query variable , and p is an IRI or a query variable , then ( t ,  p ,  x ), ( x ,  p ,  t ), and ( t ,  p ,  t' ) are SPARQL-star triple patterns.

As for RDF-star triples , a SPARQL-star triple pattern MUST NOT contain itself.

A SPARQL-star basic graph pattern  ( BGP -star) is a set of SPARQL-star triple patterns .

A SPARQL-star property path pattern is a 3-tuple ( s , p , o ) where

• s is either an RDF term , a query variable , or a SPARQL-star triple pattern ,
• p is a property path expression , and
• o is either an RDF term , a query variable , or a SPARQL-star triple pattern .

A SPARQL-star solution mapping  μ is a partial function from the set of all query variables to the set of all RDF-star terms . The domain of μ, denoted by dom(μ), is the set of query variables for which μ is defined.

All notions related to SPARQL solution mappings carry over naturally to SPARQL-star solution mappings. In particular, the definition of compatibility extends naturally to SPARQL-star solution mappings: two SPARQL-star solution mappings μ ₁ and μ ₂ are compatible if, for every variable v that is both in dom(μ ₁ ) and in dom(μ ₂ ), μ ₁ (v) and μ ₂ (v) are the same RDF-star term . In this case, μ ₁ ∪ μ ₂ is also a SPARQL-star solution mapping. Moreover, for any SPARQL-star solution mapping μ we write card[Ω](μ) to denote the cardinality of μ in a multiset Ω of such mappings. Finally, given a BGP -star   B and a SPARQL-star solution mapping μ, we write μ( B ) to denote the result of replacing every variable  v in B for which μ is defined with μ(v).

Next, we aim to carry over the notion of solutions for BGPs to BGP -star . To this end, we first define an auxiliary concept that carries over the notion of an RDF instance mapping  [ RDF11-MT ] to RDF-star.

An RDF-star instance mapping  σ is a partial function from the set of all blank nodes to the set of all RDF-star terms . The domain of σ, denoted by dom(σ), is the set of blank nodes for which σ is defined.

Similar to the corresponding notation for solution mappings, for an RDF-star instance mapping σ and a BGP -star  B we write σ( B ) to denote the result of replacing every blank node  b in B for which σ is defined with σ(b).

Now we are ready to define the notion of solution for BGP -star.

Given a BGP -star   B and an RDF-star graph   G , a SPARQL-star solution mapping  μ is a solution for the BGP -star   B over   G if it has the following two properties

• dom(μ) is equivalent to the set of query variables in  B , and
• there exists an RDF-star instance mapping  σ such that dom(σ) is equivalent to the set of blank nodes in  B and μ(σ( B )) is a subgraph of G .

SPARQL-star is defined to follow the same grammar as SPARQL 1.1, except for the EBNF productions specified below, which replace the productions having the same number (if any) in the original grammar. The parts in which these productions differ from the corresponding productions in the original grammar are marked in bold font. Productions [174] and following have been added and have no counterpart in the original grammar.

This introduces a notation for quoted triple patterns (production [174] ), which is similar to the one defined for quoted triples in 3.2 Turtle-star , but accepting also variables . These quoted triple patterns are allowed in both the subject position ( [75] , [81] ) and the object position ( [80] , [87] ) of SPARQL-star triple patterns , as well as in the short-hand notation for querying collections ( [102] , [103] ).

Additionally, production [65] for values that can be used in the VALUES clause is extended to permit RDF-star triples as possible values, and the set of available built-in functions is extended with the five functions TRIPLE, SUBJECT, PREDICATE, OBJECT, and isTRIPLE ( [121] ) that are defined in 4.4 Function and Operator Definitions .

Yet another extension is that both the Object and the ObjectPath productions now accept an optional annotation pattern after each object. The purpose of this feature is to enable users to use the same kind of annotation syntax that is supported in Turtle-star. As in the case of Turtle-star, the annotation syntax in SPARQL-star is purely syntactic sugar that has to be processed in accordance to the first expansion rule in 4.3.2 Expand Syntax Forms .

A restriction to the use of the annotation syntax in SPARQL-star exists that is not captured by the grammar as defined above: An AnnotationPatternPath may be added only to SPARQL-star property path patterns in which the property path expression is a PredicatePath (i.e., a single IRI) or the keyword a (as a short form for the IRI rdf:type ). Hence, a query such as the following violates this restriction and, thus, is invalid .

SELECT * WHERE {
    ?s :p/:q ?o {| ?pp ?oo |}.
}

While annotation patterns must not be added to property path patterns other than the ones permitted by the restriction above, it is possible to use property path expressions within annotation patterns (but without violating the restriction in the case of nested annotation patterns). For instance, the following query is valid.

SELECT * WHERE {
    ?s ?p ?o {| :p/:q ?oo |}.
}

Based on the SPARQL grammar, the SPARQL specification defines the process of converting graph patterns and solution modifiers in a SPARQL query string into a SPARQL algebra expression  [ SPARQL11-QUERY, Section 18.2 ]. This process must be adjusted to consider the extended grammar introduced above . In the following, any step of the conversion process that requires adjustment is discussed.

SPARQL introduces operators and functions that can be used in an expression of a FILTER clause, a BIND clause, or a SELECT clause (see Section 17.3 and Section 17.4 in [ SPARQL11-QUERY ]). While these operators and functions are defined to operate on RDF terms and query variables , for SPARQL-star they have to be defined to operate on RDF-star terms and query variables . To this end, when using these operators and functions in the context of SPARQL-star, their definitions as given in Section 17.4 of [ SPARQL11-QUERY ] are extended by assuming that any mention of RDF term as a data type for operands is understood to be the type of all RDF-star terms .

SPARQL-star introduces five new functions that are defined as follows (where the data types RDF-star term and RDF-star triple capture all RDF-star terms and all RDF-star triples , respectively).

The modifications to functions and operators for triple terms are:

• Modified sameTerm function (SPARQL 1.1 Section 17.4.1.8 )
• New function sparql-compare for the = operator and other comparison mappings
• Modified RDFterm-equal (SPARQL 1.1 Section 17.4.1.7 )
• Operator mapping for = and other operators (SPARQL 1.1 Section 17.3 )
• Modified ORDER BY (SPARQL 1.1 Section 15.1 )

The SPARQL specification defines a function eval( D ( G ), algebra expression) as the evaluation of an algebra expression with respect to a dataset D having active graph G  [ SPARQL11-QUERY, Section 18.6 ]. Recall that the dataset D in the context of SPARQL-star is an RDF-star dataset and, thus, the active graph G is an RDF-star graph , and so is any other graph in dataset D . The definition of the eval function is recursive; the base case of this definition for SPARQL-star are given as follows:

• For every BGP -star B , eval( D ( G ),  B ) is a multiset Ω that consists of all SPARQL-star solution mappings that are a solution for the BGP -star   B over  G . For every such mapping μ, card[Ω](μ) is the number of distinct RDF-star instance mappings  σ such that dom(σ) is equivalent to the set of blank nodes in  B and μ(σ( B )) is a subgraph of G . (For any SPARQL-star solution mapping μ' that is not a solution for  B over  G , we have that card[Ω](μ')=0; i.e., μ' is not in Ω.)

For any other algebra expression, the SPARQL specification defines algebra operators [ SPARQL11-QUERY ]. These definitions can be extended naturally to operate over multisets of SPARQL-star solution mappings (instead of ordinary solution mappings ). Given this extension, the recursive steps of the definition of the eval function for SPARQL-star are the same as in the SPARQL specification.

In SPARQL, queries can take four forms: SELECT , CONSTRUCT , DESCRIBE , and ASK - see SPARQL1.1 Query, Section 16 [ SPARQL11-QUERY ]. The first of these returns a sequence of solution mappings that contain variable bindings. The second and third both return an RDF graph, and the last returns a boolean value.

The result of the ASK query form is not changed by the introduction of RDF-star, and the result of the CONSTRUCT and DESCRIBE forms can be represented by Turtle-star . However, since the SELECT form deals with returning individual RDF terms, the specific serialization formats for representing such query results need to be extended so that the new quoted triple RDF term can be represented. In this section, we propose extensions for the two most common formats for this purpose: SPARQL 1.1 Query Results JSON Format , and SPARQL Query Results XML Format (Second Edition) .

SPARQL-star Update is an extension of the SPARQL Update language [ SPARQL11-UPDATE ]. As mentioned in SPARQL 1.1 Update, Appendix C  [ SPARQL11-UPDATE ], the grammar of the latter is provided as part of the SPARQL 1.1 Query grammar . Similarly, the grammar of SPARQL-star Update is provided as part of the grammar of the SPARQL-star query language, which is defined by the SPARQL 1.1 Query grammar with the extensions specified in 4.2 Grammar . As a result of these extensions, the production rules QuadData and QuadPattern , which are used in the definition of SPARQL Update [ SPARQL11-UPDATE ], are extended to capture nested triples and nested triple patterns as demonstrated in the examples above.

The semantics of SPARQL-star Update operations can also be defined by a simple extension of the formalization of SPARQL Update  [ SPARQL11-UPDATE ]. This extension assumes that any mention of "RDF triple" or "triple" in the formalization of SPARQL Update is understood as an RDF-star triple . Similarly, "RDF graph" and "solution mapping" are understood as RDF-star graph and SPARQL-star solution mapping , respectively. Any mention of the "evaluation function eval()" is understood as the eval function for SPARQL-star as defined in 4.6 Evaluation Semantics .

We define a mapping L that maps any IRI or literal t to a literal with:

• xsd:string as its datatype , and
• the canonical N-Triples representation of t as its lexical form  [ N-TRIPLES ]. If t is itself a literal with the xsd:string datatype , the representation MUST simply match the STRING_LITERAL_QUOTE production (i.e., without an explicit datatype IRI ).

Given an RDF-star graph G , the following steps define the unstar mapping , which transform G into an RDF graph that we call unstar ( G ).

After these steps, unstar ( G ) is an RDF graph , as it contains no quoted triples . Note that if G contains no quoted triple and no IRI in the unstar: namespace, then unstar ( G ) =  G .

Following RDF 1.1 Semantics , we define the notions of satisfiability and entailment for RDF-star graphs . Given two RDF-star graphs G and H :

• We say that G is star- satisfiable (resp. star- unsatisfiable ) if and only if unstar ( G ) is simply satisfiable (resp. simply unsatisfiable ).
• We say that H is star- entailed by (resp. star- equivalent to) G if and only if unstar ( H ) is simply entailed by (resp. simply equivalent to) unstar ( G ).

It is easy to see that, in the special case of RDF graphs G and H (i.e. RDF-star graphs containing no quoted triple ), G is star- satisfiable if and only if G is simply satisfiable , and G star- entails H if and only if G simply entails H . This is trivially true if G and H do not contain any unstar: IRI (in which case they are left unchanged by the unstar mapping ). But this is also true if they do contain such IRIs (as the renaming performed by the unstar mapping has no significant impact on the semantic relationships between the two graphs). Star- entailment can therefore be considered as a natural extension of simple entailment to RDF-star graphs .

RDF 1.1 Semantics  [ RDF11-MT ] defines the merging of two or more RDF graphs as "[taking their] union after forcing any shared blank nodes, which occur in more than one graph, to be distinct in each graph." Note that, in the case of RDF-star graphs , any blank node in the constituent terms of that graph is governed by the definition above, not only those in the subject or object position of some asserted triple .

#### graph #1
:alice :says
  << _:x :name "bob" >>,
  << _:x :likes :alice >>.
#### graph #2
:bob :says
  << :alice :hates _:x >>.
#### Merge of graphs #1 and #2 →
:alice :says
  << _:y :name "bob" >>,
  << _:y :likes :alice >>.
:bob :says
<<
:alice
:hates
_:z
>>.