ldp-extensions, ldp-paging, and Re: some thoughts on ordering

On 02/17/2014 05:46 PM, Ashok Malhotra wrote:
> Hi Sandro:
> The idea of using a Link Header to specify sort criteria is good.
> The idea of applying sorting to arbitrary graphs is great!
>
> But then, sorting is not so closely linked with paging.

As it's currently in the spec, sorting only matters when there is 
paging.   The idea is that order of RDF triples never matters during 
serialization.   So the server might sort them, but the servers 
serializer, the clients parser, etc, are free to scramble them.  In the 
end, order only comes into play when dividing the triples into pages 
which are ordered.

> We can still put sorting and paging in a separate spec but the main
> spec needs to refer to the paging/ordering spec in a carefully worded
> paragraph.
>

Yes, Eric raised this concern at the end of the call, when I got 
disconnected.    He suggested that moving paging out would be a problem, 
since then we can't say LDP Clients have to understand paging.    As it 
turns out, we don't say that now (at least that I could find), but 
perhaps that's an accident and we mean to say it. If that's what we mean 
to say, then we could still do that, with a normative reference from LDP 
to LDP Paging.   That would mean LDP Paging would have to progress to 
REC as well, but it can be a little behind LDP.    Middle ground is we 
say clients have to implement paging, but we make that text "at risk".

My own preference would be to not have such a normative reference. 
Instead, maybe we could include a paragraph about the idea of LDP 
extensibility, and give paging as an example.   Maybe we could even link 
to a web page where we have a list of LDP extensions / modules.

I've got a very rough draft of such a page, listing the extensions I'm 
thinking Andrei and I will need for our project.  I could turn that into 
a wiki page at http://www.w3.org/2001/sw/wiki/LDP or some place like that.

     -- Sandro

> Also, two specs may delay completing our work and Arnaud may be
> concerned about that.
> All the best, Ashok
>
> On 2/17/2014 1:16 PM, Sandro Hawke wrote:
>> Looking at ordering, after the call today.    Maybe we'll come back 
>> to this after LC on the main spec?
>>
>> - I think the design of ordering predates our current style of using 
>> the Link header for server-provided metadata.  Now,  I think the 
>> ldp:containerSortCriteria triple should be provided in a Link header, 
>> not inside the body.    It would be providing a link to a 
>> server-managed page which just describes the sort order (and maybe 
>> other stuff, like container metadata).
>>
>> - This would, coincidentally, actually provide a way for the client 
>> to specify the sort order it wants -- it could do its GET with that 
>> Link (or Prefer?), linking to a page it created somewhere.   If the 
>> server wanted to honor that, I'd expect it to 303 over to a resource 
>> that's sorted in that order.
>>
>> - I note ldp:pageOf occurs in the ordering example.   (We talked 
>> today how it accidentally got dropped from the normative parts of the 
>> spec.)
>>
>> - It looks like ordering only applies to LDPCs.    Thinking about how 
>> to generalize it to arbitrary graphs...
>>
>>     -- first off, what's being ordered here is the membership 
>> triples, right?   What about the containment triples?    How do those 
>> sort relative to each other?   I guess it would be logical to put { 
>> <s> ?p <o> } triples on the same pages, always.
>>
>> In general, we're assuming a graph with a large number of triples 
>> that differ in only one position (the subject or object), and we're 
>> sorting the triples based on the properties of that subject or 
>> object, found in a different graph, obtained by dereferencing that term.
>>
>> Interestingly, I think one could sort ANY RDF graph using that sort 
>> of principle, and not go too wrong.   You don't even have to know 
>> which predicate is the membership predicate, etc, because >99% of the 
>> triples will all follow the same pattern.
>>
>> So:
>> 1.  dereference all subjects and objects to get the data needed for 
>> sorting.   (with LDP servers, this is usually a no-op)
>> 2.  sort all the triples by applying the sort criteria to the 
>> subject.  (with forward membership predicates, this is a no-op)
>> 3.  within that order, sub-sort by applying the sort criteria to the 
>> object.  (with inverse membership predicates, this is a no-op)
>> 4.  any triples with the same subject and object are kept on the same 
>> page (or just considered equal for sorting?)
>>
>> I think this does what the current spec does, but also should work 
>> for arbitrary graphs.
>>
>> For my app, I also want inlining of member triples.  As long as they 
>> are kept in separate named graphs, that wouldn't have to interfere 
>> with ordering.
>>
>>        -- Sandro
>>
>>
>
>
>

Received on Tuesday, 18 February 2014 00:45:50 UTC