W3C home > Mailing lists > Public > www-tag@w3.org > February 2003

Re: Valid representations, canonical representations, and what the SW needs from the Web...

From: Paul Prescod <paul@prescod.net>
Date: Mon, 03 Feb 2003 13:55:33 -0800
Message-ID: <3E3EE555.5010605@prescod.net>
To: Sandro Hawke <sandro@w3.org>, www-tag@w3.org

Sandro Hawke wrote:
> In this view, the use of URIs (esp http URIs) in RDF buys us almost
> nothing but confusion.  At best, it makes looking up some
> documentation for a term a little easier.  

Do you consider the RDF schema for a term to be just documentation? I 
was under the impression that it was a very valuable bit of metadata 
that could be used in extremely powerful ways by RDF processors.

> ... Really, though, UUIDs or
> tag: strings would be vastly less confusing and work about as well.

How would I dereference UUIDs to get what I want? Tag identifiers can be 
viewed as just a bit of extra syntax around HTTP URIs so of course they 
are no less powerful. ;)

> Google or a few well-run directory services would provide
> documentation links, and could actually lead to better updated &
> maintained documentation after the term-coiner has lost interest (and
> his domain name :-)

Sure, we could depend on registry services if we want the Semantic Web 
to be a centralized rather than decentralized system. Personally, I 
think that that would be to misunderstand the very strength of the Web.

  * http://www.oreillynet.com/lpt/wlg/1680

As far as Google: Google's business model is advertising. This is not 
portable to the semantic web. Is the W3C volunteering to be the Verisign 
of the Semantic Web world? Are you going to be the Esther Dyson of the 
Smenatic Web? ;)

> There's an alternative view, however.  Maybe http: URIs are already
> rather precise.  Each one identifies exactly one web location [1].
> They can't be used directly to identify the Sun, etc, only indirectly
> via their content (or using fragment IDs, in one version); that
> indirect location works just fine for RDF and the semantic web,

It won't work. You can't know whether "http://www.prescod.net" refers to 
"Paul's homepage", "The Prescod Family Homepage", "Paul's business", "A 
set of links endorsed by Paul" etc. unless I tell you. There is nothing 
in either the URI string nor the document to umabiguously say what that 
page is about. I can only give it clear, semantic-web processable 
meaning with RDF. And doing so requires me to make a new URI. So why not 
use that new URI to represent me?

 > letting us bootrap off the existing billions of pages instead of
 > waiting for new ones.

Those billions of pages are not semantic-web processable or we wouldn't 
be arguing about how to build the semantic web. They are the things 
talked ABOUT by the semantic web, not the nodes in the web. Because the 
are 100% semantically ambiguous I would say that they are totally 
valueless as part of the web. Plus, not that URIs are not expensive. 
They are cheap. Making new ones is easy. We need to make new ones to 
have a home for the RDF data anyhow. So what.

> In other words, there are some existing mappings from URI strings to
> things of interest.  Some of these mappings are already out there and
> working quite well.  Why not use them?

Because they are way too semantically ambiguous for machine processing. 
We've spent weeks arguing about whether they are pages or concepts. Once 
you decide that they are pages ABOUT concepts (which I believe is your 
solution) now we can argue about each and every one to figure out WHAT 
concept it is about. Is [1]  a web page, a corporation, a kind of car, a 
family of cars, a family of car companies??? Only the owner of the URI 
can answer the question. They can only answer it in a 
machine-processable way with a machine-processable syntax like RDF. So 
why not put up an RDF document that answers the question? And heck, why 
not use that RDFs URI to represent the "thing".

[1] http://www.ford.com/en/default.htm

  Paul Prescod
Received on Monday, 3 February 2003 16:55:58 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:36 UTC