RE: Summary of the QName to URI Mapping Problem

> -----Original Message-----
> From: ext Aaron Swartz [mailto:aswartz@upclink.com]
> Sent: 15 August, 2001 20:15
> To: Stickler Patrick (NRC/Tampere)
> Cc: www-rdf-interest@w3.org; www-rdf-logic@w3.org; Sean B. Palmer
> Subject: Re: Summary of the QName to URI Mapping Problem 
> 
> 
> On Wednesday, August 15, 2001, at 05:23  AM, 
> Patrick.Stickler@nokia.com wrote:
> 
> > B. The RDF QName to URI mapping function is broken and unreliable:
> 
> I don't believe this... you've got a tough case yo make here.

Then I'll do my best to make it well.

> > I.e. if 'ns1:' = "urn:x:abc" and 'ns2:' = "urn:x:abcd"
> >      then both 'ns1:defg' and 'ns2:efg' are mapped to
> >      the same URI "urn:x:abcdefg"! Yet these are clearly
> >      separate resources per their disjunct QName identities
> 
> Really? Says who? 

Uhmmmm... the XML Namespace spec. No? 

> RDF defines a QName->URI mapping for RDF 
> documents. RDF documents must follow this mapping. 

*Documents* must follow that mapping? Don't you mean systems? And
what about RDF content that will be derived on-the-fly from other
representations or other serializations where the content producers
don't even know their stuff is being groked as RDF and thus don't 
choose the namespace URIs "carefully"? (see below re RDBMS's)

> in an RDF 
> document your examples ns1:defg and ns2:efg are the same. I 
> don't see what the issue is. RDF uses QNames as nothing more 
> than an abbreviation mechanism. 

But then one might argue that RDF mis-uses QNames, since the XML
NS spec does not define such a usage. 

> There is no great QName 
> conspiracy here. 

I never spoke of any conspiracy. Only of a shortcoming of the
mapping function defined by the RDF spec.

(though given how difficult it has been to get folks to really
address this issue, one might get the impression of a conspiracy ;-)

> QNames mean nothing special in RDF. Look at 
> N3 -- foo:bar can be replaced with <http://foo#bar> (or whatever 
> the foo prefix is defined as) with no loss in meaning.

Sure, presuming that (a) the namespace ends in a non-name character
which preserves the namespace/name boundary upon concatenation, and
(b) that the namespace was custom-tailored to the RDF interpretation
of, or custom treatment of, QNames.

Are you telling me that we cannot expect folks to want to re-use
existing XML content models which are compatible with the RDF
serialization structure as property elements and which may have
namespaces based on URIs for which the '#' at the end hack doesn't
work? Are you telling me that in order for QNames to work in RDF that 
their namespace URIs have to be "special" URIs?

Sorry, I just don't see that flying on a global scale. If RDF is
going to "adopt" URIs and QNames, then it must do so in a generic
and non-discriminatory fashion. It can't tack on special extra
rules that must be known prior to the creation of knowledge *if*
it is to work seamlessly in a global web based on systems expecting
that a valid URI is a valid URI is a valid URI wherever a URI can
be used.

TimBL himself in a '98 Design Issues spec 
(http://www.w3.org/DesignIssues/RDFnot.html) talks about how the
SW has been envisioned as a way to integrate a world full of RDBMS
content -- much of which already has XML serialization models
with defined namespaces. What if those don't fit the special criteria
seemingly required by RDF? Do we have to hack up mapping filters
to "fix" all the namespaces? Do all the namespaces have to be changed?
I can hear the RDBMS owners laughing (or groaning) already now...

If RDF is an XML application (or if XML serialization of RDF knowledge
is) then it must play by the rules laid down by the XML specs, and
that means accepting URIs used as namespaces at face value and without
discrimination.

> Outside an RDF document, if you're referring to QNames there, is 
> none of RDF's problem. If folks don't define URIs for their 
> formats, it's annoying, but I don't see how it is a flaw in RDF.

Because RDF is the only place where this is an issue. No other application
context requires a QName to map to a URI! So folks don't specially
craft their namespace URIs for use with RDF -- because they really
shouldn't have to. They should be able to use *any* URI for their
namespace, not just one that works with RDF; and if RDF can't deal
equally well with any arbitrary URI, then it *is* a flaw in RDF.

> You say a lot of fluff, but it all assumes there is some great 
> "QName to URI mapping problem". What is this problem?

Excuse me?! Did you even read the first post in this thread?
 
> > The bottom line is that *some* such solution has be 
> adopted, and soon.
> 
> Why? What is the test case?

Gee... and I thought we were far beyond "test" cases... How about the
global deployment of metadata for trillions of resources, or isn't that
what the SW is all about?

But more specifically, I've been working on employing RDF in a metadata
driven document management and distribution system that handles millions
of media objects with multilingual, multiformat, scoping, and global
localization
facets, utilizing custom ontologies but with the interest in providing
mappings to several standardized ontologies, and utilizing XML serialization
for interchange and system-independent archival. So I'm not just blowing
"fluff" out my rear end. These are real implementational issues, not
theoretical exercises, and they are issues I've been thinking long and
hard about for quite some time. Believe me, if I could have gotten RDF
to work reliably and portably as-is, I would have. I'm not slogging
through these discussions here for the fun of it.

Please have a look at my posting 'A proposed solution to the RDF 
syntactic/semantic mapping problem (long)' for examples of the kinds
of issues I am dealing with and the kind of solution I feel RDF should
provide. I'd also be happy to email it to you.

Cheers,

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 Thursday, 16 August 2001 07:16:14 UTC