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

On 3/26/13 9:23 AM, Henry Story wrote:
> On 26 Mar 2013, at 13:43, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>
>> On 3/26/13 5:41 AM, Henry Story wrote:
>>>> True, but if it's just a parameter on the media type then we can mostly just ignore it…
>>> I don't think we're here to create standards that we will ignore in order
>>> to help some people overcome problems that they only thought existed.
>>>
>> Bearing in mind that we do have a problem re. RDF and RDF based Linked Data conflation that's hidden via best practices adopted by RDF based Linked Data tools implementers. What would you suggest as a solution? We have to solve this problem.
> There is no problem here. Linked Data is the way RDF is meant to be published.

I don't think that's accurate.

Linked Data is something that RDF enables you produce. Basically, you 
end up with RDF based Linked Data that scales all the way up to the 
World Wide Web.

>   If you link to a document
> that has links that don't resolve it is a dead document: avoid it.

Yes, but why does HTML work re. HTML based Linked Documents that scale 
to the World Wide Web? Does it work just because of the existence of 
URLs or because media type "text/html" has clearly defined semantics 
that cover the expected behavior of links?

> Just as one should not link to web
> pages whose links are all broken or that are lying ( other than with a rel=nofollow link )
>
>> I believe Erik's "text/plain" and "text/html" analogy frames the problem nicely. For instance, look back to the thread between yourself and Andy about relative URIs and RDF graphs [1][2]. We have a single media type serving two distinct functions i.e., graph expression (relative URIs are fine here) and actual graph serialization (relative URIs aren't acceptable here).
> We don't. relative URIs are part of the turtle standard.

Yes, but is Turtle a Syntax Notation or a Serialization Format or both? 
Your debate with Andy demonstrates the kind of problems that dog RDF, 
endlessly. Yourself and Andy are way too experienced in this realm to 
differ so profoundly on interpretation.

>   We are just specifying clearly
> how these relative uris are meant to be interpreted in a POST. There is an issue open for
> improving the spec text on this, but there is no need for a new media type, and it would
> make no sense to invent one for this purpose. It would be shot down for sure during review.

I don't think it will, once everyone steps back, takes a deep breadth, 
and then look at the problem from the view point of someone outside the 
RDF community.

There is nothing about "text/turtle" that implies adherence or 
interpretation of the rules outlined in TimBL's Linked Data meme. Not a 
single thing, and that's the crux of the matter. TimBL outlined how to 
use a specific media type to produce Linked Data based on the RDF model. 
What he didn't do is take the additional step of triggering registration 
of a new media type or making an update to existing media types 
associated with RDF.

Why should a Web browser render HTML content delivered from a server as 
content-type: text/plain ?
Why should a Linked Data browser render (produce a follow-your-nose 
friendly graph presentation) Turtle content delivered from a server as 
content-type: text/turtle ? We do it because we adopt an RDF based 
Linked Data community best practice, not because of any semantics in the 
media type specification for text/turtle or any other media type 
associated with RDF.

Also note, many of us have products that already cater for "text/turtle" 
and "application/x-turtle" in response to the original Turtle submission 
[1]. We are all still alive, the Semantic Web vision intact, and general 
Linked Data publication and consumption hasn't missed a beat :-)

Links:

1. http://www.w3.org/TeamSubmission/turtle/#sec-mime -- Turtle media 
types .


Kingsley
>
>> Links:
>>
>> 1. http://lists.w3.org/Archives/Public/public-ldp-wg/2012Oct/0132.html -- sample post from relative URIs and RDF graphs thread .
>> 2. http://lists.w3.org/Archives/Public/public-ldp-wg/2013Mar/0095.html -- ditto  .
>>
>> -- 
>>
>> 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/
>


-- 

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