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

hello richard.

On 2013-03-23 6:27 , Richard Cyganiak wrote:
> We've had this discussion before. In the context of RDF, the media type (say, text/turtle) essentially delegates this question to vocabularies. If a client knows a particular vocabulary (say, FOAF), then all is good; it knows what to expect for any given property. If the client doesn't know the vocabulary, then at least it knows that here's some sort of relationship to some sort of web resource, but it won't know what to expect at the other end.
> So the story for RDF is a bit more complex than for other media types. RDF itself has no semantics whatsoever; it just provides a bag of triples. All the semantics in an RDF representation come from the vocabularies used in the representation. To paint the full picture of RESTful interactions with RDF, it's not sufficient to talk about media types; one also needs to talk about the vocabularies that a particular client understands. (But vocabularies can be seen as an extension mechanism provided by the media type, I suppose.)

i agree that indeed we have had this discussion before. the reason why 
it comes up again and again is that it is all about processing models. 
what does a client need to do to get useful stuff done with the LDP 
service? we decided very early that LDP specifically was not intended to 
assume that client and/or server are full-blown RDF processing entities; 
they could very well be implementation using different data models 
internally, and all they are using RDF/Turtle for is for driving the 
protocol (in the same way as many peers exchanging XML-based messages 
are definitely not using XML data models internally; they just use data 
binding of some sort).

if the LDP design assumes that on either side you need to be a 
full-blown RDF implementation to get useful stuff done (or anything done 
at all), then we have failed to make LDP useful for a much larger 
potential set of consumers/providers.

it's convenient to assume homogeneous ecosystem, but it's also a trap 
that will make LDP more limited in terms of potential users than we 
could make it. if we're serious about making it a service for any 
consumer/producer, not just RDF-driven components, then we have to 
adhere to the web's mechanics. for everything we do, we have to ask 
ourselves: if i am implementing a server or client that is not natively 
using RDF, how easy/hard will it be to use LDP? i am fully aware that 
this makes LDP a bit more inconvenient/awkward from the pure RDF point 
of view, but on the other hand it means that we're building a bridge 
between native RDF agents, and other that only serialize/deserialize to 
RDF, and can be based on any model. this is not an easy undertaking, but 
i think we have the opportunity to bridge this gap with LDP.

(( for those of us dabbling in XML: this whole situation is the 
equivalent to the question of whether you make XSD processing a 
mandatory part of your XML-based service. you easily could be designing 
rich schemas and delegating any meaningful semantics to XSD validation 
and resulting PSVI annotations. that's elegant and kind of convenient 
when you're an XSD-based implementation and want to base everything on 
type-based processing. but nobody designs services this way because you 
would exclude the 99% of implementations that use XML for data-binding 
and simply won't support any service models based on PSVI processing. ))

cheers,

dret.

Received on Saturday, 23 March 2013 16:59:13 UTC