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

Erik,

I'm not sure what point you are trying to get across. I didn't say anything that assumes or requires that LDP clients are “full-blown RDF processing entities”. In fact, I have no idea what a 
“full-blown RDF processing entity” is.

Richard


On 23 Mar 2013, at 16:58, Erik Wilde <dret@berkeley.edu> wrote:

> 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 17:48:11 UTC