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

RE: Summary of the QName to URI Mapping Problem

From: <Patrick.Stickler@nokia.com>
Date: Mon, 20 Aug 2001 11:30:50 +0300
Message-ID: <2BF0AD29BC31FE46B78877321144043114BF97@trebe003.NOE.Nokia.com>
To: phayes@ai.uwf.edu
Cc: www-rdf-logic@w3.org, www-rdf-interest@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)
scheme.

See my posting from today on the www-rdf-interest group:
http://lists.w3.org/Archives/Public/www-rdf-interest/2001Aug/0134.html 
for an alternative approach to my other 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.
 
> 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.
Do you consider 'subject', 'object', 'predicate' as any more useful
than 'element', 'attribute', 'processing instruction', etc.? Semantics
is of course is issue of perspective. What is semantics at one level
is just machinery at another.

Yet there is rich semantics in those RDBMS's. It is fairly trivial and
straightforward to dump a relational table as serialized XML. It's
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.

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. 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.

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.

There's a hole there, but RDF isn't even warning folks it's there.

Regards,

Patrick

--
Patrick Stickler                      Phone:  +358 3 356 0209
Senior Research Scientist             Mobile: +358 50 483 9453
Software Technology Laboratory        Fax:    +358 7180 35409
Nokia Research Center                 Video:  +358 3 356 0209 / 4227
Visiokatu 1, 33720 Tampere, Finland   Email:  patrick.stickler@nokia.com
 
Received on Monday, 20 August 2001 04:31:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:52:40 GMT