An overview of the changes in SPARQL 1.2

Triple terms use the “<<( … )>>” syntax

Syntax remains aligned with Turtle.

VERSION "1.2"
PREFIX : <http://example.com/ns#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

SELECT ?person ?authority {
  _:r rdf:reifies <<( ?person :jobTitle "Designer" )>> .
  _:r :accordingTo ?authority .
}

“<< … >>” as shorthand for writing reifying triples

Triple terms are rarely used directly.

SELECT ?person ?authority {
  << ?person :jobTitle "Designer" >>
      :accordingTo ?authority .
}

Expands to:

SELECT ?person ?authority {
  _:r rdf:reifies <<( ?person :jobTitle "Designer" )>> .
  _:r :accordingTo ?authority .
}

“<< … ~ :reifier >>” sets a specific reifier

Reifier can be IRIs, blank nodes, or variables.

SELECT ?person ?authority {
  << ?person :jobTitle "Designer" ~ :id >>
      :accordingTo ?authority .
}

“{| … |}” reifies and asserts triples

The annotation syntax.

SELECT ?p ?auth ?date {
  ?p :jobTitle ?title {| :accordingTo ?auth; :recorded ?date |} .
}

Expands to:

SELECT ?p ?auth ?date {
  ?p :jobTitle ?title .
  << ?p :jobTitle ?title >> :accordingTo ?auth ;
                            :recorded ?date .
}

Five new functions related to triple terms

To be used within expressions (FILTER, BIND, …)

• TRIPLE(subj, pred, obj) Triple term expression
• SUBJECT(triple-term) Get subject of triple term
• PREDICATE(triple-term) Get predicate of triple term
• OBJECT(triple-term) Get object of triple term
• isTRIPLE(term) If this is a triple term

Dynamically bind triple terms (1)

Using BIND, triple terms can be bound to a variable.

→ Lookup all asserted reifying triples

SELECT ?tt ?date {
  ?s ?p ?o .
  BIND( TRIPLE(?s, ?p, ?o) AS ?tt )
  ?reifier rdf:reifies ?tt .
  ?reifier :tripleAdded ?date .
}

Dynamically bind triple terms (2)

TRIPLE can also be written using the “<<( … )>>” shorthand.

SELECT ?tt ?date {
  ?s ?p ?o .
  BIND( <<( ?s ?p ?o )>> AS ?tt )
  ?reifier rdf:reifies ?tt .
  ?reifier :tripleAdded ?date .
}

Limitation: no sub-expressions allowed within this shorthand.

• Allowed: BIND( TRIPLE(?s, ?p, STR(?o)) AS ?tt )
• Disallowed: BIND( <<( ?s ?p STR(?o) )>> AS ?tt )

Retrieve subjects of triple terms

Using SUBJECT, the subject of a triple term is returned.

SELECT ?s {
  :id rdf:reifies ?tt .
  BIND(SUBJECT(?tt) AS ?s)
}

SPARQL depends on different forms of comparison

Introduction of triple terms has an impact on all of them:

• sameTerm
• sameValue (=)
• Operator mappings (!=, <, <=, >, >=)
• ORDER BY

sameTerm(term1, term2)

True if terms are the same RDF term.

• Both IRIs are the same as IRIs (character-by-character).
• Both literals are equal as literal terms (lexical space, case-sensitive).
• Both blank nodes are equal as blank nodes.
• Both triple terms are equal as triple terms.
•     The subject, predicate, and object components are pair-wise the same term.

term1 = term2 (sameValue)

True if terms correspond to the same value.

• Also known as sameValue(term1, term2) (called RDFterm-equal in SPARQL 1.1).
• Similar to sameTerm, but literals are compared in their value space (more flexible).

Difference between sameTerm and sameValue (=)

ORDER BY now also considers triple terms

“<” operator is used for directly comparable terms. Otherwise, incomparable terms are sorted in this order:

• No value
• Blank nodes
• IRIs
• Literals
• Triple terms

SPARQL results formats also support triple terms

• SPARQL JSON
• SPARQL XML
• SPARQL CSV
• SPARQL TSV

SPARQL JSON: “triple” term types

{
  "head": { "vars": [ "x", "name", "triple" ] },
  "results": {
    "bindings": [
      {
        "x":    { "type": "bnode",   "value": "r1" },
        "name": { "type": "literal", "value": "Alice" },
        "triple": {
          "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": "..." }
          }
        }
      }
    ]
  }
}

SPARQL XML: <triple> tag

<?xml version="1.0"?>
<sparql ...>
  <head> ... </head>
  <results>
    <result>
      <binding name="x"><bnode>r2</bnode></binding>
      <binding name="name"><literal xml:lang="en">Bob</literal></binding>
      <binding name="triple">
        <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>
      </binding>
    </result>
  </results>
