Re: Draft revised text for 2.2 on ambiguity/indirect identification


Comments in-line ...

On Sat, Nov 15, 2003 at 02:45:36PM -0800, Tim Bray wrote:
> 1. URI Ambiguity
> In Web Architecture, URIs identify resources.  They are also useful in 
> other roles, but this should not normally lead to ambiguity in the 
> identification function.  Consider the following scenario: a 
> software-development group building a database of information about 
> companies might choose to use the URI of each company's Web site as a 
> unique lookup key, since URIs have useful properties of uniqueness, 
> longevity, and moderate length.  In this application, the Web site URI 
> is being used indirectly to identify the company.

What if the company claims that "" identifies the
company, not its "Web site"?  Maybe it's the "Web site" that's
indirectly identified? 8-)

>  The same 
> software-development group might build a another database of web pages, 
> very likely indexed by URI.  However, this does not mean that the 
> company has become its Web site, that some Web-page record is actually 
> a company, that the fields of the two databases would be consistent, or 
> that the URIs would necessarily be useful as a basis for merging.
> Similarly, people can be identified by their email addresses.  When 
> conference organizers ask attendees to register by giving their email 
> addresses, both parties know that they are using the mailbox identifier 
> indirectly to identify the person.  The resource identified by the URI 
> "" is still a mailbox, not a person.

Was httpRange-14 resolved and nobody informed me? 8-)

I agree with the point being made about ambiguity, but I think it can be
done without choosing sides in httpRange-14, simply by not referring to
what the URIs used by those two apps "actually" identify.  As for some
text, I'd recommend simply dropping both the second paragraph of Tim's
text, as well as the sentence in the first paragraph that I commented on

I also wonder if some mention of rdfURIMeaning-39 isn't appropriate
in this section?


Mark Baker.   Ottawa, Ontario, CANADA.

Received on Monday, 17 November 2003 23:02:43 UTC