RE: xmlns, uri+name pairs or just uris..? Clarification needed.

Hi Perry,
> 
> My opinion, which I know is shared by at least some of the 
> implementors on
> this list, is that this part of the RDF spec is in error.

Yup!  I got very confused by this at one point.  I've come to a 
sort of 'well we can live with it ...' sort of position in my own
mind, but its not very pretty.


> ... the relevant stuff justifying the assertion that

 as far as
     XML is concerned, a qname is a pair (ns, locaname) not the
     concatenation of ns and localname, i.e.

     <x xmlns:fo="fo" xmlns:foo="foo">
       <y fo:obar="a" foo:bar="b"/>
 
     is legal - the attribute names are distinct even though
     they concatenate to the same string.

Whilst the NS spec is not absolutely precise on this, it seems like best
interpretation.
 
> 
> I think you can guess from the above how I chose to implement 
> expanded names
> in our RDF processor and API.
> 

Me too.  In my SQL stuff I separate out the namespace part and the
localname part into different tables.

There are different opinions here.  You may recall that I asked
Sergey to modify his java api to pass the qname structure through
the API rather than the URI.  He refused on the grounds all you
need in the model is the URI.

With my usual caveats of I'm new to this and not the expert, here
is my current reasoning:

XML does define a qname to be a pair(namespace, localname).  RDF
models however, are defined in terms of URI references.  Resources are
identified by a URI reference as are properties.

The current RDF XML serialization makes use of XML qnames to represent
URI references.  RDF defines a mapping from qnames to URI references,
which is, unfortunately, to simply concatenate the two.

So given a qname from an XML processor, an RDF processor can determine
what URI reference the pair representing the qname represents.

The mapping is not a one to one mapping, i.e. there are several qnames, that
at least syntactically could represent an arbritary URI reference.
Unfortunately, this is a potential problem.  Given a URI reference for
a property, it is important to be able to determine the correct namespace
for that property because the namespace defines the schema that defines
its interpretation.

So when, for example, a URI reference for a property is encountred say as
the
value of an rdf:about or rdf:resource reference, it is not in general
possible to determine what schema applies to that property just by
processing the URI.  In the words of the sage, BUMMER!

However, if a convention that all namespace URI references used for RDF
will end in a character that cannot appear in the localname part of qname,
then it is possible to determine the correct namespace from the URI of 
a property alone.  The current SiRPAC implementation relies on this.
Given this conduct, the flaw is not deadly.  I have seen published examples
of RDF schemas that did not adopt this convention, but I'm not sure
which ones - possibly the document on how to represent dublin core in RDF,
but I'm not sure.

Comments?

Perry, do you have a java parser that will pass through the qname pair
rather
than the URI?

Brian

Received on Friday, 28 July 2000 05:51:28 UTC