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


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.


On 25 Mar 2013, at 17:34, "Wilde, Erik" <> wrote:

> hello steve.
> On 2013-03-25 6:58 , "Steve Speicher" <> 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