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

hello richard.

> Erik, I agree that inference shouldn't be necessary to implement an LDP server. But I'm not aware that anyone in this WG suggested otherwise :-)

i'll cite you on that one ;-) but it's not just heavy duty requirements 
such as inference (but that's the kind of thing we really need to look 
out for). it's also the question of whether certain semantics are 
exposed on the resource level (i can have URIs and thus link to the "LDP 
resource creation container" as well as to the "LDP content creation 
container"), or whether i need to peek into RDF to find out about this 
difference.

this is what spawned this discussion: how to differentiate maybe (if we 
want that feature) how we can allow POSTing of LDP things that are 
treated as LDP, and of LDP things that the server will treat opaquely. i 
suggested different links to different interactions, and you had a 
different design idea. that was the starting point, but we (i) have 
diverged from that a bit, i guess.

> The fact that JSON's data model is easier to work with than RDF in most programming languages is unfortunate, but it comes sort of with the territory.

yes, it's basically the same as XML: no simple natural mapping to native 
programming language data models, and there's nothing that can be done 
about that (unless you start using programming languages that have RDF 
as their native data model).

cheers,

dret.

Received on Sunday, 24 March 2013 00:07:37 UTC