[oslc-core] Representing the order of triples in a query response that uses oslc.orderBy
Paul Slauenwhite
paules at ca.ibm.com
Fri Mar 30 19:56:45 EDT 2012
OSLC Community,
I would like to rekindle this discussion to find a conclusion and
(hopefully) amend the current OSLC specification so implementers can adjust
their implementations accordingly. QM is in favor of solution #1 (e.g.
rdf:_X/page). Thoughts?
Paul
Slauenwhite
IBM Software
Group,
Rational
IBM Toronto
Lab, Canada
Phone: 905-413-3861
Tie-Line: 313-3861
Mobile: 902-221-6721
E-mail: paules at ca.ibm.com
Please
consider the
environment
before
printing
this email.
From: Arthur Ryman/Toronto/IBM at IBMCA
To: John Arwe <johnarwe at us.ibm.com>
Cc: oslc-core at open-services.net,
oslc-core-bounces at open-services.net
Date: 12/14/2011 05:26 PM
Subject: Re: [oslc-core] Representing the order of triples in a query
response that uses oslc.orderBy
Sent by: oslc-core-bounces at open-services.net
John,
As we discussed in our telecon today:
1. My suggestion was to provide the ordering within a page (rdf:_1 appears
in each page) since this is slightly easier for servers to do. However,
providing the global order would also work.
2. An alternative is to add another "pseudo-property" each resource like
we do for full text search, e.g. oscl:sortedOrder.
3. Yes, each URI is a different resource, but the semantics of the query
string defines that the RDF representation of the resource is a subset of
the triples in the service, i.e. the URI of the resource is not
necessarily the subject of any triples. We do violate this rule when it
comes to representing the order of full text search so we might as well
also violate it for sorting. In both cases we'd be adding triples to
convey the order.
Regards,
___________________________________________________________________________
Arthur Ryman
DE, PPM & Reporting Chief Architect
IBM Software, Rational
Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)
From:
John Arwe <johnarwe at us.ibm.com>
To:
oslc-core at open-services.net
Date:
12/14/2011 12:48 PM
Subject:
Re: [oslc-core] Representing the order of triples in a query response that
uses oslc.orderBy
Sent by:
oslc-core-bounces at open-services.net
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
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120330/acc3a3ad/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120330/acc3a3ad/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 35363420.gif
Type: image/gif
Size: 1851 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120330/acc3a3ad/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 35417072.jpg
Type: image/jpeg
Size: 9832 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120330/acc3a3ad/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120330/acc3a3ad/attachment-0002.gif>
More information about the Oslc-Core
mailing list