RDF-star and SPARQL-star

1. Introduction

1.1 Background and Motivation

This section is non-normative.

The RDF data model lets you state facts in three-part subject-predicate-object statements known as triples. For example, with a single RDF triple, you can say that employee38 has a familyName of "Smith". A triple's predicate is a property specified with an IRI (an Internationalized version of a URI), identifying that property in a globally unambiguous way. A triple's subject and object can each be an IRI referencing any entity, and the object can also be a literal value such as "Smith" or data of other types such as dates, numbers, or Boolean values.

Sometimes, we want the subject or object of a triple to refer to another triple. For example, the statement "according to employee22, employee38 has a jobTitle of 'Assistant Designer'" can be modeled as a triple with "according to" as its predicate, employee22 as its object, and another triple as its subject, namely the triple "employee38 has a jobTitle of 'Assistant Designer'". This use of a triple as the subject or object resource of another triple so that we can say things about that triple is known as reification. The concept of reification has always been part of RDF, but expressing it in most RDF concrete syntaxes such as Turtle and N-Triples, as well as processing or querying it with SPARQL, has been verbose and cumbersome [RDF-STAR-FOUNDATION].

1.2 Overview

This section is non-normative.

This specification describes RDF-star, an extension of RDF's conceptual data model and concrete syntaxes, providing a more compact form of reification. This model and syntaxes enable the creation of concise triples that reference other triples as subject and object resources. Triples that include a triple as a subject or an object are known as RDF-star triples. The following dataset shows the example RDF-star triples from above using the Turtle-star syntax, which uses double angle brackets to enclose a triple serving as a subject or object resource:

Example 1

@prefix :    <http://www.example.org/> .

:employee38 :familyName "Smith" .
<< :employee38 :jobTitle "Assistant Designer" >> :accordingTo :employee22 .

After declaring a prefix so that IRIs can be abbreviated, the first triple in this example asserts that employee38 has a familyName of "Smith". Note that this dataset does not assert that employee38 has a jobTitle of "Assistant Designer"; it says that employee22 has made that claim. In other words, the triple "employee38 has a jobTitle of 'Assistant Designer'" is not what we call an asserted triple, like "employee38 has a familyName of 'Smith'" above; rather, it is known as an embedded triple.

If we added the triple :employee38 :jobTitle "Assistant Designer" below the triple about employee22's claim in the example above, then this triple about employee38's jobTitle would be both an embedded triple and an asserted one. This pattern is quite common, so Turtle-star offers a dedicated syntax for it, called the annotation syntax, illustrated in Example 2 below. Note that this construct is purely syntactic sugar, as it can be expanded using only the double angle brackets.

Example 2

@prefix :    <http://www.example.org/> .

:employee38
    :familyName "Smith" ;
    :jobTitle "Assistant Designer" {| :accordingTo :employee22 |} .

# this is equivalent to:
#
# :employee38
#     :familyName "Smith" ;
#     :jobTitle "Assistant Designer" .
# << :employee38 :jobTitle "Assistant Designer" >> :accordingTo :employee22 .

This specification also describes an extension to the SPARQL Protocol and Query Language known as SPARQL-star for the querying of RDF-star triples. For example, the following SPARQL-star query asks "who has made any claims about employee38?"

Example 3

PREFIX : <http://www.example.org/> 

SELECT ?claimer WHERE {
   ?claimer :claims << :employee38 ?property ?value >>
}

SPARQL can also be used to update RDF data, and SPARQL-star also extends that part. For example, the following SPARQL-star adds all the statements made by employee22 about employee38 as asserted triples, annotating them as "confirmed".

Example 4

PREFIX : <http://www.example.org/>

INSERT {
  :employee38 ?p ?o {| :status "confirmed" |}
} WHERE {
   << :employee38 ?p ?o >> :accordingTo :employee22
}

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

`:`	`<http://www.example.org/>`
`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#>`
`prov:`	`<http://www.w3.org/ns/prov#>`
`dc:`	`<http://purl.org/dc/elements/1.1/>`
`dct:`	`<http://purl.org/dc/terms/>`

1.3 Conformance

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, and MUST NOT 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.

Issue 3: Do we need more things in the 'conformance' section? later process

For the moment, we only have the boilerplate text generated by respec.

2. Concepts and Abstract Syntax

In the following, we introduce a number of definitions specific to SPARQL-star, which rely on the following notions (extending some of them) defined in RDF 1.1 Concepts and Abstract Syntax [RDF11-CONCEPTS]: blank node, default graph, graph name, IRI, literal, named graphs, object, predicate, RDF dataset, RDF graph, RDF triple, and subject

An RDF-star graph is a set of RDF-star triples.

An RDF-star triple is a 3-tuple defined recursively as follows:

any RDF triple is an RDF-star triple;
if t and t' are RDF-star triples, s is an IRI or a blank node, p is an IRI, o is an IRI, a blank node or a literal, then (t, p, o), (s, p, t) and (t, p, t') are RDF-star triples.

As for RDF triples, we call the 3 components of an RDF-star triple its subject, predicate and object, respectively. From the definitions above, it follows that any RDF graph is also an RDF-star graph. Note also that, by definition, an RDF-star triple cannot contain itself and cannot be nested infinitely.

IRIs, literals, blank nodes and RDF-star triples are collectively known as RDF-star terms.

For every RDF-star triple t, we define its constituent terms (or simply constituents) as the set containing its subject, its predicate, its object, plus all the constituent terms of its subject and/or its object if they are themselves RDF-star triples. By extension, we define the constituent terms of an RDF-star graph to be the union set of the constituent terms of all its triples.

Consider the following RDF-star triple (represented in Turtle-star):

Example 5

<< _:a :name "Alice" >> :statedBy :bob.

Its set of constituent terms comprises the IRIs :name, :statedBy, :bob, the blank node _:a, the literal "Alice", and the triple << _:a :name "Alice" >>.

An RDF-star triple used as the subject or object of another RDF-star triple is called an embedded triple. An RDF-star triple that is an element of an RDF-star graph is called an asserted triple. Note that, in a given RDF-star graph, the same triple MAY be both embedded and asserted.

An RDF-star dataset is a collection of RDF-star graphs, and comprises:

Exactly one default graph, being an RDF-star graph. The default graph does not have a name and MAY be empty.
Zero or more named graphs. Each named graph is a pair consisting of either an IRI or a blank node (called the graph name), and an RDF-star graph. Graph names are unique within an RDF-star dataset.

Again, this definition is an extension of the notion of RDF dataset, hence it follows that any RDF dataset is also an RDF-star dataset.

2.1 Triples and occurrences

This section is non-normative.

According to the definitions above, an RDF-star triple is an abstract entity whose identity is entirely defined by its subject, predicate, and object. Conversely, given three RDF-star terms s, p, and o, there is exactly and only one RDF-star triple with subject s, predicate p, and object o. This unique triple (s, p, o) can be embedded as the subject or object of multiple other triples, but must be assumed to represent the same thing everywhere it occurs, just like the same IRI p is assumed to represent the same thing everywhere it occurs.

In some situations, however, it might be necessary to distinguish the occurrences of a triple in different graphs. Consider the following sentence: "The triple <http://example.org/s> <http://example.org/p> <http://example.org/o> in (the graph represented by) file1.ttl was added by Alice, and the same triple in file2.ttl was added by Bob." Note that the words "same triple" in this sentence may be confusing, because although the triple (as an abstract entity) is the same, its respective occurrences are different things, each within a different file and with a different author (this is known, in philosophy and linguistics, as the type-token distinction). As the embedded triple represents a unique thing, adequately conveying the meaning of the sentence above requires additional nodes for representing the two distinct occurrences. One possible solution is illustrated in the following example (using the Turtle-star concrete syntax described in the next section).

Example 6

_:a :occurrenceOf << :s :p :o >> ;
    :in <file1.ttl> ;
    dct:creator :alice.
