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: