RE: Summary of the QName to URI Mapping Problem

> > >foo:barcat
> > >bar:cat
> > >
> > >Yet, using the standard concatenation mapping, both QNames
> > are mapped to the
> > >same URI:
> > >
> > >http://example.com/foobarcat
> > >
> > >While this URI identifies some resource (by definition), it
> > cannot identify
> > >both of the (distinct!) resources identified by the two QNames
> > >simultaneously.  Hence the mapping is deficient.
> >
> > If they really were distinct, that is. Or, you could take the
> > position that the use of the mapping shows that they couldn't have
> > been distinct.
>
>You could, but I don't think that is a valid position considering
>the global scope intended for the SW.

Well, I see your point, but I think that the SW is going to have to 
face up to the fact that information from several sources is liable 
to produce inconsistencies, and find ways of living with that. One 
thing that we surely cannot do is somehow guarantee that people will 
always agree with one another about everything. And once this 
possibility is allowed, and people are given reasonably expressive 
ways of saying things, they can contradict themselves. Tough, but 
true.

>I.e. when those two different QNames occur in
>totally different serializations from totally different sources
>totally ignorant of each other's use of namespaces, and
>ambiguity is introduced (needlessly) into the knowledge base
>when those sources are syndicated because the resultant URIs
>collide, that's really going to make for a robust and reliable SW.
>
>Eh?

Sure, but that's not going to happen unless those totally different 
sources happen to have almost identical source URIs, ie one of them 
has to be an exact initial substring of the other, and that one has 
to use Qnames which have the other's Qnames as exact final 
substrings, and the relevant missing string from the source URI match 
has to exactly match the missing string from the Qname match. I would 
be willing to bet money that this will not happen by chance anywhere 
on the planet in the next, say, decade. And in any case, the user of 
a Qname presumably knows what prefix is going to get spliced onto it, 
and if they use Qnames which won't survive a translation into and out 
of URIs, then one could take the view that the responsibility is on 
them to use better Qnames.

Like much else in life, there is no *guarantee* that this mechanism 
will not break, though one could do a reasonable estimate of the 
likelihoods, under admittedly artificial assumptions about randomness 
of name generation and so on. But so what? There is no guarantee that 
any given URI isnt going to generate a 404 error, either.

Pat Hayes

---------------------------------------------------------------------
(650)859 6569 w
(650)494 3973 h (until September)
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Thursday, 16 August 2001 18:52:08 UTC