_:b :occurrenceOf << :s :p :o >> ;
    :in <file2.ttl> ;
    dct:creator :bob.

3. Concrete Syntaxes

This section defines the following concrete syntaxes:

§ 3.1 Turtle-star
§ 3.2 TriG-star
§ 3.3 N-Triples-star
§ 3.4 N-Quads-star
§ 3.5 Other Concrete Syntaxes

Changes for SPARQL-star are given in § 4.2 Grammar and the changes for the result set formats in § 4.7 Query Result Formats.

3.1 Turtle-star

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.

3.1.1 Grammar

Turtle-star is defined to follow the same grammar as Turtle, except for the EBNF productions specified below, which replace the productions having the same number (if any) in the original grammar.

[8]	`objectList`	::=	object annotation`?` `(` `','` object annotation`?` `)*`
[10]	`subject`	::=	iri `\|` BlankNode `\|` collection `\|` embTriple
[12]	`object`	::=	iri `\|` BlankNode `\|` collection `\|` blankNodePropertyList `\|` literal `\|` embTriple
[27t]	`embTriple`	::=	`'<<'` embSubject verb embObject `'>>'`
[28t]	`embSubject`	::=	iri `\|` BlankNode `\|` embTriple
[29t]	`embObject`	::=	iri `\|` BlankNode `\|` literal `\|` embTriple
[30t]	`annotation`	::=	`'{\|'` predicateObjectList `'\|}'`

Note

As with N-Triples-star, the changes are that subject and object productions have been extended to accept embedded triples, which are described by the new productions 27t to 30t. Note that embedded triples accept a more restricted range of subject and object expressions than asserted triples. Additionally, the objectList production now accepts an optional annotation after each object.

3.1.2 Parsing

A Turtle-star parser is similar to a Turtle parser as defined in Section 7 of the Turtle specification [TURTLE], with an additional item in its state :

RDF-star Term curObject — The curObject is bound to the embObject production.

Additionally, the curSubject can be bound to any RDF-star term (including an embedded triple).

A Turtle-star document defines an RDF-star graph composed of a set of RDF-star triples. The subject and embSubject productions set the curSubject. The verb production sets the curPredicate. The object and embObject productions set the curObject. Finishing the object production, an RDF-star triple curSubject curPredicate curObject is produced (added to the RDF-star graph).

Beginning the embTriple production records the curSubject and curPredicate. Finishing the embTriple production yields the RDF-star triple curSubject curPredicate curObject and restores the recorded values of curSubject and curPredicate.

Beginning the annotation production records the curSubject and curPredicate, and sets the curSubject to the RDF-star triple curSubject curPredicate curObject. Finishing the annotation production restores the recorded values of curSubject and curPredicate.

All other productions MUST be handled as specified by Section 7 of the Turtle specification [TURTLE], while still applying the changes above recursively.

3.1.2.1 Discussion

This section is non-normative.

This section describes parser behavior when parsing a Turtle-star document that contains embedded triples and annotations.

Consider a Turtle-star document that describes an RDF triple, and also uses that triple as an embedded triple as the subject of another RDF-star triple:

Example 7: Turtle-star embedded triples

@base <http://example.org/> .
@prefix : <#> .
_:a :name "Alice" .
<< _:a :name "Alice" >> :statedBy :bob .

The usual process of parsing a Turtle document applies with the addition of matching the embedded triple << _:a :name "Alice" >> as part of the subject production. The resulting RDF-star graph consists of two RDF-star triples:

