Re: paging in editor's draft

hello john.

On 2013-11-12, 6:54 , "John Arwe" <johnarwe@us.ibm.com> wrote:
>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.

without going into any details: yes, that's definitely the core of the
problem. RDF currently has no concept of a "resource/document" or whatever
you might call it. that creates problems on all kinds of fronts, and we
simply ran into yet another one. i don't think we can fix this aspect of
RDF in any easy way, other than choosing to only support serializations
that actually can represent resource/document boundaries. making that
choice would simplify LDP dramatically, instead of designing all these
band-aids and realizing their limitations.

i wrote about this quite a while ago (i am sure i have linked to
http://dret.typepad.com/dretblog/2009/05/rest-and-rdf-granularity.html
before), and for a while i think it looked a little bit as if RDF 1.1
might actually turn named graphs into first-level RDF citizens. from the
REST point of view, that would have solved *many* of the problems where
there's a distinct mismatch between how REST focuses on resources as the
main abstraction, whereas RDF has no concept to match that (when in
contrast XML documents and JSON objects provide easy choices in those
other metamodel worlds).

i guess whatever LDP chooses to do in the pure RDF 1.0/1.1 space will look
and feel a bit awkward, but that's more RDF's fault than it is LDP's
fault. personally, my hope is that this will make it more obvious that a
concept bigger than the triple would be a useful addition to RDF itself. i
really don't want to turn this into a debate around RDF's future and what
should or should not be done there, but i think what we're dealing with is
simply this REST/RDF mismatch, and the only thing we can do is to decide
how to best manage it.

cheers,

dret.

Received on Tuesday, 12 November 2013 20:18:56 UTC