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

On 26 Mar 2013, at 20:55, Kingsley Idehen <kidehen@openlinksw.com> wrote:

> On 3/26/13 3:06 PM, Henry Story wrote:
>> On 26 Mar 2013, at 19:40, Erik Wilde <dret@berkeley.edu> wrote:
>> 
>>> hello henry.
>>> 
>>> On 2013-03-26 10:03 , Henry Story wrote:
>>>> On 26 Mar 2013, at 17:25, Erik Wilde <dret@berkeley.edu> wrote:
>>>>> some may be dereferencable, but you don't know which, and you don't know the service semantics of doing so.
>>>> That is not anymore the status quo in RDF land. 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 )
>>> i am really wondering what makes you think that the status quo of RDF being an URI-centric data model has changed in any way. quoting from the section you linked to:
>>> 
>>> "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. It only treats IRIs as globally unique identifiers in a graph data model that describes resources."
>>> 
>>> some IRIs can be dereferenced, others not (RDF allows you to use any URI scheme you like). how to dereference IRIs (i.e., how to behave when actually engaging in hypermedia interactions) is out of scope of RDF, as the spec itself says. how much more clear could the spec be?
>> The intent is clear that URIs can be dereferenced to fetch new information.
> 
> That isn't precise enough re. RDF based Linked Data. The information in question takes the form of a machine comprehensible description of what a given Linked Data URI denotes (i.e., the URI's referent) delivered by RDF model based content, accessible from a document location denoted by a URL [1][2].

Just read the next sentence I wrote:
> 
>> 
>> Furthermore even if this leaves something unspecified ( as it happens  the part
>> that this working group is  working on filling it as ) this does nothing to support your
>> theories about special mime types being required for Linked Data.
>> 
>> RDF is a resource description framework. So if I describe a resource such as
>> 
>> (1) <http://w3.org/> a foaf:Document .
>> 
>> Then it follows quite clearly that I am saying that one can dereference the resource
>> that is <http://w3.org/>.
> 
> It doesn't.
> 
> You know that because of your understanding of the semantics. That doesn't mean said semantics are fully discernible from the content of an RDF document.

Let's replace foaf:Document with ldp:Container, so that we stick to just the topcis 
of the LDP specification.

I am assuming ( as we should on the LDP mailing list ) that an LDP agent knows
 
1) the RDF semantics http://www.w3.org/TR/rdf-mt/
2) know the Interpretation of the rdf:type relation 
3) the interpretation of foaf:Document 

Then knowing that and receiving information it trusted that

  <http://ldp.w3.org/> a ldp:Container .

it would know quite a lot more about <http://ldp.w3.org/> than it knew before. 
IT would know that certain types of interaction patterns with that resource 
were available, namely those described by the ldp spec. Since those interaction
patterns mention PUT, POST, DELETE, etc... this gives an agent that believes this enough information 
to continue. 

The referent furthermore of <http://ldp.w3.org/> is given by the URI spec, and one of the aspects
of this is that the http component of the URI indicates that representations of that referent are
to be found by HTTP interactions as specified by the HTTP spec.

So that should help show how it follows that one can dereference the resource. One may not
succeed - because it may be access controlled, the server may be down, etc... but that is 
a different issue.

> 
> A problem arises when a user agent starts with a chunk of RDF model based content. The user agent developer could lookup  the current RDF specs in an attempt to figure out what kind of interaction behavior to deliver re.,  URIs in the RDF content that denote entities and relations, but will sadly end up with nothing.  Then they could stumble across TimBL's meme and eventually figure out that they could implement a "best practice" for RDF content exploration using the follow-your-nose pattern via URI de-reference, on the assumption that each URI de-reference resolves to a description of said URIs referent.
> 
>>  If you want you can create a vocabulary item that makes
>> this even more explicit, but you don't really need it.
> 
> A vocabulary referenced from the text/turtle media type definition could suffice. I even believe it exists [1][2].
> 
>>  <http://w3.org/> is an internet
>> resource, which is being described. So if you believe statement (1), you just come
>> to the conclusion that you can dereference it.
>> 
>> If you now find a graph that you believe that says
>> 
>>  <http://bblfish.net/people/henry/card#me> a foaf:Person .
>> 
>> then you know that I am a foaf:Person, ie a person, as described by the foaf ontology.
> 
> I know (courtesy of my RDF model theory belief system and Turtle syntax notation parsing) that the entity denoted by the URI <http://bblfish.net/people/henry/card#me>is an entity of type foaf:Person. That's it.

