Re: "On the Web" vs "On the Semantic Web" (was Re: resources and URIs)

----- Original Message -----
From: "pat hayes" <phayes@ihmc.us>
To: "Tim Bray" <tbray@textuality.com>
Cc: "Michael Mealling" <michael@neonym.net>; <www-tag@w3.org>
Sent: Monday, July 21, 2003 1:04 PM
Subject: Re: "On the Web" vs "On the Semantic Web" (was Re: resources and
URIs)


>
> >pat hayes wrote:
> >
> >>PS.  Reading things like this makes me wonder whether you guys
> >>inhabit the same planet as the rest of us. Things with hearts and
> >>multiple interfaces, arranged in layers...?? What the hell are you
> >>talking about??? Here I am looking out of my window at an oak tree
> >>and I wonder if its a resource, and what its interfaces could be,
> >>and what layer it would be in....
> >
> >If someone publishes an URI for it
>
> How could anyone tell whether a URI was 'for' an oak tree? You said
> it yourself:
>
> [PH] Am I identified by a URI? How could anyone possibly tell?
>
> [TB] You're right; the current web architecture provides no way to
> test this condition.
>
> >and, even better, provides representations (and even, better the
> >representations include audio and video and photos), then yes, that
> >oak tree is on the Web as far as I, or any software I write, can
> >tell.
>
> I doubt if you or anyone else could write software that could tell
> whether an oak tree was or was not connected with the Web in any way
> at all. At the very least, you would need to have a very advanced
> piece of visual recognition software; to get a particular tree you
> would need to have it incorporated into something that knew where it
> was and where it was looking at. You need something like a webcam
> linked to a GPS and a compass running an AI vision system that knew a
> lot about botany.
>
> But look, aside from this, your answer makes being 'on the Web'
> meaningless. Its not an architectural condition, obviously. It does
> not correspond to 'having a URI' since the URI could identify an
> image of the tree just as well as the tree itself; and in fact if the
> URI starts 'http:' and ends with a fragID then it is required to
> indicate an anchored place in an HTML document, not the thing
> 'denoted' - if there is a single such thing, which is extremely
> doubtful - by the picture or text found at that anchored location.
> What if the anchored location is a piece of text which describes an
> entire situation involving lots of entities? Which of them is THE
> resource that the URI is supposed to indicate? What if it is a
> picture of three trees? A drawing of Yggdrasil?

You are caught in the resource/representation bug. What you get when
resolving a HTTP URI with a fragid _might be_ an HTML document. It is the
responsability of the client to use the fragid to look inside the HTML
_representation_ to find an anchored piece of the HTML document. This is all
the _representation_ not the resource. Indeed the same HTTP URI with fragid,
might be resolved with Accept: appliction/rdf+xml in which case your same
fragid identifies an RDF description (i.e. rdf:ID="frag"), now what? You
still don't have the actual resource, rather an RDF/XML representation.

If we _were to_ properly integrate the SW with the current Web, we _might
say_ that when an RDF/XML representation is returned, it ?is a full fidelity
representation of the actual resource? Nope that doesn't work, so how ought
this work? What ought the connection be between a piece of so-located
RDF/XML and the resource it describes? The current SW specs i.e. RDF, don't
address this issue _except_ that OWL does define what happens when an
<owl:import>s URI is dereferenced (which is why owl:imports is somewhat
controversial). This seems to be a huge hole in the SW that needs fillin' --
not the current Web's problem though.

Jonathan

Received on Monday, 21 July 2003 13:26:35 UTC