Façade-X Data Access in SPARQL

No open issues with label FX access in SPARQL.

The reserved IRI scheme is currently x-sparql-anything:, the scheme used by the reference implementation. A vendor-neutral scheme name is expected to be chosen before this document reaches Recommendation status; until then, the implementation-specific scheme is used throughout.

This document types the root container fx:Root, in agreement with the Schema vocabulary document. Some implementations currently emit the lowercase fx:root; the casing is to be reconciled across the specifications and implementations.

Options given as triples use Engine vocabulary terms (fxe:location). The reference implementation uses the Schema namespace (fx:location); see the Engine vocabulary issues.

A Façade-X view is requested through a SPARQL SERVICE block whose IRI uses the reserved scheme x-sparql-anything:. The general form is:

SERVICE <x-sparql-anything:[OPTIONS]> {
  [GROUP GRAPH PATTERN]
}

An engine that conforms to this specification MUST, on encountering a SERVICE block whose IRI uses the x-sparql-anything: scheme:

1. collect the options given in the SERVICE clause (see Providing options) and interpret them as defined by the Engine vocabulary, which requires exactly one source option;
2. construct the Façade-X representation of the resource as defined by the metamodel and realised by the Schema vocabulary; and
3. evaluate the enclosed group graph pattern against that representation, returning solutions as for any other SERVICE invocation.

The resulting representation is a single Façade-X data source: one container typed fx:Root, reachable from which are its slots, values, and nested containers. Where a resource yields more than one data source, each is produced in its own named graph, as described in Named Graphs.

An engine MAY support options beyond those defined in the Engine vocabulary. An engine MUST NOT return different solutions for an operation because of an option it does not support, other than by raising an error.

Options are supplied to the engine in either of two modalities, which MAY be combined.

SERVICE <x-sparql-anything:location=https://example.org/people.json,media-type=application/json> {
  ?root a fx:Root ; xyz:name ?name .
}

SERVICE <x-sparql-anything:https://example.org/people.json> {
  ?root a fx:Root ; xyz:name ?name .
}

SERVICE <x-sparql-anything:> {
  fx:properties fxe:location   "https://example.org/people.json" ;
                fxe:media-type "application/json" .
  ?root a fx:Root ; xyz:name ?name .
}

A triple pattern with rdfs:member as predicate matches any numbered slot of a container. The pattern ?c rdfs:member ?v binds ?v to each value held by a slot rdf:_1, rdf:_2, … of the container ?c, regardless of its position. This lets a query traverse the members of a container without enumerating their indices.

An engine MUST evaluate rdfs:member in this way within a Façade-X SERVICE block, whether or not rdfs:member triples are materialised (see fxe:use-rdfs-member). The result is the same as under RDFS entailment, where every container-membership property is a sub-property of rdfs:member.

PREFIX fx:   <http://sparql.xyz/facade-x/ns/>
PREFIX fxe:  <http://sparql.xyz/facade-x/engine/>
PREFIX xyz:  <http://sparql.xyz/facade-x/data/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?name ?pet WHERE {
  SERVICE <x-sparql-anything:> {
    fx:properties fxe:location "people.json" .
    ?root a fx:Root ;
          xyz:name ?name ;
          xyz:pets ?pets .
    ?pets rdfs:member ?pet .
  }
}

The reference implementation provides the same behaviour through the magic property fx:anySlot. An engine MAY accept fx:anySlot as a synonym of rdfs:member.

Functions over container-membership properties, such as retrieving the index of a slot or comparing the order of two slots, are provided by implementations. Their standardisation is discussed in issue #18.