W3C home > Mailing lists > Public > public-ldp@w3.org > March 2013

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

From: Henry Story <henry.story@bblfish.net>
Date: Tue, 26 Mar 2013 20:06:32 +0100
Cc: Kingsley Idehen <kidehen@openlinksw.com>, public-ldp@w3.org
Message-Id: <5F4E2A85-0D8A-4518-AAE6-F33A3AE5258D@bblfish.net>
To: Erik Wilde <dret@berkeley.edu>

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.

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/>. If you want you can create a vocabulary item that makes
this even more explicit, but you don't really need it. <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.
Now the URI spec says that the meaning of URIs with a # are given by the URI without the

   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. 

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.

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. I think of mysefl as a RESTafarian and a Pragmatist, so
clearly there is no consensus in that community. 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.


> cheers,
> dret.

Social Web Architect

Received on Tuesday, 26 March 2013 19:07:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:03:10 UTC