Introduction

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 this notion MUST be extended as follows.

• A variable is in-scope of a BGP* |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).
• A variable is in-scope of a BIND clause of the form `BIND ( T AS v )` (where |T| is an embedded triple pattern) if the variable is variable |v| or the variable occurs in the embedded triple pattern |T|. As for standard BIND clauses with expressions, variable |v| must not [be] in-scope from the preceeding elements in the group graph pattern in which [the BIND clause] is used [SPARQL11-QUERY, Section 18.2.1]].

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 two ways:

1. Abbreviations for triple patterns with embedded triple patterns MUST be expanded as if each embedded triple pattern was a variable (or an RDF term).

   For instance, the following syntax expression:

   must be expanded to

2. Abbreviations for IRIs in all embedded triple patterns MUST be expanded.

   For instance, the embedded triple pattern

   must be expanded to

Translate Property Path Patterns

The translation of property path patterns has to be adjusted because the extended grammar allows for property path patterns whose subject or object is an embedded triple pattern (cf. ).

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 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 , |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 as follows:

1. If |Z| is an embedded triple pattern <<|S|,|P|,|O|>> then return the SPARQL* triple pattern (`Lift`(|S|, |P|, `Lift`(|O|));
2. Otherwise, return |Z|.

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

Translate BIND Clauses with an Embedded Triple Pattern

The extended grammar in allows for BIND clauses with an embedded triple pattern. The translation of such a BIND clause to a SPARQL algebra expression requires a new algebra symbol:

• TR( SPARQL* triple pattern, variable )

Note that this symbol corresponds to SPARQL* expressions of the form (`tp` AS `?v`).

Then, any string of the form `BIND( T AS v )` with |T| being an embedded triple pattern (i.e., not a standard BIND expression) is translated to the algebra expression `TR`(T’, |v|) where T’ is the result of the function `Lift` for |T|.

Notice, the translation of BIND clauses with an embedded triple pattern as defined in this section is used during the translation of group graph patterns. The case of BIND clauses with an embedded triple pattern is covered in this translation of group graph patterns by the last, “catch all other” `IF` statement (i.e., the `IF` statement with the condition `E is any other form`) and not by the `IF` statement for BIND clauses with an expression.

SPARQL* Query Results JSON Format

The result of a SPARQL SELECT query is serialized in JSON as defined in [[[sparql11-results-json]]], which specifies a JSON representation of variable bindings to RDF terms (see [sparql11-results-json, Section 3.2]). To accomodate the new RDF term for embedded triples that RDF* 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.

                {
                  "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"
                     },
                  }
                }
          

SPARQL* Query Results XML Format

The result of a SPARQL SELECT query is serialized in XML as defined in [[[rdf-sparql-XMLres]]]. This format proposes an XML representation of variable bindings to RDF terms.

To accomodate the new RDF term for embedded triples that RDF* 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`

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

Semantic condition for ground graphs

We say that an RDF* graph is ground if its set of constituent terms contains no blank node. This is a generalization of the notion of ground RDF graph [[RDF11-MT]]. The denotation of a ground RDF* graph in an RDF* simple interpretation |I| is then given by the following rules, where the interpretation is also treated as a function from expressions (terms, triples and graphs) to elements of the universe and truth values:

• if |E| is a literal then |I|(|E|) = |IL|(|E|)
• if |E| is an IRI then |I|(|E|) = |IS|(|E|)
• if |E| is an embedded triple then |I|(|E|) = |IT|(|E|)
• if |E| is an asserted triple (|s|,|p|,|o|) then |I|(|E|) =
  • true if |I|(|p|) ∈ |IP| and (|I|(|s|),|I|(|o|)) ∈ |IEXT|(|IP|(|p|))
  • false otherwise
• if |E| is an RDF* graph then then |I|(|E|) = true if
  • for every RDF* triple |t| ∈ |E|, |I|(|t|) = true, and
  • for every RDF* triple |t| = (|s|,|p|,|o|) ∈ constituents(|E|), |ITEXT|(|IT|(|t|)) = (|I|(|s|), |I|(|p|), |I|(|o|))
  otherwise |I|(|E|) = false

Since |IL| and |IT| are partial mappings, |I|(|E|) may be undefined for some literal or embedded triple |E|. In that case, |E| has no semantic value in |I|, so any triple containing it will be false, hence any graph containing that triple will also be false.

Semantic condition with blank nodes

An invertible mapping from the set blank nodes into itself is called a blank node renaming. By extension, we define the application of a blank node renaming |R| to other RDF* terms and to RDF* graphs as follow:

• if |E| is an IRI or a literal, then |R|(|E|) = |E|
• if |E| is an RDF* triple (|s|,|p|,|o|), then |R|(|E|) = (|R|(|s|),|R|(|p|),|R|(|o|))
• if |E| is an RDF* graph, then |R|(|E|) = {|R|(|t|) for all |t| ∈ |E|}

Suppose |I| is an RDF* simple interpretation and |A| is a mapping from a set of blank nodes to the universe |IR| of |I|. Define the mapping [|I|+|A|] of RDF* terms into |IR| to be |A| on blank nodes of the set, and |I| on any other term; and extend this mapping to RDF* triples and RDF* graphs using the rules given above for ground graphs. Then the denotation of any RDF* graph in |I| is given by:

• If |E| is an RDF* graph, |I|(|E|)=true if [|I|+|A|](|R|(|E|))=true
  • for some blank node renaming |R|, and
  • for some mapping |A| from the set of blank nodes in constituents(|R|(|E|)) into |IR|
  otherwise |I|(|E|)=false

Entailment

Following [[[RDF11-MT]]], we extend the notions of satisfiability and entailment. An RDF* simple interpretation satisfies |E| when |I|(|E|)=true. |E| is (simply) satisfiable when an RDF* simple interpretation exists which satisfies it, otherwise (simply) unsatisfiable. An RDF* graph |G| simply entails an RDF* graph H when every interpretation which satisfies |G| also satisfies |H|. If two RDF* graphs |G| and |H| each entail the other then they are logically equivalent.

Any semantic extension of RDF MAY be extended to RDF* by replacing the semantic conditions, the notion of satisfiability and the notion of entailment, defined in [[[RDF11-MT]]], by their corresponding extension defined above. This is notably the case for Datatype entailment and RDFS entailment.