W3C home > Mailing lists > Public > www-rdf-logic@w3.org > August 2001

RE: Summary of the QName to URI Mapping Problem

From: pat hayes <phayes@ai.uwf.edu>
Date: Tue, 28 Aug 2001 17:06:29 -0700
Message-Id: <v0421010eb7b1dcec0cab@[]>
To: Patrick.Stickler@nokia.com
Cc: www-rdf-logic@w3.org
> > >But you may not have the luxury of choosing your namespace. Whatever
> > >method is used must not discriminate against any URI scheme in
> > >any way.
> >
> > But havnt you just pointed out that that is impossible? So what do
> > you propose we do?
>No, I haven't. Please re-read my arguments again. I claim that
>it is impossible to define a function based on the namespace URI
>that fuses the name and namespace into a single URI -- not that
>there is no way to define a function that maps between a QName
>and a URI. There is -- so long as that mapping does not utilize
>the namespace URI as a basis for fusion with the name into a new
>URI which is of the same scheme as the namespace URI. That works
>for some URI schemes but not for any arbitrary (possibly uninvented)
>See my posting from today on the www-rdf-interest group:
>for an alternative approach to my other proposal.

OK< thanks, I did. But I fail to follow your point. You object to the 
use of the character '#' to divide URIs into parts, but you seem to 
be suggesting as a solution to the problem, to use the character ':' 
instead. If your proposal amounts to more than this, or if I have 
mis-stated it, I'd be grateful for an explanation. Why don't the very 
same objections that you raise to the RDF proposal apply, with minor 
variations, to your proposal?

>[so that makes at least two possible solutions to achive that mapping]
> > Maybe I'm missing something here, but you seem to be assuming that
> > there is masses of information out there for the SW to use,
>I think that this is a rather widely held assumption and expectation,
>and I understand Tim's statements to indicate that he too makes that
>assumption (though he is most certainly welcome to correct me if I
>have misunderstood him).
> > all
> > written in free-form XML (not RDF, or DAML+OIL, or whatever). Never
> > mind the Qname-to-URI mappings;
>Not necessarily written in XML, but accessible via XML serialization.

Well, RDF and DAML+OIL are accessible via XML serialization, so that 
makes the distinction vacuous.

> > I find this wildly implausible on
> > other grounds. For a start, there isn't any semantics for XML, so
> > what possible inferences could any software engines draw from
> > free-form XML (even if they do get their names lined up properly) ?
>Well, following the same argument, there isn't any semantics in RDF.

Er... there is, in fact, just as there is for DAML+OIL 

>Do you consider 'subject', 'object', 'predicate' as any more useful
>than 'element', 'attribute', 'processing instruction', etc.?

Maybe not more useful, but certainly more well-defined; well enough 
to support automatic reasoning, which the latter are not.

>is of course is issue of perspective. What is semantics at one level
>is just machinery at another.

I couldn't disagree more. My entire professional career has been 
devoted to showing why this false. I think that you are using 
'semantics' in an informal sense which is almost certainly 
insufficiently precise to support the infrastructure being envisioned 
for the SW.

>Yet there is rich semantics in those RDBMS's. It is fairly trivial and
>straightforward to dump a relational table as serialized XML.

Of course. One can probably serialize amost any data structure into 
XML with a little work.

>done all the time. And those serializations preserve the semantics
>of the relational tables because they maintain a distinct set of
>names used in those relational schemas, encoded as QNames.

That is not sufficient to 'preserve semantics' in any useful sense. 
In this sense, any 1:1 word substitution would preserve the semantics 
of a text, and crytography would be impossible. Do you want to claim 
that given the XML serialization and *no other information*, (not 
even the rules used to do the serialization) that one could figure 
out the content of the relational schema? If not, then the 
serialization has not, in fact, preserved the semantics. The 
semantics has been captured by the serialization PLUS some 'global' 
(ie external to the serialization itself) assumptions about the 
information there encoded and how it is encoded.

>So, if a given RDBMS is already interchanging data in XML, and
>already has defined namespaces for the QNames it uses, it is not
>reasonable IMO to expect the owners of those systems to go back
>and use different, *special* namespace URI's (e.g. tacking on '#'
>to the ends of them) just in order to use RDF safely.

Well, apart from the politics, why not? Suppose someone were to 
complain about having to write legal Java code, on the grounds that 
Java interpreters ought to be smart enough to see what he means, 
without him having to go and read all those boring manuals? That 
seems to me to be an exactly similar attitude to yours. Notice, Im 
not saying that everyone should be required to use RDF; but anyone 
who doesn't use it shouldnt feel  they have a right to complain if 
what they write isnt understood by an RDF-compliant engine. How could 
it possibly be otherwise?

>Ideally, whether a
>QName occurs in an RDF XML instance or a non-RDF XML instance, you
>would hope that the same semantics are being consistently identified.

I find that claim completely meaningless. Its obviously impossible to 
justify such a hope, in general. Human beings can't do this, so 
software agents certainly can't be expected to.

>And even if I conceded that RDF has a right to demand that such
>"special" URIs be used for namespaces (which I don't), RDF doesn't
>actually *require* nor specify that such special URIs must be
>used, and therefore folks aren't going to use them, and we will
>potentially face collisions and unneccesary ambiguity in the SW.

Ah, well now that is a reasonable point. The RDF spec should be clear 
on the matter. But that isnt what you have been saying until now.

Pat Hayes

(650)859 6569 w
(650)494 3973 h (until September)
Received on Tuesday, 28 August 2001 20:05:25 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 11:10:36 UTC