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

Re: TAG request: establish the relationship between URIs and Resources is many to many

From: Jonathan Borden <jonathan@openhealth.org>
Date: Sat, 25 Jan 2003 10:31:19 -0500
Message-ID: <001e01c2c486$cf68d150$7c01a8c0@ne.mediaone.net>
To: Bill de hÓra <dehora@eircom.net>, "Tim Bray" <tbray@textuality.com>
Cc: <www-tag@w3.org>

Bill de hÓra wrote:

> Tim Bray wrote:
> > How about a slight recasting of that:
> >
> > 1. Different URIs can identify the same resource, in the opinion of the
> > creators and users of that resource.
> > 2. The Web is designed on the principle that a single URI identifies a
> > single resource which does not change.  In practice, this principle is
> > someties violated (insert list of nasty examples), and software must
> > often deal with the consequences, but such inconsistency is always
> > damaging and SHOULD be avoided.  -Tim

See my prior message on why the URI:resource relationship is many:1.

> Clearer, thanks. But abuse of this principle also affects
> specifications such as RDF, as well as web software. For example it
> will mean we have to merge RDF graphs with great caution before
> inferences can be made and we have to be careful about RDF queries
> that span multiple graphs.
> If the rdf-wg were happy to add words to the primer about how
> breaking this principle interplays with the function that determines
> the denotation of a URI, that would help greatly. That is, when
> merging two RDF graphs, be aware that a URI  used in graph 1 might
> not have the same denotation as it does in graph 2.

That is an issue for RDF. The RDF Semantics document goes to length to
describe the fact that time-varying changes in resources are not dealt with
in this version of RDF. Algorithsms to merge graphs will generally assume
that when you use a URI in two places you mean the same thing in both
places. (places can be spatially and temporally separated).

Received on Saturday, 25 January 2003 10:53:36 UTC

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