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

[John Arwe]

Thanks for stating things clearly Arthur, as usual. 
Question your formulation: would the rdf:li triples (rdf:_1 etc) provide 
ordering -within- 1 page only (I think so) or a global ordering across all 
pages in the notional result set (or either).

As background, the particular implementation that surfaced this problem to 
me (there may be others) has a typical SQL DB back end and uses Jena to 
serialize the RDF representations from the DB's result set.  The results 
are ordered in their implementation by the SQL DB.  Having read the 
Primer, they were aware of the guidance to use rdfs:Container and 
rdfs:member for collections (they are also on a path to become CM 
producers, where this is a SHOULD for RDF/XML).  They deal with 
collections large enough that they feel it necessary to support Paging as 
well as sorting.  Since rdfs:Container is unordered, in oslc.orderBy case 
they cannot even do the DB query once, dump the results into Jena, and 
OSLC-page the results from there (because they lose the global wrt pages 
sorting upon entry to Jena).  In such an implementation they end up 
sorting in the DB back end, piping the result set into Jena, sorting it 
again at least once (they seemed to think twice, not sure about that).

Having now thought about this a for a few days, I find myself questioning 
whether the ordering is being imposed on the results or we have fallen 
into the trap of mixing interface and implementation.
> 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. 
This is where we may be mixing interface (client's view) with 
implementation (server's view).  Alternative formulation:

If I were to come at this from an HTTP client's point of view (where I 
know nothing about the implementation), I have to assume that every unique 
URL names a unique resource (via WebArch).  Whether or not the client 
constructs the URL does not matter.  Framed that way, I could argue that 
when the client uses URLs (that it constructs, or that it was given) 
containing oslc.orderBy, the HTTP resource referred to is an ordered (sic 
- rather than UNordered) set.  Whoever constructed the URL used 
oslc.orderBy precisely because they intended the collection to be ordered. 
 In that way of thinking, one would indeed make the ordering visible via 
the triples.  There might be reasons to represent that ordering using 
different predicates (Seq vs List model) worthy of discussion, but only if 
we accept this alternative framing of the problem.  It does have the 
advantage of requiring no new invention in the specs.

If I were to take the liberty of adjusting the excerpt I quoted above from 
Arthur to align with that formulation, it might look like this:
However, it is also useful to expose another resource that imposes an 
ordering on the members, even 
though this may not be what is explicitly represented in the 
underlying implementation. The ordering depends on the query URL and 
therefore changes with 
the query, i.e. it is intrinsic to the resource's triples as far as the 
client can discern.


Steve Speicher: during the course of Research, I found that CM 2.0 [1] has 
a statement saying that Core Examples recommends rdfs:member; when I 
followed the link to the latter and searched, 0 hits.
"For RDF/XML and XML, use rdf:Description and rdfs:member as defined in 
OSLC Core RDF/XML Examples"
[1] http://open-services.net/bin/view/Main/CmSpecificationV2

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20111214/b9802b7f/attachment-0003.html>