some thoughts on ordering

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 Monday, 17 February 2014 18:16:31 UTC