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

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].

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

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.


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

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

>
> 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. 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 :-)

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. Do we split 
the baby or keep it alive?
>
> 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