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

On Mon, 2013-03-25 at 11:41 -0700, Erik Wilde wrote:
> 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.

Something like "text/turtle;profile=http://ldp.net/ldpr" would be really
cool as it could be applied to any (past or future) RDF format and
mostly ignored by clients/servers that don't understand it.

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

Callimachus requires the following when POST'ing a new member entity.
All the subjects of the triples must be a hashless URI, a hash URI, or a
blank node. There must be exactly one hashless URI used in a subject
position. The prefix before the '#' of all hash URIs, in the subject
position, must be equal to a hashless URI in a subject position. All
hash URIs and blank node terms, in the subject position, must also
either (a) appear in the object position of a triple with a hashless URI
(in the subject position), or (b) appear in the object position of a
triple with a term (in the subject position) that satisfies (a) or (b).

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

You can't have it both ways ;). Clients can use Callimachus as a graph
store, post, get, put, delete g-text documents and use SPARQL to query
the data in them. Clients can also use Callimachus as a linked data
entity store, post, get, patch, put, delete entities and use SPARQL to
query their metadata. If a client manages a linked data member entity,
it has no control over what named graph will be used. However, because
both use the same underlying store, a client managing g-text graph
documents can introduce new linked data entity members and/or linked
data entity properties.

Designing Callimachus applications that use named graphs as containers
is discouraged. In Callimachus, named graphs are for importing/updating
data that is managed elsewhere in a different system (like an external
vocabulary or dataset).

Regards,
James

Received on Tuesday, 26 March 2013 02:35:46 UTC