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

hello james.

On 2013-03-25 06:54 , James Leigh wrote:
> On Sun, 2013-03-24 at 22:38 -0700, Erik Wilde wrote:
>> 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".

you may or may not have seen 
http://www.w3.org/2012/ldp/wiki/ISSUE-37#AtomPub_example, where i tried 
to do exactly that: start from a well-known working RESTful service, and 
develop our model based on this inspiration. some differences might 
occur because of different use cases or because of differences between 
XML and RDF models, but essentially, there are many similarities where 
we don't necessarily have to reinvent the wheel, or at least can look at 
existing wheels.

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

the interesting side-effect of this design is that you cannot create an 
atom entry as a media resource, or only after going through a weird 
dance of POSTing something different first, and then updating it with a 
atom media type. that's fine because not having atom entries as content 
of atom entries is probably something that very people see as a missing 
feature.

but it only works as well because atom uses a media type for 
interactions, and thus you can happily POST XML to a collection and 
those will become media resources. you could even POST something that 
*look* like a atom entry, but label it as application/xml, and it still 
would be treated as XML (and not an atom entry) because that's what the 
media type does: it dictates protocol semantics. any atompub server 
looking at XML labeled as application/xml, seeing that it is an atom 
entry, and then processing it as an atom entry would be broken.

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

sort of. but type is not a registered media type parameter of turtle, so 
you cannot actually to that. also, my suggestion would be to use profile 
instead (http://dret.typepad.com/dretblog/2013/03/on-profiles.html), but 
that one isn't a registered media type parameter either. but yes, what 
you're proposing is probably what we will have to do, given that it's 
unlikely that we will actually expose the LDP-ness of LDP resources at 
the media type level.

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

that's another pattern we might use, and you can essentially get the 
same job done both ways. personally, i think it's more elegant to 
simplify navigation and use media types for driving service behavior, 
but that is just a preference on how you use certain parts in the web 
toolbox to get a given job done. both ways work, and have different pros 
and cons.

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

how do you validate, and how are the expectations of the server (this is 
what i expect, this is what i reject) communicated to the client? do you 
actually have a schema or something along those lines?

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

nice. now to the messy part: if you wanted to expose an "inlined" 
version of such a thing, but it makes statements that actually also 
would have validated as an interpreted resource (had it been POSTed to 
the first URI), how to you even handle this in RDF? in most models i 
know, inlining is rather simple because you have containers as part of 
the metamodel (such as trees in XML). RDF doesn't have that, and for 
server-side management using graphs works fine. but what about designing 
representations that should expose various graphs, and it actually 
matters which graph a triple appeared in. is that something you do 
expose? is that something you even can expose?

cheers,

dret.

Received on Monday, 25 March 2013 18:41:46 UTC