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

On 3/26/13 10:16 AM, Henry Story wrote:
> On 26 Mar 2013, at 14:45, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>
>> 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?
> The mime type of the HTTP header is a way to specify to the interpreter how to interpret the bytes along the wire. It is not a statement about the links being or not being followable.
>
> You can publish html with all the links broken, and that will still be correct html. Pages that publish information pointing to broken links are just a lot less interesting and useful to use, and people tend not to link to such pages. Just as a road is still a road even if in a dangerous neighborhood.

Yes, but the browser will still render the HTML page with broken links 
if it's served as text/html. It might not do so if it's served as 
text/plain.

>
> The mime type would be too general a place to indicate such a thing. Are we going to need a mime type if only half the links are followable, and another one if 99% of the links are?

No, the media type simply does for RDF based Linked Data what it already 
does for HTML based Linked Documents. It just formalizes the 
content-type in a manner that broadens the audience of users and 
developers that ultimately understand this most powerful, but terribly 
confusing, aspect of the Web.
>
> Anyway the point is moot. As Richard just pointed out  The spec defining RDF graphs says, when explaining what the IRIs in an RDF graph mean  ( http://www.w3.org/TR/rdf11-concepts/#referents )
>
> [[
> Perhaps the most important characterisitic of IRIs in web architecture is that they can be dereferenced, and hence serve as starting points for interactions with a remote server. This specification, however, is not concerned with such interactions. It does not define an interaction model.
> ]]

*this specification, however, is not concerned with such interactions, 
It does not define an interaction model*

RDF based Linked Data is about an interaction model. That's the problem.


>
> Furthermore if a document wants to indicate that an resource is an LDPC it need just write
>
>     <http://remote.resource.com/something/> a ldp:Container .
>
> and the work is done.

How can that be without inference?

>   Now you can be a lot more fine grained in your description of resources than
> you could ever do by playing with mime types.

I don't see how without inference, RDF model commitment & comprehension, 
and a best practice (as opposed to formally specified) based interaction 
model.

Kingsley

>   
>
>>> 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.
> This Turtle document is your friend here:  http://www.w3.org/TR/turtle/
> [[
> This document defines a textual syntax for RDF called Turtle that allows an RDF graph to be completely written in a compact and natural text form, with abbreviations for common usage patterns and datatypes.
> ]]
>
> What we were discussing with Andy is what the Base of a Turtle document should be when it is POSTed to
> a LDPC. The choice of having the created resource be the base is compatible with HTTP and Turtle, and
> the turtle mime type. It is something that only LDP can decide on, since we are defining what an LDPC
> is and how it functions.
>
>>>   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.
> I doubt anyone outside the RDF community will care at all about this. They'll use text/turtle without any problems.
>
>> 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.
> These are old debates from the beginning of RDF. The linked data community has made them obsolte by now,
> as shown by the recent revisions to the RDF1.1 concepts. It is easy to explain how this came about - though
> this is not the topic of this thread: from the logical point of view these pragmatic issues were out of
> scope. If one falsely believes that logic is all there is in communication, then one can come to the conclusion
> that pragmatics being out of scope of logic it does not exist. But that is just a mistake. One thankfully
> that is now widely understood to be one.  Let's move on.
>
>> 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
>>
>>
>>
>>
>>
> 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