Re: Updated: issue qnameAsId-18

On 2002-06-06 15:30, "ext Chris Lilley" <> wrote:

> On Wednesday, June 5, 2002, 5:10:43 PM, Brian wrote:
> BM> Norm,
> BM> 1) Can you confirm that the RDF practise of using qnames to represent URI
> BM> REF's is consistent with this finding.  If so, you might like to mention
> BM> this in section 2.
> BM> 2) RDFCore has an outstanding issue to allow qnames as attribute values as
> BM> a shorthand for a URI REF.
> A URI ref is a single item. A qname is a tuple of URI and local name.
> I don't see that one can be a substitute for the other in the general
> case.
> For specific cases where the RDF assumption is valid that namespace
> URIs end with a # and that the URI reference formed by concatenating
> the namespace URI and the localname is a valid URI reference, you
> could make that equivalence.

Right. The idea is to simply allow folks to use qnames as an editorial
convenience, similarly to how entities are used now e.g.

So, when an RDF parser (not just an XML parser) encounters
e.g. rdf:resourceQ="rdf:Class", it performs the exact same qname to
URI mapping as if it had encountered the qname as an element or
attribute name e.g. <rdf:Class ...>.

But, since RDF is anyway tossing out the qname structure and ignoring
its context, I'm not really sure this is an issue that is relevant
outside the scope of RDF. A qname in RDF that denotes a resource
is not actually a "real" qname, per the XML definition, nor
does such a qname ever remain a qname once we get to the RDF graph.

If RDF decides to allow qnames in attribute values or data content, it's
not an XML issue, since the end result is only URIs, not qnames, and the
parsing is done by an RDF parser, not just a generic XML parser (even if
the latter is imployed at some level).

It's really no different that special treatment given to specific
RDF idioms or parseTypes by the RDF parser.



Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email:

Received on Thursday, 6 June 2002 10:36:03 UTC