- From: Dan Connolly <connolly@w3.org>
- Date: Wed, 15 Aug 2001 11:57:21 -0500
- To: Drew McDermott <drew.mcdermott@yale.edu>
- CC: www-rdf-logic@w3.org
Drew McDermott wrote:
>
> Thank you, Mr. Stickler, for a very clear discussion of the QName/URI
> problem. I always blamed myself for not understanding how this was
> supposed to work, and it's nice to realize that no one else
> understands it either.
no one? There's ample evidence to the contrary...
> The designers of XML clearly intended QNames to be the "skeleton" of a
> domain.
Keep in mind that the design of XML namespaces was concurrent
with the design of RDF, when plenty of cross-participation and
collaboration; the RDF way of using namespaces is
as much by-design as any other use of XML namespaces.
> That is, if you were making up a notation for describing,
> say, luggage, you might want a predicate 'manufacturer', and it would
> end up as an element tag somewhere, in a context like
> <lugg:manufacturer>...</lugg:manufacturer>
>
> The names aren't defined in any sense except that there is an API
> description somewhere that tells programmers how a compliant
> luggage-notation reader/writer is supposed to behave when it sees
> 'manufacturer' in the International Luggage Language namespace.
>
> Then
i.e. meanwhile ...
> RDF introduced conventions such as that
>
> <rdf:Description ...>
> <rdf:type resource="{some URI}">
> ...
> </rdf:Description>
>
> may be abbreviated
>
> <{some QName} ...>
> ...
> </{some QName}>
>
> where {some QName} and {some URI} must expand to the same resource.
>
> Example: We declare the namespace
> xmlns:foo="http://www.foo.org/names#",
> and then we can abbreviate
>
> <rdf:Description ...>
> <rdf:type resource="http://www.foo.org/names#wow">
> ...
> </rdf:Description>
>
> as
>
> <foo:wow ...>
> ...
> </foo:wow>
>
> Obviously, QNames are playing a very different role here than in XML.
Er... different than in XML? The above _is_ XML, as well as RDF.
The use of namespaces in RDF is one of the many uses of namespaces
in XML.
> No RDF processor is expected to know what 'foo:wow' means in the same
> sense that a program compliant with the International Luggage Language
> is expected to know what 'lugg:manufacturer' means. Instead, QNames
> are being used as a URI abbreviation device.
>
> Does that mean I could write:
>
> <rdf:Description ...>
> <rdf:type resource="foo:wow">
> ...
> </rdf:Description>
>
> or
>
> <"http://www.foo.org/names#wow" ...>
> ...
> </"http://www.foo.org/names#wow">
>
> The answer is a loud No! for the second, and, I believe, a somewhat
> softer No for the first. So whoever generates the RDF has to make
> sure there are two distinct ways of referring to the resource in
> question. Assuming the URI is given, it may not be obvious what the
> proper QName is for referring to it.
_the_ proper QName? Any qname whose prefix binds to a URI reference
which, when concatenated with the QName's local name, yeilds
the relevant URI is just fine.
> The only rule is that the URI be
> broken into a prefix and suffix, where the suffix is alphanumeric and
> the prefix is defined as a namespace.
Exactly.
(a quibble: I understand "alphanumeric" to refer to the pattern
of characters allowed in XML names)
> But there's no rule for where
> to break it, and, as Patrick pointed out, if you do it the wrong way
> you get ambiguities.
What ambiguities? concat(nsname, localname) is completely
unambiguous.
> This really is a glaring hole in RDF that needs to be filled.
Well, it's a discussion that keeps happening.
But I have yet to see any coherent argument that there's an
actual technical hole.
> Adopting an offical QName <-> URI mapping convention seems to be the
> obvious solution.
The RDF spec includes an unambiguous QName -> URI mapping:
uri(qname) = concat(nsname(qname), localname(qname))
It's a W3C recommendation; that's as official as we get around here.
It's not possible to define a URI->Qname mapping, since not
all URIs end in XML name characters. (This is a limitation
that designers of RDF vocabularies should be made aware
of by some NOTE in the spec or something.)
> Not all QNames would have to be mappable, but it
> should be obvious from a namespace declaration whether it was defining
> mappable names or not. Then one could use a mappable QName in any
> context where a URI was expected (but not vice versa, to avoid
> violating XML rules).
I don't understand this last bit.
--
Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Wednesday, 15 August 2001 12:57:23 UTC