- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Wed, 29 May 2002 10:11:14 +0300
- To: ext Mark Baker <distobj@acm.org>, Graham Klyne <GK@ninebynine.org>
- CC: www talk <www-talk@w3.org>
On 2002-05-28 23:12, "ext Mark Baker" <distobj@acm.org> wrote: >> It also suggests a possible answer to the question about the web and >> URIs. It is sometimes claimed that to be on the web means to have a >> URI. So are people and cats and dogs and cars "on the web"? > > I am, at http://www.markbaker.ca. No you are not. Sans Star Trek technology where I can beam you over, I can't dereference that URI and get a representation of *you* but only a representation of some web page that may provide information *about* you. But that doesn't mean that you, yourself, are actually "on the web". Abstract or non-digital resources for which a representation cannot be obtained are not "on the web" even if there might be information about them or other referring resources which are "on the web". I think that alot of confusion arises from the term "representation of a resource" where folks think that means any information about that resource rather than a digital realization of the resource itself. A human being can not (at least for now) be "on the web". >> If I clarify >> the definition of "on the web" to not include things that have URI >> references, then the answer to that question can be "no". But using RDF, >> we are still free to talk about these things without actually having to >> claim that they are "on the web", by using URI-references rather than "1st >> class" URIs. > > I think that severely cripples the Web, suggesting it only be used for > those things for which the resource and its representation are the same > thing (my interpretation of TimBL's "document" view). > > The resource/representation dichotomy is at the essence of the > universality of the Web. Not all things can be retrieved over a > network (my dog, for example), but all digital representations of things > can (pictures of my dog). But a picture of your dog is not an HTTP representation of your dog. What you GET in that case is a representation of the picture. Not a representation of your dog. > As GET means "GET me a representation of the > thing identified by the URI", this permits the Web to encompass all > things with identity, not just documents. Such a view introduces ambiguity into the web architecture. We are no longer then able to differentiate between primary resources and secondary descriptions or references to those primary resources. No thanks. If I ask for a resource, I want a representation of *that* resource (i.e. a digital realization of that resource). If all I can get is knowledge *about* that resource, OK, but I want to know that all I am getting is knowledge about the resource and not the resource itself. A picture of your dog is not your dog. A picture of some sexy babe is not the sexy babe (if it were, just think what *that* would do for e-commerce ;-) > I know this opens up that whole cars/hills/documents discussion again, > and I didn't want to go into it. I just wanted to point out how my > view of that issue relates to my view on this issue. Not all of the > URIs-can-identify-anything folks see this the same way though; DanC > thinks that an HTTP URI can identify his car, but he likes fragids. > Go figure. 8-) I see the issues as disjunct. Whether a URIref identifies resources on or off the web is not dependent on whether a fragid has consistent interpretation in all cases where the URI would be dereferenced. The significant point, as I see it, for the SW and RDF use of fragid's is simply that they have consistent interpretation -- whereas for Web use, they need not. This is a specific and distinct difference between the nature/needs of the Web and SW with regards to URIref interpretation. > In the long run, I expect the fact that Web servers (and therefore apps) > don't get the fragment id, will decide this issue. We've already seen > some of this in Dublin Core's use of namespaces, for example, since > they use purl to redirect, but you can't redirect with a fragid. > There's going to be a lot of pain in RDF land when people start > integrating it with HTTP, because of this. I agree that avoiding the use of fragids in URIs to denote resources in RDF will avoid alot of headaches, and I don't use them myself for such reasons. "Fixing" the XML Namespaces spec to disallow URIrefs with fragids would help things alot, IMMHO. Cheers, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com
Received on Wednesday, 29 May 2002 03:07:58 UTC