yes. I was referring to me de re, not de dicto ( but it was phrased ambiguously )

> 
> 
>> Now the URI spec says that the meaning of URIs with a # are given by the URI without the
>> fragment.
>> 
>> http://tools.ietf.org/html/rfc3986#section-3.5
>> [[
>>    The semantics of a fragment identifier are defined by the set of
>>    representations that might result from a retrieval action on the
>>    primary resource.  The fragment's format and resolution is therefore
>>    dependent on the media type [RFC2046] of a potentially retrieved
>>    representation, even though such a retrieval is only performed if the
>>    URI is dereferenced.
>> ]]
> 
> The meaning of a fragment identifier doesn't triangulate to its sense. You need more information conveyed by the content and the model that constrains the content.

you need more information, but the minimum is given here: you need to look for the document without
the hash to get its meaning. More information after that is goodness, but the above 
is all that is needed to make the point that we are discussing here: namely that the
the meaning is given by a representation returned by that URI. 

> 
> I know what you are saying, but from an objective perspective, you are taking leaps of faith re. the pursuit of truth.

This is not a leap of faith. This is the RFC for URIs.

> 
>> 
>> So this is saying that if you can you should do a retrieval action on
>> <http://bblfish.net/people/henry/card> to get the meaning of the hash uri.
> 
> It doesn't say or imply that at all, from an honest objective view point.

It says so very cleary:

  "The semantics of a fragment identifier are defined by the set of
   representations that might result from a retrieval action on the
   primary resource"


> Of course, you can conclude that because your RDF model theory knowledge introduces a subtle bias that manifests as an intuition which doesn't actually map to an existing spec. What it does map to is TimBL's RDF based Linked Data meme :-)

RDF model theory is what the Turtle spec refers to.

> 
> If we tweak the definition of text/turtle or resurrect and reapply application/x-turtle we can turn TimBL's RDF based Linked Data meme into a spec. Then we no longer have these "leaps of faith" or "best practices" that sort of paper over a subtle procedural omission.
> 
>> 
>> All of this is soo deeply embedded in the core of the core specs of the
>> Web  that really the tables are turned on you to do find something to
>> make your point other than vague gestures to what some people you name
>> the REST community say when sitting around a table, or what you understood
>> them to be saying.
> 
> Erik should certainly at least provide a URL to a media type definition that demonstrates and outlines what he seeks. That's a fair request, one I made earlier also. I've even added a reference to the HTML mime type definition below [2].
> 
>>  I think of mysefl as a RESTafarian and a Pragmatist, so
>> clearly there is no consensus in that community.
> 
> Do you puff HATEOAS though?  LOL .
> 
>>  To get further we need
>> to refer to widely adopted specs. I don't think you can get any more solid
>> that the URI specs. So why not move on to other issues, and lets finish
>> the spec. There are quite a few more issues of bigger import to be resolved.
> 
> This is a "deceptively hard" problem to solve, it now seems.

An it has been solved over the past 10 years by the RDF community in a number
of specifications.

> Do we split the baby or keep it alive?

We keep it alive. text/turtle is all we need.

Ok, that's enough for me on this topic for now. If there is a serious proposal,
put it forward and it can be put to a vote. I think we are going in circles now.


>> 
>> Henry
> 
> Links:
> 
> 1. http://www.w3.org/2000/10/swap/log.n3 -- Semantic Web Logic
> 2. http://bit.ly/Xajq65 -- Linked Data browser view for easier reading and exploration .
> 
> 
> Kingsley
>> 
>> 
>>> cheers,
>>> 
>>> dret.
>> 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/