OSLC Simple Query SPARQL Semantics V1

Early Draft

Introduction

The OSLC Core Query Syntax is intended to be sufficiently simple that query authors should be able to write queries by looking at examples. This document is primarily intended for service implementers and testers who require greater precision.

For an informal discussion of the semantics, see OSLC Simple Query Semantics V1. This document describes the formal semantics by translating simple queries into their equivalent SPARQL queries. The semantics of the simple queries is thus defined in terms of the semantics of their SPARQL equivalents.

The Role of SPARQL

The use of SPARQL to define the formal semantics in no way implies that implementations must use a SPARQL processor. A goal of the simple query syntax is that is should be readily implementable in a wide range of commonly available technologies. An implementation of the simple query syntax MAY use any technology, e.g. SQL, XQuery, or a proprietary query language.

Example 1: Including Properties of a Resource

The oslc.properties query parameter lets you specify which properties of a resource to include in the HTTP response. In general, a given property may occur zero or more times in a resource. The semantics of the oslc.properties query parameter is that all occurances of the property are included in the HTTP response. This implies that a property may not occur, i.e. if a property occurs then it is included, but there is no requirement that the property occur at all.

The following example is described in Including Selected Properties of a Resource.

http://braintwistors.example.com/ems10/Project/4201?oslc.properties=dc:title,ems:projectList 

The service should first check for the existence of the base URL and return an HTTP 404 Not Found or other suitable error response if it does not exist. If the base URL exists then the service should execute the query and return the triples return by the following SPARQL query. The service MAY add rdf:type information for the base URL, i.e. ems:Project, when forming the representation.

This simple query is equivalent to the following SPARQL query which we'll discuss in detail below:

BASE <http://braintwistors.example.com/ems10/Project/4201>

PREFIX dc:  <http://purl.org/dc/terms/>
PREFIX ems: <http://open-services.net/software-metrics/>

CONSTRUCT {
   <> dc:title ?v1;
      ems:projectList ?v2
}      
WHERE {
   { 
      { <> dc:title ?v1 }
      UNION 
      { <> ems:projectList ?v2 }
} 

The SPARQL query begins which a BASE statement that defines the base URL of the simple query as the base for relative URIs in the body of the query. SPARQL uses angle brackets to delimit URIs, and <> is shorthand for the base URI itself. The base URL of the simple query identifies the resource to return in the HTTP response.

The next lines of the SPARQL query declare the pre-defined prefixes, dc: and ems:

The CONSTRUCT clause of the SPARQL query defines the triples to return in the HTTP response. Each match of the WHERE clause results in the inclusion of the set of triples defined in the CONSTRUCT clause. If some match leaves a variable unbound, then the triples that use that variable are omitted. Similarly, any match that would produce an invalid triple (e.g. having a literal subject) are also omitted.

The WHERE clause defines the graph patterns to match. It is a UNION of two patterns. The first pattern matches any dc:title properties and the second pattern matches any ems:projectList properties. If the first pattern matches then ?v1 is bound and ?v2 is unbound. Similarly, if the second pattern matches then ?v1 is unbound and ?v2 is bound.

The generalization of this SPARQL query to an arbitrary list of unnested properties should be evident, i.e. add corresponding triples to the CONSTRUCT clause and graph patterns to the WHERE clause.

Example 2. Searching for Resources in a Collection Resource

The oslc.where query parameter lets you search a collection of resources for a subset of resources that satisfy specified conditions. The resources that belong to the collection are refered to as members of the collection. This type of search can be thought of as filtering the members of the collection since a member is included in the result set only if it passes through the filter defined by the search conditions.

The properties used in the oslc.where query parameter may occur zero or more times, however, at least one occurance of properties that satisify the specified conditions must exist in order for the member resource to be included in the result set.

The following example is described in Filtering Resource Collections:

http://braintwistors.example.com/ems10/Project?oslc.where=dc:identifier="2009" 

This simple query searches for a project resource that has the identifier "2009". Since oslc.from is not present, the service uses its default value, which in this case is the membership property ems:memberProject. The query is equivalent to the following SPARQL query:

BASE <http://braintwistors.example.com/ems10/Project>

PREFIX dc:  <http://purl.org/dc/terms/>
PREFIX ems: <http://open-services.net/software-metrics/>

CONSTRUCT {
   <> ems:memberProject ?member .
}      
WHERE {
   <> ems:memberProject ?member .
   ?member dc:identifier "2009" 
}

The SPARQL query begins by setting the BASE URI to be the base URL of the simple query, which in this case is a collection resource of type ems:ProjectList. Let us assume that the service has defined the shape of ems:ProjectList to have ems:memberProject as its only membership property.

The CONSTRUCT clause defines the triples to include. Only triples with the predicate ems:memberProject are included since there is no oslc.select query parameter.

The WHERE clause has two graph patterns that must be satified together. The first pattern matches the members of the collection. The second pattern filters those members whose dc:identifier is "2009".

Example 3: Including Nested Properties of Resource

The oslc.properties query parameter lets you specify both immediate and nested properties of a resource to include in the HTTP response. These properties may occur zero or more times. All occurances of the specified properties are included.

The following example is described in Including Selected Nested Properties of a Resource:

 http://braintwistors.example.com/ems10/Project?oslc.properties=ems:service{dc:title}

Here we specify a nested property of ems:service. The ems:service property refers to a resource of type ems:Service which has a dc:title property.

This simple query is equivalent to the following SPARQL query:

BASE <http://braintwistors.example.com/ems10/Project>

PREFIX dc:  <http://purl.org/dc/terms/>
PREFIX ems: <http://open-services.net/software-metrics/>

CONSTRUCT {
   <> ems:service ?v1 .
   ?v1 dc:title ?v2.
}      
WHERE {
   { 
      <> ems:service ?v1 .
   }
   UNION
   {
      <> ems:service ?v1 .
      ?v1 dc:title ?v2
   }
} 

The CONSTRUCT clause contains two triple patterns that represent the property ems:service and the nested property ems:service{dc:title}.

The WHERE clause is the UNION of two graph match patterns. The first pattern matches ems:service. The second matches ems:service{dc:title}.

The general structure for matching properties is to view the oslc.properties query parameter as specifying a tree rooted at the base URL with an arc for each property name that appears in it. In this example, the tree is a linear chain of three nodes, i.e. (<>) ems:service (?v1) dc:title (?v2). Each arc in the tree corresponds to a graph pattern in the UNION, i.e. each unique path of one or more arcs from the root node corresponds to a graph pattern. Here the two paths are (<>) ems:service (?v1), and (<>) ems:service (?v1) dc:title (?v2).

Example 4: Including Properties of Collection Members

The following example is described in Including Selected Collection Member Resource Properties:

 http://braintwistors.example.com/ems10/Project?oslc.select=dc:identifier

This simple query is equivalent to the following SPARQL query:

BASE <http://braintwistors.example.com/ems10/Project>

PREFIX dc:  <http://purl.org/dc/terms/>
PREFIX ems: <http://open-services.net/software-metrics/>

CONSTRUCT {
   <> ems:memberProject ?member .
   ?member dc:identifier ?v1 .
}      
WHERE {
   { 
      <> ems:memberProject ?member .
   }
   UNION
   { 
      <> ems:memberProject ?member.
      ?member dc:identifier ?v1 .
   }
}

The CONSTRUCT clause has two triple patterns. The first pattern constructs the membership properties for the member resource. The second pattern constructs the dc:identifier properties of the member resources.

The WHERE clause is the UNION of two patterns. They match the member resources and their dc:identifier properties. All member resources are included in the query response since oslc.where was not present.

Comments

Added your comments here: