Re: ACTION-43 Draft use case for ordering

I think that using an rdf:List to express the order of items, rather than through the property used for ordering, could be simpler on clients.

For example, if we have three events

  :event_2012-12-01
  :event_2013-01-14
  :event_2013-03-04

that are ordered by date in a container response, I think it would be better to say (note that this is Turtle shorthand syntax for creating an rdf:List):

  <container> ldp:order (:event_2012-12-01 :event_2013-01-14 :event_2013-03-04).

And we shouldn't say:

  <container> ldp:orderProperty dc:date.

If we specify the order explicitly by a list property, then client and server need to agree on the sort semantics for that property. This is a (slight) burden for the standard literal datatypes, but becomes rather difficult when custom datatypes are used.

The downsides of the rdf:List approach are that rdf:Lists are a bit icky to work with in some RDF toolkits. It's also a bit more verbose as the example shows.

Best,
Richard




On 25 Mar 2013, at 17:34, "Wilde, Erik" <Erik.Wilde@emc.com> wrote:

> hello steve.
> 
> On 2013-03-25 6:58 , "Steve Speicher" <sspeiche@gmail.com> wrote:
>> Bug tracking tools often have thousands of bugs reported.  Making a
>> request on these is often filtered down based on the state or
>> project/timeline associated with, but often ordered based on some
>> defined ordering: last modified, highest priority, status, creator,
>> etc.  Since RDF is unordered and the response may be split across
>> pages, there needs to be a way to indicate what the order is.
>> Otherwise, the client will have to discover the intended order by
>> other means and also if the response was split across pages responses,
>> it would be preferred to have member resources on the current page
>> based on ordering predicates that occur before those found on the next
>> page.
> 
> this is an excellent use case and a very popular one, too. adding to this,
> it often is equally important to be able to choose what to order on
> (unless there is some implicit assumption somewhere, such as many feeds
> being ordered by update time). going further, you might also want to
> filter things, but that becomes pretty tough because of the potential
> complexity of the filter expressions. neither ordering nor filters should
> be based on the back-end processing of ordering/filtering requests in RDF;
> they should simply identify exposed capabilities of the service, which
> then can map them to whatever implementation it is based on. RDF-based LDP
> services then internally map them to SPARQL, SQL-based LDP services
> internally map them to SQL, and so forth.
> 
> regardless of how far we go down the line of ordering, exposing order
> keys, and exposing filtering capabilities, all of this should be based on
> the same general mechanics that we are going to use for the paging
> mechanism: if these are fixed URIs, we should expose them as typed links
> to fixed URIs; if these are parametrized URIs, we should expose them as
> URI templates. and as for paging, we then would expect LDP to standardize
> the relevant concepts (how to identify URI template variables for sort
> order, order keys, or filter expressions).
> 
> cheers,
> 
> dret.
> 
>

Received on Monday, 25 March 2013 18:32:59 UTC