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

On 3/25/13 3:54 PM, Richard Cyganiak 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?

This really depends on if the LDP client understands RDF. You see, even 
your question can't (at this point) generate a clear answer from an LDP 
perspective.

A Linked Data client would at the very least understand that it was 
working with an entity relationship graph where each component of the 
graph is denoted using a de-referencable URI. Subject to reasoning 
capability, the aforementioned client would draw further inference from 
the vocabularies that constrain said graph.

>
> 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?

Subject to the capabilities of the LDP server, more than likely a 406.

A Linked Data server will typically handle content negotiation or simply 
return 406.
>
> 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.

Good point!

I am not trying to do that, as per my initial comments [1] about this 
matter. I am pushing a compromise scenario where RDF-Linked-Data-Heavy 
tools that already know what to do with text/turtle just continue as is 
i.e., they already *implicitly* treat text/turtle as an RDF based Linked 
Data media type anyway. Developers of these tools (ourselves included) 
can handle another media type that for all intents and purposes receives 
the very same treatment we currently give to text/turtle.

My concern is more to do with those who seek to be much more specific 
about media types and associated link semantics. There is a good case to 
be made for an IANA media type for RDF based Linked Data. Personally, I 
strongly believe that TimBL's Linked Data meme [2] should have been used 
as the basis for creating this critically missing media type.

As is always the case with this RDF, Linked Data, and Semantic Web 
journey, we need to call on the wisdom of Solomon. Thus, I would rather 
accept a new RDF based Linked Data media type than sit back and let the 
conflation driven confusion of yore persist, detrimentally.
>
> 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.

Yes-ish, but isn't that how things are today -- even amongst those that 
are heavy RDF and RDF based Linked Data true believers?
>
> I don't see how anybody wins in this scenario.

Wisdom of Solomon is the only way out, so anything to save the life of 
the baby will do :-)

Methinks, existing implementers of RDF based Linked Data solutions 
(relatively few in the grand scheme of things) are best positioned to 
compromise in this particular scenario.

Links:

1. http://lists.w3.org/Archives/Public/public-ldp/2013Mar/0036.html -- 
outlining the expected behavior for RESTafari and RDF heavy types.
2. http://www.w3.org/DesignIssues/LinkedData.html -- TimBL's Linked Data 
meme.
>
> Best,
> Richard

Kingsley
>
>
>
>
>> 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
>>
>>
>>
>>
>>
>
>


-- 

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