Choosing and comparing URIs

a presentation on tag issue URIEquivalence-15 (and irieverywhere?)

Dan Connolly, Feb 2002

Take-home points

If you mean the same thing...

...refer to it the same way

Providers: choose clearly distinct names for distinct things

Comparison Relationships

Premise: compare u1 and u2, and use the result as information about what they identify, i.e. r1 and r2.

false negative: If r1 = r2 but not R(u1, u2) we say R gives some false negatives.

false positive: If R(u1, u2) but r1 != r2, we say R gives some false positives.

Partial Knowledge is the norm

false negatives are a normal consequence of the ordinary situation where local knowledge is incomplete

Absolute URIs* are the basis of comparison

Axiom: u1 = u2 => r1 = r2.

for absolute URIs (optionally with fragids) u1 and u2, where u1 = u2 is strcmp(b1, b2) where b1 is the US-ASCII encoding of u1 and b2 likewise for u2.

For IRIs, analagously: ecmascript/java/C# string compare[@@double-check] [@@what is this called in the charmod spec?].

Absolute URIs* are the basis of comparison (2)

Providers: consider using relative references: In http://example/abc , abbreviate http://example/def by a relative URI reference, "def".

Absolute URIs* are the basis of comparison (3)

** or at least act like you did.

Information hiding: Clients should not usurp server's naming rights

*or at least: indistinguishable

Well-known pathnames are counter to information-hiding

layered conventions reveal information