W3C home > Mailing lists > Public > public-ldp-wg@w3.org > March 2013

Re: ACTION-43 Draft use case for ordering

From: Alexandre Bertails <bertails@w3.org>
Date: Mon, 25 Mar 2013 15:06:41 -0400
Message-ID: <5150A041.5020600@w3.org>
To: Richard Cyganiak <richard@cyganiak.de>
CC: Steve Speicher <sspeiche@gmail.com>, public-ldp-wg@w3.org, Erik Wilde <Erik.Wilde@emc.com>
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.


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


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


> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:38 UTC