[oslc-core] Representing the order of triples in a query response that uses oslc.orderBy
Paul Slauenwhite
paules at ca.ibm.com
Thu Apr 19 13:55:25 EDT 2012
Sounds good Steve.
RQM plans on doing an implementation in RQM 4.0 RC3 as a proof-point.
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: Steve K Speicher/Raleigh/IBM at IBMUS
To: Paul Slauenwhite <paules at ca.ibm.com>
Cc: oslc-core at open-services.net, Arthur Ryman <ryman at ca.ibm.com>
Date: 04/18/2012 04:43 PM
Subject: Re: [oslc-core] Representing the order of triples in a query
response that uses oslc.orderBy
Paul,
As was discussed at the April 4th [1] I took the action to propose a way
forward based on what was recommended in this thread originally by Arthur
and also taking into consideration the Linked Data Basic Profile W3C
submission proposal [2].
There are a couple options to consider for order:
1. JSON
We discussed this and due to the nature of JSON the arrays are ordered
(whether you want them ordered or not)
2. RDF/XML
There are a number of ways to express order and I'd recommend using the
bp:containerSortPredicates from the LDBP [2]. Instead of introducing
bp:Page, which has no harm, you could just add a few things to the
response of the query: 1st and ordering predicate, anything you pick that
is right for your domain model, for each "result" triple such that you
have:
<resourceUrl1> mynm:idx 1.
<resourceUrl2> mynm:idx 2.
...
and 2nd adding the bp:containerSortPredicates statement to
oslc:ResponseInfo:
<requestUrl?oslc.orderBy=mynm:idx> bp:containerSortPredicates (mynm:idx).
By introducing this little bit of LDBP, it would be interesting to hear
some feedback on how this implementation progresses and look to see what
the right recommendation would be to adopt for Core 2.0 if needed.
[1] - http://open-services.net/bin/view/Main/OslcCoreMeetings20120404
[2] - http://www.w3.org/Submission/2012/SUBM-ldbp-20120326/#bpc-ordering
Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645
> From: Paul Slauenwhite <paules at ca.ibm.com>
> To: Arthur Ryman <ryman at ca.ibm.com>,
> Cc: oslc-core at open-services.net, oslc-core-bounces at open-services.net
> Date: 03/30/2012 07:57 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
>
> 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?
>
> [image removed]
>
> Paul Slauenwhite
>
> IBM Software Group, Rational
>
> IBM Toronto Lab, Canada
>
> [image removed]
>
> Phone:
>
> 905-413-3861
>
> [image removed]
>
> Tie-Line:
>
> 313-3861
>
> [image removed]
>
> Mobile:
>
> 902-221-6721
>
> [image removed]
>
> E-mail:
>
> paules at ca.ibm.com
>
> [image removed]
>
> [image removed]
>
> [image removed]
>
> Please consider the environment before printing this email.
>
> [image removed]
>
>
> [image removed] Arthur Ryman---12/14/2011 05:26:27 PM---John, As we
> discussed in our telecon today:
>
> 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
>
> _______________________________________________
> 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/20120419/07338579/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/20120419/07338579/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 26992415.gif
Type: image/gif
Size: 1851 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120419/07338579/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 26065641.jpg
Type: image/jpeg
Size: 9832 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120419/07338579/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/20120419/07338579/attachment-0002.gif>
More information about the Oslc-Core
mailing list