</sparql>

SPARQL CSV: encoding in “<<( … )>>”

Warning: SPARQL CSV is lossy! (no data types)

SPARQL TSV: encoding in “<<( … )>>”

Manage syntax changes without new media types

• Example: The media type of Turtle 1.1 is text/turtle.
• Problem: syntax changes in Turtle 1.2.
• New media types are not a scalable solution:
  • text/turtle-1-2, application/rdf+xml-1-2, text/n-triples-1-2, …
  • text/turtle-1-3, application/rdf+xml-1-3, text/n-triples-1-3, …
  • text/turtle-1-4, application/rdf+xml-1-4, text/n-triples-1-4, …

Also painful for clients to manage during content negotiation
    (+CORS: 128 char header value limit).

Keep media types and introduce versioning

• Precedent: JSON-LD already does this (“@version”), HTML.
• Two ways to announce versions:
  • In-band: within the syntax
  • Out-of-band: outside of the syntax (media type parameter)

In-band versioning

• VERSION keyword for Turtle-like syntaxes (incl. SPARQL).
• Purely informative: keyword MAY be used when 1.2 features are present (could be impossible to determine for some producers).
• Can appear anywhere; should be placed early to make unsupported parsers fail early.

VERSION "1.2"
PREFIX : <http://example.com/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
:a :name "Alice" ~ :t {| :statedBy :bob |} .

Out-of-band versioning

• MAY be used instead of, or together with in-band versioning.

GET /document.ttl HTTP/1.1
Host: example.com
Accept: text/turtle; version=1.2

HTTP/1.1 200 OK
Content-Type: text/turtle; version=1.2

Media type parameter

Defined version labels

Languages can (optionally) have different reading directions

• Direction cannot be derived from language: https://www.w3.org/International/questions/qa-direction-from-language
• Language tags are insufficient → tag literals with language AND base direction.
•     Language-tagged strings can now be augmented with a base direction.
•         :a :name "Alice"@en--ltr
• New datatype: rdf:dirLangString
• Base directions:
      ltr: left-to-right
      rtl: right-to-left

SPARQL functions to handle rdf:dirLangString

• LANG() Get language of a literal (EXTENDED)
• LANGDIR() Get base direction of a literal (NEW)
• hasLANG() If term is literal with language (EXTENDED)
• hasLANGDIR() If term is literal with base direction (NEW)
• STRLANGDIR() Make literal with value, language, and base direction (NEW)

SPARQL 1.1 introduced the (NOT) EXISTS filter expressions

For testing if some data does (not) exist.

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT ?person WHERE {
  ?person rdf:type foaf:Person .
  FILTER EXISTS { ?person foaf:name ?name }
}

Several issues were discovered with EXISTS

Outcome of the SPARQL EXISTS W3C community group:

1. Some uses of EXISTS are not defined during evaluation.
2. Substitution happens where definitions are only for variables.
3. Blank nodes substituted into BGPs act as variables.
4. Substitution can flip MINUS to its disjoint-domain case.
5. Substitution affects disconnected variables.

Examples: substitution happens where definitions are only for variables

The target term of BIND must always be a variable.

SELECT ?person WHERE {
  ?person rdf:type foaf:Person .
  FILTER EXISTS { BIND ( :p AS ?person ) }
}

Projection with SELECT must always be a variable.

SELECT ?person WHERE {
  ?person rdf:type foaf:Person .
  FILTER EXISTS { SELECT ?person { :a :b ?person } }
}

Different interpretations lead to inconsistent behaviour across SPARQL engines.

Solution: “deep injection”

• Goal was to remain close to the original intent of EXISTS in SPARQL 1.1.
• Deep injection: inject values inside the pattern (↔ at beginning of pattern).
• Without projection: values projected out in sub-SELECTs are affected.
• Per solution mapping: evaluate EXISTS pattern once per solution mapping (↔ once for all solution mappings).

Many new specification tests

https://github.com/w3c/rdf-tests/

Declarative set of tests to measure conformance of a system.

New tests for:

• N-Triples 1.2 (70)
• N-Quads 1.2 (68)
• Semantics 1.2 (155)
• TriG 1.2 (60)
• Turtle 1.2 (92)
• RDF/XML 1.2 (30)
• SPARQL 1.2 (230)

Next steps

• After RDF and SPARQL 1.2 recommendations, WG in maintenance mode
      → faster evolution of RDF and SPARQL specs.
• Will consider input from the SPARQL DEV community group: https://github.com/w3c/sparql-dev/

Reference implementations for 1.2

• Java: Apache Jena
• Rust: Oxigraph, Sophia
• JavaScript/TypeScript: Comunica, RDF/JS
•     https://query.comunica.dev/, https://rdf-play.rubensworks.net/