This wiki is locked. Future workgroup activity and specification development must take place at our new wiki. For more information, see this blog post about the new governance model and this post about changes to the website.

OSLC Simple Query SPARQL Semantics V1

Early Draft

Introduction

The OSLC Simple Query Syntax V1 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 serivce 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: Selecting Properties of a Resource

The oslc.properties query parameter lets you select 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 

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/elements/1.1/>
PREFIX ems: <http://open-services.net/software-metrics/>

CONSTRUCT {
   <> a ems:Project;
      dc:title ?v1;
      ems:projectList ?v2
}      
WHERE {
   { <> a ems:Project }
   UNION { <> a ems:Project; dc:title ?v1 }
   UNION { <> a ems:Project; 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 WHERE 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 three patterns. The first pattern simply tests that the base URL does indeed exist in the service and has type ems:Project. If it matches, i.e. the base URL exists in the service, then neither ?v1 nor ?v2 are bound, so their corresponding triples in the CONSTRUCT clause are omitted from the result. The second pattern matches any dc:title properties, and the third pattern matches any ems:projectList properties, both guarded by the test that the base URL exists as a resource of type ems:Project in the service. If the second pattern matches then ?v1 is bound and ?v2 is unbound. Similarly, if the third 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. It is equivalent to the following SPARQL query:

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

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

CONSTRUCT {
   <> a ems:ProjectList;
      ?property ?value;
      ems:memberProject ?result .
}      
WHERE {
   { 
      FILTER ( ?property != ems:memberProject ) .
      <> ?property ?value
   }
   UNION
   { 
      <> ems:memberProject ?result.
      ?result 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.

The CONSTRUCT clause defines the triples to include.

Comments

Added your comments here:

 
Edit | Attach | Print version | History: r6 | r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r2 - 25 Feb 2010 - 17:25:06 - ArthurRyman
 
This site is powered by the TWiki collaboration platform Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use
Ideas, requests, problems regarding this site? Send feedback