Re: Using two URIs for the same thing

On Thu, 2003-10-16 at 15:16, Sandro Hawke wrote:
[...]
> We have four URIs:
[...]
> This seems reasonable, doesn't it?

I think so, but after just a quick read, I'm not sure if you
should have worked harder to not make up a new URI...

>   Two names for the same thing; when
> you follow them you get information about the thing; you get different
> information when you follow different names.  For some applications
> you'll use the first name, for others the second.  There are other
> people building test-results browsers; they should have access to the
> same data.
> 
> Useful, practical, easy to do, and...  seemingly contrary to TAG
> advice.  The current WebArch document says, "If a URI has been
> assigned to a resource, Web agents SHOULD refer to the resource using
> the same URI, character for character."  [2]
> 
> So where is the breakdown here?

I'm not sure there is one.

> Is this just the normal RFC 2119 escape from a "SHOULD": "there may
> exist valid reasons in particular circumstances to ignore a particular
> item, but the full implications must be understood and carefully
> weighed before choosing a different course."   If so, I wish the
> document would spell this out better, saying what some reasonable
> exceptions might be.

Isn't it clear enough? By introducing a synonym, you've introduced
a cost on anybody who wants to realize that the two terms refer
to the same thing (along with various risks that they'll eventually
diverge, etc.)

This text seems clear enough to me; what are we missing?

[[[
To help parties know when they are referring to the same resource, it
follows that URI producers should be conservative about the number of
different URIs they produce for the same resource.

Thus, the parties responsible for weather.example.com should not use
both "http://weather.example.com/Oaxaca" and
"http://weather.example.com/oaxaca" to refer to the same resource;
agents will not detect the equivalence relationship by following
specifications.

There may be other ways to establish that two parties are identifying
the same resource that are not based on string comparison; see the
section on future directions for determining that two URIs identify the
same resource.

[...]

2.8.2. Determination that Two URIs Identify the Same Resource

Emerging Semantic Web technologies, including "DAML+OIL" [DAMLOIL] and
"Web Ontology Language (OWL)" [OWL10], define RDF properties such as
equivalentTo and FunctionalProperty to state — or at least claim —
formally that two URIs identify the same resource.

]]]

> It seems to me a lot like having two web pages about the same topic.

It's not clear to me that the two pages should use different
names for the thing. (like I said, quick read...)

> Surely that's not something Web Arch wants to warn against.  

No?

Web Arch is giving advice that's pretty widely agreed
in data management, no? http://c2.com/cgi/wiki?OnceAndOnlyOnce

No, things won't halt and catch fire if you make copies,
but making copies does introduce risks of divergence, etc.
And synonyms are sort of a pain to deal with.

> Maybe this is just a natural outgrowth of using URIs simultaneously as
> (1) logical constant symbols naming objects in some domain of
> discourse and (2) network addresses naming virtual end-points for
> communication.  Since we're using them in two ways at the same time,
> they can be equivalent in one way, while being completely different in
> another.   

That too... as I say: once you make two names, you introduce risks
that their meanings may diverge.

>      -- sandro
> 
> 
> 
> [1] Actually, I want to use 303-See-Other redirection instead of a
>     fragment URI, so I can merge in the human-readable view as well,
>     but that's orthogonal, so I'll pretend otherwise for now.
> [2] http://www.w3.org/TR/2003/WD-webarch-20031001/#identifiers-comparison
-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Saturday, 18 October 2003 11:25:13 UTC