W3C home > Mailing lists > Public > public-ldp@w3.org > March 2013

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

From: Henry Story <henry.story@bblfish.net>
Date: Sat, 23 Mar 2013 18:28:32 +0100
Cc: Richard Cyganiak <richard@cyganiak.de>, Martynas Jusevičius <martynas@graphity.org>, public-ldp@w3.org
Message-Id: <9236F6EA-4CEB-4B96-BA79-E086EF398C35@bblfish.net>
To: Erik Wilde <dret@berkeley.edu>

On 23 Mar 2013, at 17: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. ))

The minimum RDF tools need for LDP at present are

  - Turtle Parser
  - Graph libraries ( to be able to query for simple patterns of relations )
  - http(s) request tools

All platforms have the above.

It helps to have very minimal reasoning cabailities ( these are easy enough to code by hand )

I don't see that anything interesting can be done by LDP without those.

What is it that Richard needs beyond the above to get something done in LDP?


> cheers,
> dret.

Social Web Architect

Received on Saturday, 23 March 2013 17:29:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:03:10 UTC