Skip to content

Linked Data Templates

Martynas Jusevičius edited this page Dec 7, 2018 · 26 revisions

See the Linked Data Templates for a detailed specification of how templates are defined and executed

AtomGraph sitemap ontology contains Linked Data Templates (LDTs) expressed in RDF/OWL. Linked Data Template defines a class of document resources that:

  • their URI identifiers share the same URI pattern (match specified URI template)
  • their RDF representation was generated from the same SPARQL query

Inheritance

Templates dht:Container and dht:Item are built-in templates, all other templates extend them by using ldt:extends property. Extending templates inherit LDT annotation properties from superclasses, unless they override inheritance by defining own property.

An example of a Linked Data Template that extends built-in container template and overrides its properties:

:LabelResourcesContainer a ldt:Template ;
    ldt:extends dht:Container ;
    ldt:match "/resources/labelled" ;
    ldt:query :DescribeLabelResources ;
    rdfs:label "Labelled resource container" ;
    rdfs:isDefinedBy <#> .

URI templates

AtomGraph Processor is currently using JAX-RS @Path URI template syntax, which is based on Java-style regexp pattern. JAX-RS defines a priority algorithm which LDT is using to select the best match even if the request URI is matching multiple templates. For example, more specific /resources/labelled takes precedence over the catch-all /{path: .*}.

Query templates

LDT template's URI template is defined using the ldt:path property. In the above example its value is /resources/labelled.

AtomGraph Processor is using TopBraid SPIN API to store and manage SPARQL queries as RDF. Queries are instances of SPIN query class, e.g. of sp:Describe or sp:Construct. SPIN also allows using instances of SPIN Templates wherever a query is expected (they are known as "template calls").

Read more about SPIN - SPARQL Inferencing Notation.

Query bindings

Like in SPIN API, ?this variable has a special meaning in AtomGraph. When processsing SPARQL query, LDT always sets values to the following variables:

?this
the absolute URI of the request (excluding query string)

For example, if a template is with a query DESCRIBE ?this, what will be executed is DESCRIBE <http://localhost:8080/> if request to http://localhost:8080 matches this template.

Execution

Lets consider that our :LabelResourcesContainer template is defined with the following query, and our server runs on http://localhost:8080/:

:DescribeLabelResources    a       sp:Describe ;
      sp:text """
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX sioc: <http://rdfs.org/sioc/ns#>
PREFIX dc:   <http://purl.org/dc/elements/1.1/>
PREFIX dct:  <http://purl.org/dc/terms/>

DESCRIBE ?this ?resource WHERE {
    {
        SELECT ?resource
        WHERE {
            ?resource rdfs:label|dct:title ?label .
            FILTER isURI(?resource) .
        }
    } .
}"""^^xsd:string .

During request processing in Processor, if the http://localhost:8080/resources/labelled?limit=20&order-by=label URI is dereferenced, the following query will be executed on the SPARQL backend:

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX sioc: <http://rdfs.org/sioc/ns#>
PREFIX dc:   <http://purl.org/dc/elements/1.1/>
PREFIX dct:  <http://purl.org/dc/terms/>

DESCRIBE <http://localhost:8080/resources/labelled> ?resource WHERE {
    {
        SELECT ?resource
        WHERE {
            ?resource rdfs:label|dct:title ?label .
            FILTER isURI(?resource) .
        }
        LIMIT 20
        ORDER BY ?label
    } .
}

As you can see, ?this has been bound to the request URI. Because :LabelResourcesContainer extends dht:Container and the query contains a sub-SELECT, result modifiers LIMIT and OFFSET are set to dh:limit and dh:orderBy parameter values.

User interface templates

For XSLT stylesheet support, see AtomGraph Web-Client.

Clone this wiki locally