- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Mon, 25 Mar 2013 20:24:33 +0000
- To: Erik Wilde <dret@berkeley.edu>
- Cc: Kingsley Idehen <kidehen@openlinksw.com>, public-ldp@w3.org
On 25 Mar 2013, at 20:07, Erik Wilde <dret@berkeley.edu> wrote: >> I don't see how anybody wins in this scenario. > > LDP wins, because now LDP clients don't have to (pretend to be) generic RDF clients (and the same is true for servers). Boy. This is like introducing a new media type for HTML when forms were invented, and justifying it by saying “now form-capable browsers don't have to pretend to be generic browsers”. A read-only LDP client *is the same* as a generic RDF client. A generic RDF server *is the same* as a non-writable LDP server. The HTTP GET side of LDP is exactly what is already deployed on hundreds of Linked Data sites around the web. All that LDP is doing is adding a POST/PUT/DELETE story to that. Breaking free backward compatibility by introducing a new media type, and breaking all existing RDF clients that could provide read-only access to LDP server for free, strikes me as an exceptionally poor design choice. > they speak LDP and nothing else. They also speak read-only linked data, as it is already deployed on hundreds of sites on the web. > they can make this explicit in HTTP conversations. how is that not a win for a protocol that explicitly intends to bridge RDF and non-RDF worlds? LDP doesn't intend to bridge RDF and non-RDF worlds. If it ends up doing so, that's a happy side effect. LDP intends to provide HTTP-based application integration based on read/write Linked Data. Best, Richard > > cheers, > > dret.
Received on Monday, 25 March 2013 20:24:55 UTC