(b, http://example.org/#name, "Alice"), where b is a blank node
((b, http://example.org/#name, "Alice"), http://example.org/#statedBy, http://example.org/#bob/), where b is the same blank node

Because the above example includes the triple (b, http://example.org/#name, "Alice") as an asserted triple, the same RDF-star graph may also be represented by using the Turtle-star annotation syntax as follows:

Example 8: Turtle-star annotated triples

@base <http://example.org/> .
@prefix : <#> .
_:a :name "Alice" {| :statedBy :bob |} .

In this case, the objectList production matches the annotation production on {| :source :bob |} after parsing the object production on "Alice". At this point, the curSubject, curPredicate, and curObject are saved, and a new RDF-star triple _:a :name "Alice" is created and used as curSubject while processing the annotation production.

3.2 TriG-star

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

Note

RDF-star describes embedded triples, which are not necessarily present in any named graph, or within the default graph.

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.

3.2.1 Grammar

TriG-star is defined to follow the same grammar as TriG, except for the EBNF productions specified below, which replace the productions having the same number (if any) in the original grammar.

The TriG-star grammar contains exactly the same production updates described in § 3.1.1 Grammar with an additional change to the triplesOrGraph production.

[3g]	`triplesOrGraph`	::=	labelOrSubject `(` wrappedGraph `\|` predicateObjectList `'.' )` `\|` embTriple predicateObjectList `'.'`
[8]	`objectList`	::=	object annotation`?` `(` `','` object annotation`?` `)*`
[10]	`subject`	::=	iri `\|` BlankNode `\|` collection `\|` embTriple
[12]	`object`	::=	iri `\|` BlankNode `\|` collection `\|` blankNodePropertyList `\|` literal `\|` embTriple
[27t]	`embTriple`	::=	`'<<'` embSubject verb embObject `'>>'`
[28t]	`embSubject`	::=	iri `\|` BlankNode `\|` embTriple
[29t]	`embObject`	::=	iri `\|` BlankNode `\|` literal `\|` embTriple
[30t]	`annotation`	::=	`'{\|'` predicateObjectList `'\|}'`

3.2.2 Parsing

TriG-star parsing uses the same updates described in § 3.1.2 Parsing as applied to Section 5 of the TriG specification [TRIG].

Note

As with Turtle-star, the embTriple and annotation are used to set either the curSubject or curObject, and do not directly add the associated embedded triple to curGraph. Subsequent productions which use either curSubject or curObject may result in adding triples to curGraph.

A conforming TriG-star parser MUST parse any valid TriG document and any valid Turtle-star document in addition to the Turtle-star grammar productions contained within a named graph.

3.2.3 Discussion

This section is non-normative.

TriG-star allows the same expressivity as Turtle-star with the addition of allowing embedded triples and annotations within named graphs.

Example 9: TriG-star annotated triples

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

The resulting RDF-star dataset consists of an empty default graph, and a graph named http://example.org/#G with two RDF-star triples:

(b, http://example.org/#name, "Alice"), where b is a blank node
((b, http://example.org/#name, "Alice"), http://example.org/#statedBy, http://example.org/#bob/), where b is the same blank node

3.3 N-Triples-star

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 an embedded triple.

3.3.1 Grammar

N-Triples-star is defined to follow the same grammar as the N-Triples Grammar, except for the EBNF productions specified below, which replace the productions having the same number (if any) in the original grammar.

[3]	`subject`	::=	IRIREF `\|` BLANK_NODE_LABEL `\|` embTriple
[5]	`object`	::=	IRIREF `\|` BLANK_NODE_LABEL `\|` literal `\|` embTriple
[7t]	`embTriple`	::=	"<<" subject predicate object ">>"

Note

The changes are subject and object productions have been extended to accept embedded triples, which are described by the new production 7.

3.3.2 Parsing

In contrast to [N-TRIPLES], N-Triples-star allows recursion on the subject and object productions.

An N-Triples-star document defines an RDF-star graph composed of a set of RDF-star triples. The triple production produces an RDF-star triple composed of a subject, predicate, and object.

In addition to the Term Constructors defined in [N-TRIPLES], an additional constructor is defined for embTriple of type RDF-star triple defined by the terms constructed for subject, predicate, and object.

All other productions MUST be handled as specified by Section 8.1 of the N-Triples specification [N-TRIPLES], while still applying the changes above recursively.

3.4 N-Quads-star

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.

Note

As RDF-star describes embedded triples and not embedded quads, the graphLabel component of an N-Quads statement does not apply to the embTriple component.

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.

3.5 Other Concrete Syntaxes

This section is non-normative.

While this document specifies a small number of concrete syntaxes, nothing prevents other concrete syntaxes of RDF-star from being proposed. In particular, syntaxes such as RDF/XML [RDF-SYNTAX-GRAMMAR], and JSON-LD [JSON-LD], could be extended to support RDF-star.

4. SPARQL-star Query Language

This Section introduces SPARQL-star, which is an RDF-star-aware extension of the RDF query language SPARQL [SPARQL11-QUERY]; i.e., SPARQL-star can be used to query RDF-star graphs.

4.1 Initial Definitions

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]: RDF term, 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:

Every SPARQL triple pattern is a SPARQL-star triple pattern;
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.

Note

The notion of a SPARQL-star solution mapping extends the notion of a standard SPARQL solution mapping; that is, every SPARQL solution mapping is a SPARQL-star solution mapping. However, in contrast to SPARQL solution mappings, SPARQL-star solution mappings may map variables also to RDF-star triples.

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.

4.2 Grammar

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.

[65]	`DataBlockValue`	::=	EmbTriple `\|` iri `\|` RDFLiteral `\|` NumericLiteral `\|` BooleanLiteral `\|` `'UNDEF'`
[75]	`TriplesSameSubject`	::=	VarOrTermOrEmbTP PropertyListNotEmpty `\|` TriplesNode PropertyList
[80]	`Object`	::=	GraphNode AnnotationPattern`?`
[81]	`TriplesSameSubjectPath`	::=	VarOrTermOrEmbTP PropertyListPathNotEmpty `\|` TriplesNode PropertyListPath
[87]	`ObjectPath`	::=	GraphNodePath AnnotationPatternPath`?`
[104]	`GraphNode`	::=	VarOrTermOrEmbTP `\|` TriplesNode
[105]	`GraphNodePath`	::=	VarOrTermOrEmbTP `\|` TriplesNodePath
[119]	`PrimaryExpression`	::=	BrackettedExpression `\|` BuiltInCall `\|` iriOrFunction `\|` RDFLiteral `\|` NumericLiteral `\|` BooleanLiteral `\|` Var `\|` ExprEmbTP
[121]	`BuiltInCall`	::=	Aggregate `\|` `'STR'` `'('` Expression `')'` `\|` `'LANG'` `'('` Expression `')'` `\|` `'LANGMATCHES'` `'('` Expression `')'` `\|` `'DATATYPE'` `'('` Expression `')'` `\|` `'BOUND'` `'('` Var `')'` `\|` `'IRI'` `'('` Expression `')'` `\|` `'URI'` `'('` Expression `')'` `\|` `'BNODE'` `(` `'('` Expression `')'` `\|` NIL `)` `\|` `'RAND'` NIL `\|` `'ABS'` `'('` Expression `')'` `\|` `'CEIL'` `'('` Expression `')'` `\|` `'FLOOR'` `'('` Expression `')'` `\|` `'ROUND'` `'('` Expression `')'` `\|` `'CONCAT'` ExpressionList `\|` SubstringExpression `\|` `'STRLEN'` `'('` Expression `')'` `\|` StrReplaceExpression `\|` `'UCASE'` `'('` Expression `')'` `\|` `'LCASE'` `'('` Expression `')'` `\|` `'ENCODE_FOR_URI'` `'('` Expression `')'` `\|` `'CONTAINS'` `'('` Expression `','` Expression `')'` `\|` `'STRSTARTS'` `'('` Expression `','` Expression `')'` `\|` `'STRENDS'` `'('` Expression `','` Expression `')'` `\|` `'STRBEFORE'` `'('` Expression `','` Expression `')'` `\|` `'STRAFTER'` `'('` Expression `','` Expression `')'` `\|` `'YEAR'` `'('` Expression `')'` `\|` `'MONTH'` `'('` Expression `')'` `\|` `'DAY'` `'('` Expression `')'` `\|` `'HOURS'` `'('` Expression `')'` `\|` `'MINUTES'` `'('` Expression `')'` `\|` `'SECONDS'` `'('` Expression `')'` `\|` `'TIMEZONE'` `'('` Expression `')'` `\|` `'TZ'` `'('` Expression `')'` `\|` `'NOW'` NIL `\|` `'UUID'` NIL `\|` `'STRUUID'` NIL `\|` `'MD5'` `'('` Expression `')'` `\|` `'SHA1'` `'('` Expression `')'` `\|` `'SHA256'` `'('` Expression `')'` `\|` `'SHA384'` `'('` Expression `')'` `\|` `'SHA512'` `'('` Expression `')'` `\|` `'COALESCE'` ExpressionList `\|` `'IF'` `'('` Expression `','` Expression `','` Expression `')'` `\|` `'STRLANG'` `'('` Expression `','` Expression `')'` `\|` `'STRDT'` `'('` Expression `','` Expression `')'` `\|` `'sameTerm'` `'('` Expression `','` Expression `')'` `\|` `'isIRI'` `'('` Expression `')'` `\|` `'isURI'` `'('` Expression `')'` `\|` `'isBLANK'` `'('` Expression `')'` `\|` `'isLITERAL'` `'('` Expression `')'` `\|` `'isNUMERIC'` `'('` Expression `')'` `\|` RegexExpression `\|` ExistsFunc `\|` NotExistsFunc `\|` `'TRIPLE'` `'('` Expression `','` Expression `','` Expression `')'` `\|` `'SUBJECT'` `'('` Expression `')'` `\|` `'PREDICATE'` `'('` Expression `')'` `\|` `'OBJECT'` `'('` Expression `')'` `\|` `'isTRIPLE'` `'('` Expression `')'`
[174]	`EmbTP`	::=	`'<<'` EmbSubjectOrObject Verb EmbSubjectOrObject `'>>'`
[175]	`EmbTriple`	::=	`'<<'` DataValueTerm `(` iri `\|` `'a'` `)` DataValueTerm `'>>'`
[176]	`EmbSubjectOrObject`	::=	Var `\|` BlankNode `\|` iri `\|` RDFLiteral `\|` NumericLiteral `\|` BooleanLiteral `\|` EmbTP
[177]	`DataValueTerm`	::=	iri `\|` RDFLiteral `\|` NumericLiteral `\|` BooleanLiteral `\|` EmbTriple
[178]	`VarOrTermOrEmbTP`	::=	Var `\|` GraphTerm `\|` EmbTP
[179]	`AnnotationPattern`	::=	`'{\|'` PropertyListNotEmpty `'\|}'`
[180]	`AnnotationPatternPath`	::=	`'{\|'` PropertyListPathNotEmpty `'\|}'`
[181]	`ExprEmbTP`	::=	`'<<'` ExprVarOrTerm Verb ExprVarOrTerm `'>>'`
[182]	`ExprVarOrTerm`	::=	iri `\|` RDFLiteral `\|` NumericLiteral `\|` BooleanLiteral `\|` Var `\|` ExprEmbTP

This introduces a notation for embedded triple patterns (production [174]), which is similar to the one defined for embedded triples in § 3.1 Turtle-star, but accepting also variables. These embedded 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.

Note

As defined for all keywords in SPARQL, the names of the five new built-in functions added by SPARQL-star are matched in a case-insensitive manner.

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.

Example 10

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.

Example 11

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

4.3 Translation to the Algebra

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.

4.3.1 Variable Scope

As a basis of the translation, the SPARQL specification introduces a notion of in-scope variables. To cover the new syntax elements introduced in § 4.2 Grammar this notion MUST be extended as follows.

A variable is in-scope of a BGP-star B if the variable occurs in B, which includes an occurrence in any embedded triple pattern in B (independent of the level of nesting).
A variable is in-scope of a property path pattern if the variable occurs in that pattern, which includes an occurrence in any embedded triple pattern in the pattern (independent of the level of nesting).

4.3.2 Expand Syntax Forms

The translation process starts with expanding abbreviations for IRIs and triple patterns [SPARQL11-QUERY, Section 18.2.2.1]. This step MUST be extended in three ways:

Annotation patterns MUST be replaced by additional SPARQL-star triple patterns that have the annotated triple pattern as an embedded triple pattern in their subject position.
Example 12: Expanding annotations to embedded triple patterns
For instance, the following syntax expression:
```
?x :p :o1 {| :ap1 ?y;
             :ap2 ?z |} ,
      :o2 {| :ap3 ?z |} .

?x :p :o3 {| :ap4/:ap5 ?w } .
```
must be replaced by
```
?x :p :o1, o2 .
<<?x :p :o1>> :ap1 ?y ;
              :ap2 ?z .
<<?x :p :o2>> :ap3 ?z .

?x :p :o3 .
<<?x :p :o3>> :ap4/:ap5 ?w .
```
Abbreviations for triple patterns with embedded triple patterns MUST be expanded as if each embedded triple pattern was a variable (or an RDF term).
Example 13: Expanding abbreviations for triple patterns with embedded triple patterns
For instance, the following syntax expression:
```
<<?c a owl:Class>> dct:source ?src ;
    :entailing <<?c a rdfs:Class>> .
```
must be expanded to
```
<<?c a owl:Class>> dct:source ?src .
<<?c a owl:Class>> :entailing <<?c a rdfs:Class>> .
```
Abbreviations for IRIs in all embedded triple patterns MUST be expanded.
Example 14: Expanding IRI abbreviations
For instance, the embedded triple pattern
```
<<?c a rdfs:Class>>
```
must be expanded to
```
<< ?c <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2000/01/rdf-schema#Class>>>
```

4.3.3 Translate Property Path Patterns

The translation of property path patterns has to be adjusted because the extended grammar allows for SPARQL-star property path patterns whose subject or object is a SPARQL-star triple pattern.

The translation as specified in the W3C specification distinguishes four cases. The first three of these cases do not require adjustment because they are taken care of either by recursion or by the adjusted translation of basic graph patterns (as defined in § 4.3.4 Translate Basic Graph Patterns below). However, the fourth case MUST be adjusted as follows.

Let X P Y be a string that corresponds to the fourth case in [SPARQL11-QUERY, Section 18.2.2.4]. Given the grammar introduced in § 4.2 Grammar, X and Y may be an RDF term, a variable, or an embedded triple pattern, respectively (and P is a property path expression). The string X P Y is translated to the algebra expression Path(X’,P,Y’) where X’ and Y’ are the result of calling a function named Lift for X and Y, respectively. For some input string Z (such as X or Y) that can be an RDF term, a variable, or an embedded triple pattern, the function Lift is defined recursively as follows:

If Z is an embedded triple pattern <<S,P,O>> then return the SPARQL-star triple pattern (Lift(S), P, Lift(O));
Otherwise, return Z.

Note

The purpose of this translation step is to convert any property path pattern as can be written based on the extended grammar for SPARQL-star (cf. § 4.2 Grammar) into a SPARQL-star property path pattern as considered in the algebra. To this end, the function Lift translates every embedded triple pattern as can be written in the SPARQL-star syntax into a SPARQL-star triple pattern.

4.3.4 Translate Basic Graph Patterns

After translating property path patterns, the translation process collects any adjacent triple patterns [...] to form a basic graph pattern [SPARQL11-QUERY, Section 18.2.2.5]. This step has to be adjusted because triple patterns in the extended syntax may have an embedded triple pattern in their subject position or in their object position (or in both). To ensure that every result of this step is a BGP-star, before adding a triple pattern to its corresponding collection, its subject and object MUST be replaced by the result of calling function Lift for the subject and the object, respectively.

4.4 Function and Operator Definitions

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)

4.4.1 TRIPLE

RDF-star triple TRIPLE ( RDF-star term term1, RDF-star term term2, RDF-star term term3 )

If the 3-tuple (term1, term2, term3) is an RDF-star triple, the function returns this triple. If the 3-tuple is not an RDF-star triple, then the function raises an error.

4.4.2 SUBJECT

RDF-star term SUBJECT ( RDF-star triple triple )

If triple is an RDF-star triple, the function returns the subject of this triple. Passing anything other than an RDF-star triple is an error.

4.4.3 PREDICATE

RDF-star term PREDICATE ( RDF-star triple triple )

If triple is an RDF-star triple, the function returns the predicate of this triple. Passing anything other than an RDF-star triple is an error.

4.4.4 OBJECT

RDF-star term OBJECT ( RDF-star triple triple )

If triple is an RDF-star triple, the function returns the object of this triple. Passing anything other than an RDF-star triple is an error.

4.4.5 isTRIPLE

xsd:boolean isTRIPLE ( RDF-star term term )

Returns true if term is an RDF-star triple. Returns false otherwise.

4.4.6 Embedded Triple Expression

RDF-star triple << RDF-star term term1, RDF-star term term2, RDF-star term term3 >>

An Embedded Triple Expression <<S P O>>, where S, P and O conform to ExprVarOrTerm, is evaluated as TRIPLE(S, P, O).

4.4.7 sameTerm

xsd:boolean sameTerm (term, term)

The function sameTerm is extended to support term comparison for RDF-star triple terms by defining:

Extended Definition: sameTerm

If both arguments are RDF-star triple terms:

sameTerm(<<S1 P1 O1>>, <<S2 P2 O2>>)

is evaluated as

sameTerm(S1, S2) && sameTerm(P1, P2) && sameTerm(O1, O2)

This is applied recursively.

If one argument is an RDF-star triple term and the other argument is not, the result is false.

4.4.8 sparql-compare

The function sparql-compare is defined to support value-comparison operators such as = and ORDER BY.

xsd:boolean sparql-compare (RDF-star term, RDF-star term)

The function sparql-compare returns -1, 0, 1, or throws an error, based on the comparison of two RDF-star terms. When comparing two RDF-star triple terms, comparison is by pairwise comparison of subject, then predicate, then object.

Definition: sparql-compare

If neither A nor B is an RDF-star triple term, compare by SPARQL 1.1 operators <, =, >) and return the comparison value (-1, 0, +1) or throw an error as defined by SPARQL 1.1.
If either A or B is an RDF-star triple term, and the other is not an RDF-star triple term, then error.
If sparql-compare(SUBJECT(A), SUBJECT(B)) != 0, then return this value.
If sparql-compare(PREDICATE(A), PREDICATE(B)) != 0, then return this value.
Return sparql-compare(OBJECT(A), OBJECT(B))

4.4.9 RDFterm-equal

The function RDFterm-equal is the default dispatch for the = operator.

This is extended to cover RDF-star terms so that it returns true if term1 and term2 are both RDF-star triple terms and RDFterm-equal is true for pairwise comparison of the component RDF terms.

Extended Definition: RDFTerm-equal

If exactly one of the arguments is an RDF-star triple term, return false.

If both arguments are RDF-star triple terms:

RDFterm-equal(<<S1 P1 O1>>, <<S2 P2 O2>>)

is evaluated as

RDFterm-equal(S1, S2) && RDFterm-equal(P1, P2) && RDFterm-equal(O1, O2)

It produces an error if matching RDF terms in nested RDF triple terms when both are literals but not the same RDF term. This is the same as the existing RDFterm-equal. Operator mapping overrides this behavior.

The case of two RDF-star triple terms is covered by the operator dispatch mappings and covers cases involving literals.

4.4.10 Operator Mappings

New operator mappings are added for RDF-star triple terms for section SPARQL 1.1 Query 17.3 Operator Mapping

SPARQL Binary Operators (SPARQL-star)
Operator	Type(A)	Type(B)	Evaluation	Result type
SPARQL-star Tests
A = B	RDF triple term	RDF triple term	op:numeric-equal(sparql-compare(A, B), 0)	xsd:boolean
A != B	RDF triple term	RDF triple term	fn:not(op:numeric-equal(sparql-compare(A, B), 0))	xsd:boolean
A < B	RDF triple term	RDF triple term	op:numeric-equal(sparql-compare(A, B), -1)	xsd:boolean
A <= B	RDF triple term	RDF triple term	fn:not(op:numeric-equal(sparql-compare(A, B), 1))	xsd:boolean
A > B	RDF triple term	RDF triple term	op:numeric-equal(sparql-compare(A, B), 1)	xsd:boolean
A >= B	RDF triple term	RDF triple term	fn:not(op:numeric-equal(sparql-compare(A, B), -1))	xsd:boolean

4.4.11 Triple terms with ORDER BY

There is an added item to the ordering of terms when they would not otherwise be ordered. RDF-star triple terms are placed last (highest).

(Lowest) no value assigned to the variable or expression in this solution.
Blank nodes
IRIs
RDF literals
RDF-star triple terms

RDF-star triple terms are compared using the < operator.

While SPARQL-star does not define a total ordering of all possible RDF-star terms, implementations should provide some ordering for ORDER BY that does not change between queries if the data has not changed.

4.5 Examples and Discussion

This section is non-normative.

By the evaluation semantics of SPARQL-star as defined in § 4.6 Evaluation Semantics, the five new built-in functions defined above can be used in exactly the same manner as the functions defined in the SPARQL 1.1 spec. For instance, the following SPARQL-star query retrieves every asserted triple that is both contained in the default graph of the queried RDF-star dataset and has an embedded triple as its subject.

Example 15

SELECT ?t WHERE {
  ?s ?p ?o .
  BIND( TRIPLE(?s,?p,?o) AS ?t )
  FILTER( isTRIPLE(SUBJECT(?t)) )
}

Instead of accessing the subject of the triples in the FILTER after the BIND clause, as was done in the previous query, a semantically equivalent query may apply the FILTER directly on the variable ?s, as follows:

Example 16

SELECT ?t WHERE {
  ?s ?p ?o .
  BIND( TRIPLE(?s,?p,?o) AS ?t )
  FILTER( isTRIPLE(?s) )
}

While the triples that the previous example queries bind to variable ?t occur in the queried data, the TRIPLE function can be used to construct triples that may not be in the data. For instance, the following query uses the subject of each asserted triple in the default graph of the queried RDF-star dataset to construct another triple, and bind it to the variable ?t. Notice that the result of this query contains as many SPARQL-star solution mappings as there are asserted triples in the queried graph, and there may be duplicates in the result if multiple asserted triples have the same subject.

Example 17

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?t WHERE {
  ?s ?p ?o .
  BIND( TRIPLE(?s,rdf:type,rdfs:Resource) AS ?t )
}

There are cases where the effects of using the new TRIPLE function are not immediately obvious just from its definition, particularly when considering the interplay of this function with the BNODE function when used within GRAPH clauses. Some of these cases are discussed below.

Consider the following SPARQL-star query.

Example 18

SELECT ( COUNT(?t1) AS ?t1Count )
       ( COUNT(?t2) AS ?t2Count )
       ( COUNT(?t3) AS ?t3Count )
       ( COUNT(DISTINCT ?t1) AS ?t1DistCount )
       ( COUNT(DISTINCT ?t2) AS ?t2DistCount )
       ( COUNT(DISTINCT ?t3) AS ?t3DistCount )
WHERE {
  GRAPH ?g {
    BIND( TRIPLE(BNODE(), :p, :o) AS ?t1 )
    BIND( TRIPLE(BNODE("id"), :p, :o) AS ?t2 )
    BIND( TRIPLE(:s, :p, :o) AS ?t3 )
  }
}

When evaluated over an RDF-star dataset that contains n named graphs, where n>0, the GRAPH clause results in one SPARQL-star solution mapping per named graph. The SELECT clause collapses these n mappings into a single mapping that is defined for the six variables introduced in the SELECT clause. (If n=0, the query result is the empty set.) Each of these six variables is mapped to an integer-typed literal with values as follows. For each of ?t1Count, ?t2Count, and ?t3Count, the value is n, because the variables ?t1, ?t2, and ?t3 are bound in each of the n solution mappings produced for the GRAPH clause. For the variable ?t1DistCount, the value is also n, because the BIND clauses are evaluated n times (once for each named graph) and the subexpression BNODE() always creates a different new blank node; thus, the triples created for variable ?t1 are all different from one another. This is also the case if the BNODE function is used with an argument; i.e., the value of ?t2DistCount is n too. In contrast, the variable ?t3 is mapped to the same triple within each evaluation of the third BIND clause; thus, the value for ?t3DistCount is 1.

Notice that the BNODE function has to be used to create a blank node; simply writing a blank node directly in an expression is not permitted.

Notice as well that the preceding query is special in two ways: its GRAPH clause does not actually consider the content of the named graphs; and the expressions in the BIND clauses do not contain variables. In contrast, the GRAPH clause and the BIND clauses in the following query do.

Example 19

PREFIX rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX rdfg: <http://www.w3.org/2004/03/trix/rdfg-1/>

SELECT ( COUNT(?t1) AS ?t1Count )
       ( COUNT(?t2) AS ?t2Count )
WHERE {
  GRAPH ?g {
    ?g rdf:type rdfg:Graph .
    BIND( TRIPLE(?g, rdf:type, rdfs:Resource) AS ?t1 )
    BIND( TRIPLE(?x, rdf:type, rdfs:Resource) AS ?t2 )
  }
}

For every RDF-star dataset with n>0 named graphs, the result of this query consists of a single SPARQL-star solution mapping that is defined for the three variables introduced in the SELECT clause. The value of ?t1Count is the number of named graphs in the queried dataset that contain a triple of the form (u, rdf:type, rdfg:Graph) such that u is the name of the named graph in the dataset. The value of ?t2Count is always 0 (zero), because evaluating the expression of the second BIND clause results in an error, because the variable ?x is not bound in the scope of this evaluation. As a side note, evaluating the expression of the first BIND clause would also result in an error, if the variable ?g was not mentioned inside the GRAPH clause (e.g., if the given triple pattern was not there).

4.6 Evaluation Semantics

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.

4.7 Query Result Formats

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

4.7.1 SPARQL-star Query Results JSON Format

The result of a SPARQL SELECT query is serialized in JSON as defined in SPARQL 1.1 Query Results JSON Format, which specifies a JSON representation of variable bindings to RDF terms (see [sparql11-results-json, Section 3.2]). To accommodate the new RDF term for embedded triples that RDF-star introduces, the table of RDF term JSON representations in sparql11-results-json, Section 3.2.2 is extended with the following entry:

An embedded triple with subject RDF term S, predicate RDF term P and object RDF term O

{
  "type": "triple",
  "value": {
     "subject": S,
     "predicate": P,
     "object": O
  }
}

where S, P and O are encoded using the same format, recursively.

Example 20

Consider the following RDF term, an embedded triple in Turtle-star syntax:

<< <http://example.org/alice> <http://example.org/name> "Alice" >>

This term is represented in JSON as follows:

{
  "type": "triple",
  "value": {
     "subject": {
        "type": "uri",
        "value" "http://example.org/alice"
     },
     "predicate": {
        "type": "uri",
        "value" "http://example.org/name"
     },
     "object": {
        "type": "literal",
        "value" "Alice",
        "datatype": "http://www.w3.org/2001/XMLSchema#string"
     },
  }
}

4.7.2 SPARQL-star Query Results XML Format

The result of a SPARQL SELECT query is serialized in XML as defined in SPARQL Query Results XML Format (Second Edition). This format proposes an XML representation of variable bindings to RDF terms.

To accommodate the new RDF term for embedded triples that RDF-star introduces, the list of RDF terms and their XML representations in [RDF-SPARQL-XMLRES Section 2.3.1] is extended as follows:

An embedded triple with subject term S, predicate term P, and object term O

<binding>
  <triple>
    <subject>S</subject>
    <predicate>P</predicate>
    <object>O</object>
  </triple>
</binding>

where S, P and O are encoded recursively, using the same format, without the enclosing <binding> tag.

Example 21

Consider the following RDF term, an embedded triple in Turtle-star syntax:

<< <http://example.org/alice> <http://example.org/name> "Alice" >>

This term is represented in XML as follows:

<triple>
    <subject>
        <uri>http://example.org/alice</uri>
    </subject>
    <predicate>
        <uri>http://example.org/name</uri>
    </predicate>
    <object>
        <literal datatype='http://www.w3.org/2001/XMLSchema#string'>Alice</literal>
    </object>
</triple>

5. SPARQL-star Update

This section specifies SPARQL-star Update, an update language for RDF-star. This language extends SPARQL Update [SPARQL11-UPDATE], the update language for RDF, by adding RDF-star-specific features and semantics.

5.1 Informal Description

This section is non-normative.

While SPARQL Update operates over a graph store that consists of RDF graphs, SPARQL-star Update extends the notion of graph store to contain RDF-star graphs instead of RDF graphs. That is, a graph store in the context of SPARQL-star Update contains one (unnamed) slot holding an RDF-star graph, referred to as the default graph, and zero or more named slots holding other RDF-star graphs, referred to as named graphs. Then, all graph management operations in SPARQL Update (CREATE, DROP, COPY, MOVE, ADD) carry over directly to SPARQL-star Update with the only difference being that in SPARQL-star Update these operations manage RDF-star graphs. For instance, the CREATE operation in SPARQL-star Update creates an RDF-star graph rather than a pure RDF graph. Similarly, the graph update operations LOAD and CLEAR in SPARQL-star Update operate with RDF-star graphs in the same way as their SPARQL Update counterparts operate with RDF graphs.

The only operations that SPARQL-star Update actually extends are the graph update operations INSERT DATA, DELETE DATA, and DELETE/INSERT. This section describes these extensions informally. While this description focuses mainly on updates to the default graph, the operations can also be applied to the named graphs.

5.1.1 INSERT DATA

The INSERT DATA operation can be used to add a given set of triples into the graph store. In the context of SPARQL-star Update, these triples may be RDF-star triples. As an example, consider the following INSERT DATA operation.

Example 22

PREFIX : <http://www.example.org/>

INSERT DATA {
  :alice :claims << :bob :age 23 >> .
}

Suppose this INSERT DATA operation is executed over a graph store with an empty default graph. After executing this operation, the default graph contains the given (nested) RDF-star triple. Now, it is possible to query for this triple. For instance, the following SPARQL-star query returns a single solution mapping in which the variables ?p and ?a are mapped to the IRI :alice and the literal 23, respectively.

Example 23

PREFIX : <http://www.example.org/>

SELECT ?p ?a WHERE {
  ?p :claims << :bob :age ?a >> .
}

Notice that inserting a nested triple does not automatically also insert its embedded triple(s) as asserted triple(s) into the graph. Hence, in the previous example, after executing the given INSERT DATA operation, the default graph does not contain the triple :bob :age 23. In other words, a query such as the following would have an empty result.

Example 24

PREFIX : <http://www.example.org/>

SELECT ?a WHERE {
  :bob :age ?a .
}

For an embedded triple to be present in the graph as an asserted triple, it needs to be inserted as such. For instance, the INSERT DATA operation in the example above may be modified as follows in order to insert not only the nested triple but also the triple :bob :age 23.

Example 25

PREFIX : <http://www.example.org/>

INSERT DATA {
  :bob :age 23 .
  :alice :claims << :bob :age 23 >> .
}

5.1.2 DELETE DATA

The DELETE DATA operation can be used to remove a given set of triples from the graph store. In the context of SPARQL-star Update, this may include removing nested RDF-star triples as demonstrated in the following example.

Example 26

PREFIX : <http://www.example.org/>

DELETE DATA {
  :alice :claims << :bob :age 23 >> .
}

After executing this DELETE DATA operation over a graph store with a default graph that contains the given nested triple, the graph will not contain this triple any longer. If the graph did not contain that nested triple in the first place, the graph will remain unchanged by the given DELETE DATA operation.

Notice that deleting triples by using the DELETE DATA operation does not affect any other triples in the corresponding graphs. For instance, for a default graph that contains the triple :bob :age 23 as an asserted triple, the DELETE DATA operation given above does not delete this asserted triple. In contrast, the following operation would delete this asserted triple but it would not delete any nested triple that contains the given triple as an embedded triple.

Example 27

PREFIX : <http://www.example.org/>

DELETE DATA {
  :bob :age 23 .
}

5.1.3 DELETE/INSERT

The DELETE/INSERT operation can be used to remove or add triples based on variable bindings obtained by evaluating a given WHERE clause. As an example, the following DELETE/INSERT operation replaces all nested triples in which :alice is the subject by nested triples in which :carol is the subject.

Example 28

PREFIX : <http://www.example.org/>

DELETE { :alice ?pp <<?s ?p ?o>> . }
INSERT { :carol ?pp <<?s ?p ?o>> . }
WHERE {  :alice ?pp <<?s ?p ?o>> . }

As in SPARQL Update, in SPARQL-star Update it is possible to use variations of the DELETE/INSERT operations in which either the DELETE clause or the INSERT clause are omitted.

When removing triples via the DELETE clause (irrespective of whether the INSERT clause is omitted or not), the effects with respect to nested triples must be the same as described above for the DELETE DATA operation; i.e., only the triples that are explicitly identified to be deleted are deleted. Similarly, inserting triples via the INSERT clause has the same effects as described above for the INSERT DATA operation; i.e., inserting nested triples does not automatically also insert their embedded triples as asserted triples into the graph. Of course, it is possible to request such inserts explicitly as demonstrated in the following example.

Example 29

PREFIX : <http://www.example.org/>

DELETE { :alice ?pp <<?s ?p ?o>> . }
INSERT { :carol ?pp <<?s ?p ?o>> .  ?s ?p ?o .}
WHERE {  :alice ?pp <<?s ?p ?o>> . }

While all SPARQL-star Update examples above focus only on the default graph of a graph store, SPARQL-star Update can also be used to update the named graphs of a graph store, which works in exactly the same way as in SPARQL Update. As a possible example consider the following INSERT operation which retrieves all embedded triples found in nested triples in the default graph and inserts them as asserted triples into the named graph with IRI :graph2.

Example 30

PREFIX : <http://www.example.org/>

INSERT {
  GRAPH :graph2 { ?s ?p ?o }
}
WHERE {
  { <<?s ?p ?o>> ?pp ?oo }
  UNION
  { ?ss ?pp <<?s ?p ?o>> }
}

5.2 Grammar

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.

5.3 Semantics

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.

6. RDF-star Semantics

In this section, we provide a model-theoretic semantics for RDF-star, based on the one defined in RDF 1.1 Semantics [RDF11-MT]. More precisely, we define a mapping from RDF-star's abstract syntax into standard RDF's abstract syntax, and define the semantics of RDF-star graphs in terms of the semantics of the mapped RDF graphs.

In the following, we will use abbreviated IRIs using the prefix unstar: which is an alias for the namespace https://w3c.github.io/rdf-star/unstar#.

We also introduce a number of definitions specific to RDF-star, which rely on the following notions, defined in RDF 1.1 Concepts and Abstract Syntax [RDF11-CONCEPTS] and RDF 1.1 Semantics [RDF11-MT]: datatype, lexical form, ill-typed, merging, satisfiability, unsatisfiability, entailment, and equivalence.

6.1 Mapping RDF-star abstract syntax to RDF

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

For each IRI i in the constituents of G starting with https://w3c.github.io/rdf-star/unstar#:
1. Mint a new IRI j by appending an underscore (_) to i.
2. Replace with j all occurrences of i in the subject, predicate, or object position of an asserted or embedded triple of G.
While G contains embedded triples:
1. Pick an RDF-star triple (s, p, o) in the constituents of G such that neither s nor o is an embedded triple.
2. Mint a fresh blank node b (i.e., such that b is not in the constituents of G).
3. Replace with b all occurrences of (s, p, o) in the subject or object position of an asserted or embedded triple of G.
4. Add the following asserted triples to G:
  - (b, unstar:subject, s)
  - (b, unstar:predicate, p)
  - (b, unstar:object, o) unless o is an ill-typed literal
  - (b, unstar:subjectLexical, L(s)) unless s is a blank node
  - (b, unstar:predicateLexical, L(p))
  - (b, unstar:objectLexical, L(o)) unless o is a blank node

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

6.2 Entailment of RDF-star graphs

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

Note

Other notions of satisfiability and entailment, such as RDF entailment or RDFS entailment, can be extended in the same way for RDF-star graphs.

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

Example 31

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

6.4 Remarks

This section is non-normative.

6.4.1 Implementing the RDF-star semantics

It is important to notice that the definitions given above for satisfiability and entailment of RDF-star graphs do not mandate that implementations actually transform RDF-star graphs using the unstar mapping defined above. It should be possible to implement the semantics by directly handling RDF-star's abstract syntax.

6.4.2 Combining RDF-star graphs

Care must be taken when implementations that rely on the unstar mapping combine the resulting RDF graphs through union or merge. Given two RDF-star graphs G and H, it may be the case that unstar(G ∪ H) ≠ unstar(G) ∪ unstar(H).

In particular, if G and H contain the same embedded triple, this triple will be mapped to a single blank node in unstar(G ∪ H), but in two potentially different blank nodes in unstar(G) ∪ unstar(H). These blank nodes will need to be unified in order to reconstruct unstar(G ∪ H).

Conversely, nothing in the definition of the unstar mapping prevents it from generating the same blank node b for an embedded triple of G, and for a different embedded triple of H (provided that b is not present in either G nor H). In that case, not only would unstar(G) ∪ unstar(H) be different from unstar(G ∪ H), but it would lose some information by mixing the descriptions of the two embedded triples.

6.4.3 Other uses of the unstar mapping

Since the unstar mapping transforms any RDF-star graph into a standard ("non-star") RDF graph, it might be tempting to use this mapping for conveying RDF-star graphs to legacy RDF systems. However, this has a number of caveats.

First, the unstar mapping alters the semantics of the graph: in general, a graph G is not equivalent to its "unstarred" version unstar(G), even if G is a standard RDF graph containing no embedded triples. (More precisely, they are equivalent only if G contains no embedded triples and no IRIs from the unstar: namespace.)

Second, when a legacy RDF system communicates an RDF graph to an RDF-star-aware system, there is no means by which the latter can determine with certainty whether the graph is the result of applying the unstar mapping, and thus needs to be transformed back. (The presence of unstar: IRIs in the graph can be used as a hint, but such IRIs can also be used independently of the mapping.) Additional metadata should therefore be attached to unstarred graphs, so that RDF-star systems know whether or not they need to apply the inverse transformation of unstar.

Finally, legacy RDF systems may alter unstarred graphs in ways that prevent their transformation back to the original RDF-star graph. For example, it has been pointed out above how combining several unstarred graphs may not yield the expected result. Another example is the removal of some arcs, such that an embedded triple is not completely described anymore, and can not be reconstructed.

6.4.4 Referential opacity

The way the unstar mapping is defined, the denotation of an embedded triple does not only depend on the denotation of its component terms, but also on their syntactical form (for IRIs and literals). This behavior is referred to as referential opacity. A consequence is that two different triples, that would be semantically equivalent if asserted, are not automatically considered to denote the same thing when embedded. In the example below, assuming D-entailment: while "42"^^xsd:integer and "042"^^xsd:integer denote the same thing (namely, the number 42), the two embedded triples are allowed to have different denotations, and so the entailment does not hold.

Example 32

#### under D-entailment

<h2g2.ttl> :contains << :lue :answer "42"^^xsd::integer >>.

#### does NOT entail

<h2g2.ttl> :contains << :lue :answer "042"^^xsd::integer >>.

Similarly, in the example below and under OWL entailment [OWL2-Overview], while :superman and :clark are inferred to denote one and the same person (because of the owl:sameAs relationship between them), the two embedded triples are not automatically considered to denote the same thing.

Example 33

#### under OWL-entailment

:superman owl:sameAs :clark.
<< :superman :can :fly >> :reportedBy :clark.

#### does NOT entail

<< :clark :can :fly >> :reportedBy :clark.

This is well suited for use-cases where the syntactical form of the annotated statements may be significant (like annotating statements from other graphs or annotating commit deltas). On the other hand, other use-cases would expect some degree of referential transparency. Consider the case of attributed/evidenced triples. The annotation is understood to be about the fact asserted by the triple rather than the triple itself. As illustrated in the example below, one might then expect more inferences than provided by the current semantics.

Example 34

#### under D-entailment

:linköping :population "0104232"^^xsd::integer
    {| :source <https://en.wikipedia.org/wiki/Link%C3%B6ping> |}.

#### does NOT entail

:linköping :population "104232"^^xsd::integer
    {| :source <https://en.wikipedia.org/wiki/Link%C3%B6ping> |}.

#### more precisely, it DOES entail

:linköping :population "104232"^^xsd::integer.

#### but it does NOT entail

<< :linköping :population "104232"^^xsd::integer >>
    source <https://en.wikipedia.org/wiki/Link%C3%B6ping> .

Note that the current semantics does not forbid the additional inferences to be drawn. However, they would require additional knowledge and an appropriate semantic extension, not specified in this document. This makes RDF-star less readily usable for (but not incompatible with) that latter kind of use-cases.

6.4.5 Alternatives to referential opacity

Given the potential drawbacks of the referential opacity provided by the current semantics, as described in the previous section, the group has considered alternative semantics. No clear consensus was reached, however, to decide whether these alternatives should be used as a replacement, or as a semantic extension, of the current semantics.

A fully referentially transparent semantics can be achieved by changing the step 2.4 of the unstar mapping algorithm as follows:

Add the following asserted triples to G:
- (b, unstar:subject, s)
- (b, unstar:predicate, p)
- (b, unstar:object, o)

In the examples above (Example 32, Example 33, Example 34), all the entailments would now hold automatically. This could be a problem in some use-cases, as such inferences could then not be cancelled, given the monotonic semantics of RDF.

An intermediate alternative would be to make embedded triples referentially opaque for IRIs only, keeping it transparent for literals (and for blank nodes, as is already the case). This can be achieved by changing the step 2.4 of the unstar mapping algorithm as follows:

Add the following asserted triples to G:
- (b, unstar:subject, s)
- (b, unstar:predicate, p)
- (b, unstar:object, o)
- (b, unstar:subjectLexical, L(s)) if s is an IRI
- (b, unstar:predicateLexical, L(p))
- (b, unstar:objectLexical, L(o)) if o is an IRI

Note

Other design choices for the semantics have also been discussed by the community group; these have been summarized in a Github issue.

B.1 SA-mode and PG-mode

A lot of discussions on the RDF-star mailing list and GitHub repository refer to SA-mode and PG-mode. Those abbreviations stand for "Separate Assertion mode" and "Property Graph mode". They originate in the fact that different versions of RDF-star have been published over the years, with different designs. In PG-mode, any embedded triple was also considered asserted. SA-mode, on the other hand, allowed the use of embedded triples without those triples being automatically asserted, requiring that they be asserted separately when that was intended. SA-mode was more flexible, but induced redundancy in the use-cases that PG-mode was designed to address.

The notion of annotations in the Turtle-star syntax was introduced to remove the need for different modes. Rather than interpret the same syntax differently in each mode, which would have caused interoperability problems and required a switch for those modes, it was decided to provide a different syntax for each use case.

The << ... >> syntax represents a triple that is embedded without being asserted, satisfying the need formerly filled by SA-mode.
The :a :b :c {| :p :o ... |} annotation syntax creates triples where the subject is an embedded version of the triple asserted just before the annotation (here, :a :b :c), without the need to repeat it, satisfying the need formerly filled by PG-mode.

B.2 The seminal example

The motivating example in the original RDF-star paper [RDF-STAR-FOUNDATION] was on a provenance use-case, and is repeated below.

Example 35

# the controversial seminal example
:bob foaf:name "Bob".
<<:bob foaf:age 23>> dct:creator <http://example.com/crawlers#c1> ;
                     dct:source <http://example.net/listing.html> .

This example was further debated on the RDF-star mailing list, as it appears to have set wrong expectations about what embedded triples represent. More precisely, from this example, one may wrongly assume that <<:bob foaf:age 23>> represents the occurrence of the given triple at the address http://example.net/listing.html (see § 2.1 Triples and occurrences). This impression may be reinforced by the use of dct:creator: arguably, a triple (as a unique abstract entity) is not "created" by anyone, while an occurrence thereof can be said to be created or authored.

The problem with this interpretation is that it will break as soon as other creators and sources are added for the triple: one could not tell which source corresponds to which creator. Correctly capturing this information would require additional nodes to explicitly represent triple occurrences, as in Example 6. In summary, although RDF-star can be used for provenance, the seminal example does not work as stated and can lead to the fundamentally incorrect interpretation that RDF-star can represent multiple distinct embedded triples with the same subject, predicate, and object.

D.1 Normative references

[N-QUADS]: RDF 1.1 N-Quads. Gavin Carothers. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/n-quads/
[N-TRIPLES]: RDF 1.1 N-Triples. Gavin Carothers; Andy Seaborne. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/n-triples/
[RDF-SPARQL-XMLRES]: SPARQL Query Results XML Format (Second Edition). Dave Beckett; Jeen Broekstra. W3C. 21 March 2013. W3C Recommendation. URL: https://www.w3.org/TR/rdf-sparql-XMLres/
[RDF11-CONCEPTS]: RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/
[RDF11-MT]: RDF 1.1 Semantics. Patrick Hayes; Peter Patel-Schneider. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-mt/
[RFC2119]: Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[RFC8174]: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc8174
[SPARQL11-QUERY]: SPARQL 1.1 Query Language. Steven Harris; Andy Seaborne. W3C. 21 March 2013. W3C Recommendation. URL: https://www.w3.org/TR/sparql11-query/
[SPARQL11-RESULTS-JSON]: SPARQL 1.1 Query Results JSON Format. Andy Seaborne. W3C. 21 March 2013. W3C Recommendation. URL: https://www.w3.org/TR/sparql11-results-json/
[SPARQL11-UPDATE]: SPARQL 1.1 Update. Paula Gearon; Alexandre Passant; Axel Polleres. W3C. 21 March 2013. W3C Recommendation. URL: https://www.w3.org/TR/sparql11-update/
[TRIG]: RDF 1.1 TriG. Gavin Carothers; Andy Seaborne. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/trig/
[TURTLE]: RDF 1.1 Turtle. Eric Prud'hommeaux; Gavin Carothers. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/turtle/
[XML]: Extensible Markup Language (XML) 1.0 (Fifth Edition). Tim Bray; Jean Paoli; Michael Sperberg-McQueen; Eve Maler; François Yergeau et al. W3C. 26 November 2008. W3C Recommendation. URL: https://www.w3.org/TR/xml/
[XPATH-FUNCTIONS]: XQuery 1.0 and XPath 2.0 Functions and Operators (Second Edition). Ashok Malhotra; Jim Melton; Norman Walsh; Michael Kay. W3C. 14 December 2010. W3C Recommendation. URL: https://www.w3.org/TR/xpath-functions/

D.2 Informative references

[DX-PROF-CONNEG]: Content Negotiation by Profile. Lars G. Svensson; Nicholas Car. W3C. 26 November 2019. W3C Working Draft. URL: https://www.w3.org/TR/dx-prof-conneg/
[JSON-LD]: JSON-LD 1.0. Manu Sporny; Gregg Kellogg; Markus Lanthaler. W3C. 3 November 2020. W3C Recommendation. URL: https://www.w3.org/TR/json-ld/
[OWL2-Overview]: OWL 2 Web Ontology Language Document Overview (Second Edition). W3C OWL Working Group. W3C. 11 December 2012. W3C Recommendation. URL: https://www.w3.org/TR/owl2-overview/
[RDF-STAR-FOUNDATION]: Foundations of RDF* and SPARQL* - An Alternative Approach to Statement-Level Metadata in RDF.. Olaf Hartig. In Proceedings of the 11th Alberto Mendelzon International Workshop on Foundations of Data Management (AMW), Montevideo, Uruguay. June 2017. URL: http://ceur-ws.org/Vol-1912/paper12.pdf
[RDF-SYNTAX-GRAMMAR]: RDF 1.1 XML Syntax. Fabien Gandon; Guus Schreiber. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-syntax-grammar/
[SPARQL11-SERVICE-DESCRIPTION]: SPARQL 1.1 Service Description. Gregory Williams. W3C. 21 March 2013. W3C Recommendation. URL: https://www.w3.org/TR/sparql11-service-description/

RDF-star and SPARQL-star

Draft Community Group Report 01 July 2021

Abstract

Status of This Document

1. Introduction

1.1 Background and Motivation

1.2 Overview

1.3 Conformance

2. Concepts and Abstract Syntax

2.1 Triples and occurrences

3. Concrete Syntaxes

3.1 Turtle-star

3.1.1 Grammar

3.1.2 Parsing

3.1.2.1 Discussion

3.2 TriG-star

3.2.1 Grammar

3.2.2 Parsing

3.2.3 Discussion

3.3 N-Triples-star

3.3.1 Grammar

3.3.2 Parsing

3.4 N-Quads-star

3.5 Other Concrete Syntaxes

4. SPARQL-star Query Language

4.1 Initial Definitions

4.2 Grammar

4.3 Translation to the Algebra

4.3.1 Variable Scope

4.3.2 Expand Syntax Forms

4.3.3 Translate Property Path Patterns

4.3.4 Translate Basic Graph Patterns

4.4 Function and Operator Definitions

4.4.1 TRIPLE

4.4.2 SUBJECT

4.4.3 PREDICATE

4.4.4 OBJECT

4.4.5 isTRIPLE

4.4.6 Embedded Triple Expression

4.4.7 sameTerm

4.4.8 sparql-compare

4.4.9 RDFterm-equal

4.4.10 Operator Mappings

4.4.11 Triple terms with ORDER BY

4.5 Examples and Discussion

4.6 Evaluation Semantics

4.7 Query Result Formats

4.7.1 SPARQL-star Query Results JSON Format

4.7.2 SPARQL-star Query Results XML Format

5. SPARQL-star Update

5.1 Informal Description

5.1.1 INSERT DATA

5.1.2 DELETE DATA

5.1.3 DELETE/INSERT

5.2 Grammar

5.3 Semantics

6. RDF-star Semantics

6.1 Mapping RDF-star abstract syntax to RDF

6.2 Entailment of RDF-star graphs

6.3 Merging RDF-star graphs

6.4 Remarks

6.4.1 Implementing the RDF-star semantics

6.4.2 Combining RDF-star graphs

6.4.3 Other uses of the unstar mapping

6.4.4 Referential opacity

6.4.5 Alternatives to referential opacity

7. RDF-star vocabulary

A. IANA Considerations

B. Historical remarks

B.1 SA-mode and PG-mode

B.2 The seminal example

C. Issue Summary

D. References

D.1 Normative references

D.2 Informative references