- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Tue, 6 Apr 2004 13:37:05 -0700
- To: Pat Hayes <phayes@ihmc.us>
- Cc: Tim Bray <tbray@textuality.com>, Jeremy Carroll <jjc@hplb.hpl.hp.com>, Graham Klyne <gk@ninebynine.org>, uri@w3.org
> If I am following this discussion, we seem to be in violent agreement. > Graham and Jeremy and I are concerned that URIref normalization may > introduce name equivalences where RDF is expecting distinct names. > This would be very damaging, a potential disaster: a large part of the > expected functionality of RDF and especially OWL is in determining > that two names refer to one entity, and unpredictable normalization > will wreck this kind of reasoning. Then define an RDF/OWL axiom that says any two equivalent URI must refer to the same resource. That is what I believe is already true. I expect those technologies to handle it correctly, fail safely in the presence of false negatives, or be fixed. I don't know about Owl, but RDF simply defines string equivalence as sufficient because the cost of dealing with bifurcated graphs, when someone does produce inconsistent URIs, is considered less than the cost of normalizing every reference. The RDF doesn't become false; it is merely less well-connected than it might be. To reduce the problem, we recommend consistently providing URI references in their canonical form. That is why the specification does not require normalization to occur -- it is simply an option for applications that do wish to reduce false negatives. > But that sounds like a 'false positive' (?), so it seems that we are > all in agreement that it is important to avoid this situation, ie one > where an application is expecting that two URI references are > distinct, but a URI normalization process is licenced to convert one > of them into the other 'silently', without giving notice. The application is in control of the normalization process. In any case, a reasoning system that depends on two equivalent URI pointing to different resources is already broken. ....Roy
Received on Tuesday, 6 April 2004 16:37:10 UTC