Re: ACTION-43 Draft use case for ordering

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

I hope that you didn't bring the rdf:list idea because of its native
support in the Turtle 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”.

What you describe is a List and I'm completely fine with it. What I
need here is a *lazy* list. There is no contradiction if we use the
right terminology.

I didn't know about the "properly terminated" thing, which looks weird
to me. One of the reasons I prefer rdf:list over OLO (which by the way
is not really an ordered list but an indexed list...) in the context
of Linked Data is that I can look at the head of the list without
reading it entirely.

Alexandre.

>
> 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:38:41 UTC