- From: Henry Story <henry.story@bblfish.net>
- Date: Tue, 26 Mar 2013 20:06:32 +0100
- To: Erik Wilde <dret@berkeley.edu>
- Cc: Kingsley Idehen <kidehen@openlinksw.com>, public-ldp@w3.org
- Message-Id: <5F4E2A85-0D8A-4518-AAE6-F33A3AE5258D@bblfish.net>
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 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. ]] 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. Henry > > cheers, > > dret. Social Web Architect http://bblfish.net/
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Tuesday, 26 March 2013 19:07:06 UTC