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

RE: httpRange-14

From: John Black <JohnBlack@deltek.com>
Date: Sat, 2 Aug 2003 14:02:56 -0400
Message-ID: <D3C8F903E7CC024C9DA6D900A60725D9025F341E@DLTKVMX1.ads.deltek.com>
To: Bill de hÓra <dehora@eircom.net>, "Tim Berners-Lee" <timbl@w3.org>
Cc: "Roy T. Fielding" <fielding@apache.org>, "Norman Walsh" <Norman.Walsh@sun.com>, "Public W3C" <www-tag@w3.org>

> -----Original Message-----
> From: Bill de hÓra [mailto:dehora@eircom.net]
> Sent: Saturday, August 02, 2003 7:34 AM
> To: Tim Berners-Lee
> Cc: Roy T. Fielding; Norman Walsh; Public W3C
> Subject: Re: httpRange-14
> Tim Berners-Lee wrote:
> Tim,
> > Sorry, but the semantic web architecture absolutely needs the idea
> > of information resources. The RDF identifier foo#bar is
> > used by dereferencing foo and parsing it a get information.
> Is it? I'm sure there are fragids out there that are being used as 
> just proper names. And when it comes to machine reasoning, that is 
> /all/ they are. The RDF MT explicitly does not care abut URI 
> structure. You can't carry over that implication without going 
> beyond the RDF MT. An RDF machine that did this would be embracing 
> and extending RDF semantics in much the same way cwm does.
> To state, in a machine reasonable way that a URI denotes an 
> information resource rather a non-information resource requires an 
> ontology of resources - URI indexicals are not sufficient.

It requires agreement by a community to share an interpretation that
specifies that is what HTTP-URIs name.

It is true, HTTP-URIs used as names, rather than web retrievers, 
could be used to name anything.  The meaning of names is with the 

But we can agree that HTTP-URIs, when used as names, will name those 
very things that are retrieved by the Web.  This is possible and makes 
a huge difference.  If all (or most) of us agree that HTTP-URIs name 
the things retrieved, then suddenly RDF now has a huge set of things 
to talk about.  Additionally, it makes it possible for any logical 
language (KIF,CG) to talk about those Web things.  HTTP-URIs, along 
with a community with this shared interpretation is *not* necessary -
but is sufficient to create trillions of global, unique, unambiguous 
topics of conversation.  This agreement makes the connection between 
the semantic and functional web realms.  And these are important things 
to have named - as important as the web itself.

It took me a while, but now I think this is the best choice for what 
the community should agree that HTTP-URIs name.  I guess Information
Resources will work, although I think it could be explained better.

Now - how do we name the rest of the resources that one would like to be 
able to talk about with RDF, i.e., people, galaxies, cars and so on. 
Hmm. I'll start studying this idea of fragIds....

> If you are going to mandate a privileged status for URIS with 
> fragids in the semantic web, then before the URI is forwarded to an 
> RDF MT compliant reasoner that URI needs to be annonated with new 
> triples that claims it is an information type resource. So, you 
> /still/ need the resource ontology.
> This automagic must be stated explicitly in the architecture, as 
> being automagic. That's not to say it isn't useful, people hack at 
> URI structures every day to great effect, but as things stand it's 
> beyond RDF and any semantic web MT I've seen.
> And I suspect this opens a Pandora's box of hacks, optimizations, 
> localizations, my-need-is-special, non-portable extensions and 
> presumptions to the semantics that involve frigging with URIs. You 
> name it. This is since I don't see why we'd would stop carving 
> things up at information resources, if that turned out to be useful.
> If so, where this heuristic annotating is done needs to be clearly 
> outlined. Is there a layer for it?
> The more I think about it, the more this seems like a way of 
> avoiding defining a new URI scheme for the semantic web by finessing 
> the opacity axiom.
> Bill de hÓra
Received on Saturday, 2 August 2003 14:02:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:00 UTC