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)
