Re: ACTION-43 Draft use case for ordering

On 03/25/2013 02:32 PM, Richard Cyganiak wrote:
> 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.

+1

>
> 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).

Note that with this approach, you have paging for free: just
substitute a blank node with a URL where you can find the rest of the
(lazy) list.

>
> 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.

+1

>
> 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.

This may be because there was no good use-case for it until now, and
because it doesn't play well with pattern-based approaches like
SPARQL. In practice, that's the only RDF-based data-structure that is
standardized and its lazy nature is extremely useful for the use-case
we're discussing.

Alexandre.

>
> 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 19:06:49 UTC