Re: URI ref comparison - clarification requested

> There is still an aspect of this that makes me a little uneasy, though
> I doubt that it's significant even if my reasoning makes sense. If a
> spec like RDF says it's using URIs but provides its own comparison
> mechanism (such as the first approximation of string equiv), then
> applications built to that spec may systematically, as a group, behave
> differently than apps built directly to the URI spec (possibly
> including support for better approximations). That systematic aspect
> seems a step beyond different apps implementing different variations
> of the original options.
>
> Where the primary practical use of the URI is in the process of
> obtaining a representation of the resource identified,  the
> comparisons only (potentially) producing false negatives seem to
> preclude problems. I suspect it might not be such a failsafe in the
> general case when is used in constructing logical statements (though I
> might well be mistaken, IANAL).

I am kind of curious how a system constructing logical statements
could somehow fail in a non-safe way just because two equivalent URI
are considered different.  I think, at most, it just adds one to the
number of aliases, and thus the admonishment against creating
arbitrary aliases for a resource still applies.  If the RDF graph
contains conflicting assertions for two equivalent URIs, then those
assertions are broken regardless of the comparison algorithm; that
brokenness is simply made harder to discover due to the lax method
of comparing URIs -- merely declaring the URIs to be different
does not cause the assertions to be true.

However, it is important to note that the reason RDF specifies
it that way is because the probability of encountering two
equivalent but not string-equal URIs in the same RDF graph is
quite small, and easily avoided by use of canonical URI forms.

....Roy

Received on Friday, 27 August 2004 22:30:06 UTC