Re: ACTION-43 Draft use case for ordering

On 25 Mar 2013, at 19:06, Alexandre Bertails <bertails@w3.org> wrote:
>>   <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.

I have mixed feelings about this. It would no longer be possible to use the handy (a b c) Turtle shorthand syntax.

In the RDF WG, we have discussed the concept of a “well-formed list”, which is an rdf:List that consists only of blank nodes, doesn't have branches or other weird stuff going on, and is properly terminated. In other words, it's what you get from parsing the Turtle shorthand syntax.

What you describe wouldn't meet that definition. The discussion pretty much died without any decision, so it looks like we won't formally define that concept in RDF 1.1. But I've been thinking so far that it's best practice to only use rdf:List as “well-formed lists”.

Best,
Richard



>> 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:26:25 UTC