Re: some thoughts on ordering

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

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:18:09 UTC