Re: Section 4: LDPR/non-LDPR formal definitions

Hi dret,

Thanks for the interesting posts over the weekend. I enjoyed reading
your responses.

On Sun, 2013-03-24 at 22:38 -0700, Erik Wilde wrote:
> hello richard.
> 
> On 2013-03-23 6:08 , Richard Cyganiak wrote:
> > On 23 Mar 2013, at 01:08, Erik Wilde <dret@berkeley.edu> wrote:
> >> that means we're unable to support a case where somebody want to POST something that looks like an LDP resource, but isn't treated as one by the server (the LDP would be treated as opaque by that server).
> > As I read the current spec, there is no way for the client to indicate, or for the server to communicate in advance, whether a Turtle representation POSTed to a "factory-enabled" container will create a full-blown LDPR or not.
> > I'm not sure how much of a problem that is. I could live with it, I guess.
> 
> my guess is that most people can live with that. i just think it's 
> interesting to think about this when we design our interactions of the 
> media type. it's a suspicious design smell if we wouldn't be able to do 
> this out of fundamental reasons, but we very well might not take this 
> feature into consideration for our design to simplify the LDP service.
> 

We really should be comparing this with existing standards like AtomPub.
In particulary, Section 9.6[1], which states "A client can POST Media
Resources as well as Entry Resources to a Collection".

RFC5023 says that if the media type is "application/atom+xml" or
"application/atom+xml;type=entry" then the client is posting metadata
about a member entry that should be added to the collection (combined
with server-side metadata), otherwise "If a server accepts such a
request, then it MUST create two new Resources -- one that corresponds
to the entity sent in the request, called the Media Resource, and an
associated Member Entry, called the Media Link Entry."

I think this works for AtomPub because the media type "application/atom
+xml;type=entry" isn't of much use outside of the protocol. If LDP has
one collection URL to POST new resources to, it would have to define a
media type that was fairly specifically for creating LDPR, as all the
existing RDF media types have fairly general uses.

Inspired by AtomPub a media type like text/turtle;type=entry (to
indicate all triples are about the same informal/abstract entity), would
be enough to distinguish between the clients intentions.

> > A use case where this would be a problem would be something like where a client wants to use an LDP server to archive some Turtle files, and the client wants assurance that the server won't mess with the POSTed file by inserting server-managed metadata.
> 
> i such a case i would expect the client to POST text/turtle, and ideally 
> by POSTing this instead of POSTing text/ldp+turtle the client would make 
> clear that the representation should be treated as generic turtle, 
> without any need for the server to process it according to the LDP 
> processing model.
> 
> because we very likely will not use media types, both POSTs will end up 
> using the same media type (text/turtle), and then we have two options 
> (that i can see):
> 
> - use profiles or something similar to indicate that one is to be 
> treated as opaque turtle, the other one is actually LDP payload.
> 
> - use interaction affordances that support the "we will just store 
> whatever you POST here" semantics i was talking about above, so that you 
> can safely POST text/turtle that looks like an LDP resource, but 
> shouldn't be treated as one.
> 
> > One solution might be to introduce yet another "flag" on containers that indicates whether the container is "passive" (just stores as a new resource whatever representation is POSTed, and makes the new URL a member) or "active" (only accepts Turtle or other RDF payloads, and results in creation of an LDPR).
> 
> that might be a solution, too, but it would hide these interaction 
> affordances from the HTTP level, which imho is where they belong.
> 

In Callimachus we implemented two POST targets, one target[2] for
creating new RDF resource entities (all triples about the same thing),
and another target[3] for creating media blobs that are stored
bit-for-bit. For RDF media types this distinguishes between creating an
informational/abstract entity member and creating a g-text named graph
member.

If a text/turtle is POST'd to the first target, it is validated to
ensure all triples are talking about the same thing and only the
semantic triples are stored as a member entity. If a text/turtle is
POST'd to the second target, the request payload is stored as g-text,
the triples are added to the RDF store as a (new) named graph, and a new
member entity is created for the named graph.

Cheers,
James

[1] http://tools.ietf.org/html/rfc5023#section-9.6
[2] http://callimachusproject.org/docs/1.0/callimachus-for-web-developers.docbook?view#CRUD_operations_on_RDF_content
[3] http://callimachusproject.org/docs/1.0/callimachus-for-web-developers.docbook?view#CRUD_operations_on_BLOB_content

Received on Monday, 25 March 2013 13:54:40 UTC