W3C home > Mailing lists > Public > www-talk@w3.org > May to June 2002

Re: [rdfmsQnameUriMapping-6] Algorithm for creating a URI from a QName in RDF Model?

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>
Message-ID: <B91A59C2.15990%patrick.stickler@nokia.com>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 October 2010 18:14:27 GMT