[oslc-core] Representing the order of triples in a query response that uses oslc.orderBy

[Arthur Ryman]

Some implementers have reported a gap in the Core spec. This note 
summarizes the gap and proposes a solution.

Problem Statement

The main design point of OSLC Simple Query is that it always returns a 
subset of the triples about the resources hosted by a service. The 
semantics of a query is that it is a filter on the set of all triples. 
This means that no triples are altered and that no triples are added. 
Triples can be deleted though - that is the whole purpose of a filter. 
These sematics have the advantage that a client knows it is always dealing 
with a subset of the triples. It can display them, copy them, etc.

However, it is also useful to impose an ordering on the results even 
though this goes beyond what is explicitly represented as triples in the 
service. The ordering depends on the query and is therefore changes with 
the query, i.e. it is not instinsic to the triples. There are two cases 
where Query supports this:

1. Full text search. oslc.searchTerms lets you specify search terms and 
the results are returned in ranked order. To communicate the ranking, we 
introduced the "pseudo-property" oslc.score. So in fact we are adding 
triples, but these are clearly distinguishable from the service's triples.

2. Sorting. oslc.orderBy lets you sort the results by one or more keys.

In an XML world, the results are ordered. However, in an RDF world, the 
results are triples and they are unordered. Nevertheless, ordering is 
still useful when it comes to large results and paging. The service is 
required to split the results into pages such that the results on page 1 
are ordered ahead of the results on pages 2, 3, ... , the results on page 
2 are ordered ahead of page 3, 4, ..., etc. So the relative order is 
preserved in pages, but the order in a page is not preserved.

The rationale for not representing the order within a page was that the 
client issued the query with the oslc.orderBy clause and therefore knows 
the desired ordering. It can therefore resort the results when it needs to 
display or process them.

Implementers are now providing feedback that requiring the client to 
re-sort the results is a burden, especially on under-powered clients such 
as web browsers. The following is a proposal for returning the order.

Proposed Solution

The Core spec defines an oslc:ResponseInfo resource type which is used to 
convey paging information. We can therefore use this resource to also 
convey the ordering of the resources on the current page. RDF defines the 
rdf:Seq resource class to represent ordered sets, and the infinite set of 
membership properties, rdf:_1, rdf:_2, etc. to represent the position of a 
member within an ordered set. We can therefore introduce a new, optional, 
OSLC Core property, oslc:orderedResults and include it in the 
ResponseInfo. e.g.

<http://example.org/query?...&oslc.orderBy=dcterms:identifier> a 
oslc:ResponseInfo ;
        oslc:orderedResults [
                a rdf:Seq;
                rdf:_1 <resource-1> ;
                rdf:_2 <resource-2> ;
                etc.
        ]

To find the sorted order match on a graph pattern:

 ?query a oslc:ResponseInfo ;
        oslc:orderedResults ?seq

This gives ?seq as the rdf:Seq resource that contains the order of the 
results.

Regards, 
___________________________________________________________________________ 

Arthur Ryman 

DE, PPM & Reporting Chief Architect
IBM Software, Rational 
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)