Re: paging in editor's draft

Howdy Erik

> sure they are, and that's fine because that's how RDF works. but what i 
am
> asking about is *resource order*, not *triple order*. 

Given that I know you've been aware in the past that HTTP URL != 
subject(s) of triples stored at that URL, and given that one (each) page 
is the only HTTP resource in play here, this is a surprising distinction 
for you to try on.  But I'll try to follow along.

> if i get resources
> a, b, and c on a page, 

What that means (assuming the simplest membershipXXX case) is you get 
triples on each page:
<ldpc,rdfs:member, memberA >
<ldpc,rdfs:member, memberB >
<ldpc,rdfs:member, memberC >

We removed inlining weeks ago.  A server is still allowed to send extra 
triples (including "the content of" members A, B, C) if it likes, but the 
interpretation of that is now wholly outside of LDP.

The problem Henry and others observed with just smushing all the triples 
into a Turtle/similar representation of the page (merging their graphs) is 
that it's impossible to determine the boundaries between what's stored at 
A, B, C ... which subset of the triples came from each HTTP resource.  Aka 
"the quotation problem" or "loss of provenance".

Formats like TRIG and N-quads would allow sending the member contents too 
without loss of provenance and without additional HTTP requests, and they 
can be content-negotiated with the server.  Both just went to CR, as it 
happens.

> and based on the server-side ordering, these should
> be ordered (a, b, c), so that i can reasonably display them in an 
ordered
> UI (such as rows in a table), is that order of the resources 
represented,
> or not?

Any within-page ordering present in the serialized triples of the page MAY 
be present, but an RDF client has no way to see it absent using its own 
deserializer that preserves the ordering somehow.  LDP's sorting 
predicates only define the order between members on different pages, not 
within a page, because of the "a page is a set of RDF triples, and RDF 
triples are unordered sets" logic.

> of course the triples making up a, b, and c themselves are not ordered,
> and that's perfectly fine because that doesn't matter in RDF; but in 
REST,
> link semantics matter, and i would expect clients to be able to
> distinguish between the links for the first, second, and third resource.

So let's try that out (trivial example, assuming we still had inlining and 
we use a Turtle-like format).  Doing this by hand, so pfttht in advance to 
anyone who complains about syntax.
On my server, members A, B, C, each contain exactly one triple, and in 
fact the same one < henry , likes, quoted-formats >.
Page 1: 
<ldpc,rdfs:member, memberA >
<ldpc,rdfs:member, memberB >
<henry , likes, quoted-formats >


Page 2: 
<ldpc,rdfs:member, memberC >
<henry , likes, quoted-formats >

A client receiving page 1 has no way to know whether the triple <henry , 
likes, quoted-formats > is stored in memberA, memberB, or both.  Now if 
you have some way outside LDP for the client to know that each member only 
stores triples whose subjects are related to their HTTP URL (e.g. they're 
equal), then the problem is solved.  But that's a more specific case than 
what LDP covers.


Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario