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: Mon, 25 Mar 2013 20:56:07 +0100
Cc: Kingsley Idehen <kidehen@openlinksw.com>, public-ldp@w3.org
Message-Id: <558A41CB-3CE4-4F69-9840-E95B0708F65F@bblfish.net>
To: Richard Cyganiak <richard@cyganiak.de>

On 25 Mar 2013, at 20:54, Richard Cyganiak <richard@cyganiak.de> wrote:

> On 25 Mar 2013, at 19:43, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>> What's wrong with media type: application/ld+turtle, application/ldp+turtle or whatever else to end this most recursive line of discussion and debate?
> 
> What's an LDP client supposed to do when it sees, say, a document that professes to be an ldp:Container, but is served using text/turtle? I suppose it would have to treat it as an opaque document, and not treat it as an LDP container?
> 
> And what's an LDP server supposed to do when clients ask for text/turtle? Given that content negotiation is optional in LDP (and should remain so, to keep minimalistic servers possible), I suppose that many LDP server would have to refuse the request?
> 
> The result would be that you're bifurcating the RDF world into a part that only handles text/ldp+turtle, and another part that only handles text/turtle, for no good reason.
> 
> In reality, clients would probably tend to ignore the media type coming from the server, because of misconfigured servers that send text/ldp+turtle when they should send text/turtle, or vice versa.
> 
> I don't see how anybody wins in this scenario.

+1000

> 
> Best,
> Richard
> 
> 
> 
> 
>> 
>> A media type for RDF based Linked Data is more explicit than existing media types such as text/turtle, application/rdf+xml etc..
>> 
>> Linked Data is about a combined *application* of RESTful data interaction patterns and the RDF model for expressing and representing entity relationship semantics (some call this the RBox), entity types (some call this the Tbox), and entity instances (some call this the ABox).
>> 
>> As I've said before [1], there is a little grey area that is easily addressed via a media- or content-type for RDF based Linked Data.
>> 
>> RDF based Linked Data basic behavior is simple: URIs resolve to Documents that Describe what said URI denotes (i.e, the aforementioned URI's referent).
>> 
>> RDF != Linked Data and this fact is something we can't skirt around. It bites on both sides i.e., it hurts RDF believers and non believers alike, as these recursive threads demonstrate.
>> 
>> The rules for RDF based Linked Data are simple:
>> 
>> 1. URIs denote entities
>> 2. URIs resolve to Entity Description Documents
>> 3. Entity Description Documents are comprised of Entity Relationship Graph based Content
>> 4. Entity Relationship Graph based content is constrained by the RDF Data Model
>> 5. The RDF Model enables the construction of Entity Relationship Graph based content endowed with explicit (rather than implicit) machine-readable Entity Relationship Semantics
>> 6. Entity Type Definitions and Relationship Semantics can packed into a Vocabulary, Ontology, or Data Dictionary -- which enables loose coupling of instance data (Abox), type definition data (Tbox), and relations definition data (Rbox).
>> 
>> This is all very old stuff bar the ingenuity inherent in HTTP URIs as exemplified by today's World Wide Web (a killer application of HTTP URIs).
>> 
>> Links:
>> 
>> 1. http://lists.w3.org/Archives/Public/public-ldp/2013Mar/0036.html -- resolving this RDF and Linked Data conflation problem via a content-type for the RESTafari .
>> 
>> -- 
>> 
>> Regards,
>> 
>> Kingsley Idehen	
>> Founder & CEO
>> OpenLink Software
>> Company Web: http://www.openlinksw.com
>> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
>> Twitter/Identi.ca handle: @kidehen
>> Google+ Profile: https://plus.google.com/112399767740508618350/about
>> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>> 
>> 
>> 
>> 
>> 
> 
> 

Social Web Architect
http://bblfish.net/



Received on Monday, 25 March 2013 19:56:45 UTC

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