QName URI Scheme Re-Visited, Revised, and Revealing (was RE: De dicated, Standardized URI Scheme for QNames?)

I wrote:

> Are you saying that the same QName, used for both element and
> attribute name in the same XML instance, will represent different
> semantics?
> 
> ...
> 
> 4. If type ... is a manditory property of 
> the uniqueness of a QName ... then type 
> should of course be reflected in the qn URI scheme...


OK, I got a little bit of egg on my face here. I re-re-read the
XML NS spec and Sean is quite right about the QName partitions being 
a component of the lexical identity (though I wonder what the significance
is of those partitions being non-normative...) That information should, 
I fully agree, be embodied in some way in any alternate representation
of QNames that exists outside the scope of the serialized instance
in which they occur.

Thanks, Sean, for beating that into my thick skull ;-)

But because the partition information contributes to the lexical 
identity of QNames, I would opt for including it in the URI scheme
proper, rather than as statements in the RDF based on URIs derived
by some other concatenative/fusion based formula.

E.g. Something like the following revised syntax might do the trick 
for partitioned QNames:

1. All Element Types Partition:

   'qn' ':' '{' <namespace> '}' <ename>

   <foo:bar xmlns:foo="urn:abc:foo">

   qn:{urn:abc:foo}bar            (element)

2. Global Attribute Partition:

   'qn' ':' '{' <namespace> '}' '@' <aname>

   <... xmlns:foo="urn:abc:foo" foo:bar="...">

   qn:{urn:abc:foo}@bar           (global attribute)

3. Per-Element-Type Partitions:

   'qn' ':' '{' <namespace> '}' <ename> '@' <aname>

   <foo:bar xmlns:foo="urn:abc:foo" bas="...">

   qn:{urn:abc:foo}bar            (element)
   qn:{urn:abc:foo}bar@bas        (per-element attribute)

Thus, all together, with no loss of lexical distinction:

   <foo:bar xmlns:foo="urn:abc:foo" foo:bar="..." bas="...">

   qn:{urn:abc:foo}bar            (element)
   qn:{urn:abc:foo}@bar           (global attribute)
   qn:{urn:abc:foo}bar@bas        (per-element attribute)

--

Such a representation is concise, regular, explicit, bidirectional, 
globally unique, and reasonably human parsable.

The '@' marker for attribute (rather than element) name is mnemonicly
related
to (rhymes with) the word "attribute" and the identity of per-element type 
attributes is clearly an extension of their contextual element identity.

No loss of partition information, and no need for sub-graph structures
or additional RDF statements to capture that important information, and
we still have just URIs defining resource identities in the RDF graph.

Eh?

--

*BUT*!  (fasten your seat belts...)

There will now arise problems where element QNames and global attribute
QNames represent the same resource, because now there can be a many to one
interpretation of QNames to some concept. 

It may very well be that RDF's treatment of namespaces is even more
non-compliant than we thought, *if* those namespace partitions are "real"
(again, the issue of their being non-normative arises).

Just to take a single example derived directly from the RDF M&S spec:

Both 

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:s="http://description.org/schema/">
  <rdf:Description about="http://www.w3.org/Home/Lassila">
    <s:Creator>Ora Lassila</s:Creator>
  </rdf:Description>
</rdf:RDF>

and

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:s="http://description.org/schema/">
  <rdf:Description about="http://www.w3.org/Home/Lassila"
		       s:Creator="Ora Lassila" />
</rdf:RDF>

should equate to the same knowledge, namely (using the original  
non-partition qn URI syntax):

   [http://www.w3.org/Home/Lassila,
      qn:{http://description.org/schema/}Creator,
         "Ora Lassila"]

but in fact, if it really is true that those namespace partitions 
exist and that the same QName used for an element is a different 
lexical construct than when used for a global attribute, then these 
alternate syntaxes, using the above revised qn URI syntax, result 
in different statements. I.e. rather than getting the same triple
from both serializations, we get from the first serialization:

   [http://www.w3.org/Home/Lassila,
      qn:{http://description.org/schema/}Creator,
         "Ora Lassila"]

and from the second abbreviated serialization:

   [http://www.w3.org/Home/Lassila,
      qn:{http://description.org/schema/}@Creator,
         "Ora Lassila"]

Which are (to RDF) not the same statement! Oops!

Hmmmm.... do we need then to use DAML equivalence constructs for
basic RDF?! E.g.

   <qn:{http://description.org/schema/}Creator>
      daml:equivalentTo
         <qn:{http://description.org/schema/}@Creator> .

??? 

So, if QNames belonging to different partitions are different things, such
that the partition distinction results in a distinction of identity in
the knowledge base (by whatever method a URI is derived from the QName,
either qn:{namespace}@name or namespace#attribute_name, etc.) then allowing
alternate serializations where the same concept (resource) is identified
either as an element or global attribute will be a *big* problem.

Two questions can IMO direct this issue one way or another:

1. Can a QName used in one partition represent semantics that is not
equivalent
to the semantics attributed to the same QName in another partition? 

I.e. can an element <foo:bar> a global attribute <... foo:bar="..."> and 
a per-element attribute <... bar="..."> all mean different things?

2. And if so, is RDF required to maintain that distinction? 

If the answer to the first question is no, then the present RDF treatment of
not differentiating between equivalent lexical identity in different
partitions
is valid. And the initial non-partition qn URI syntax is sufficient.

If the answer to the first question is yes, then we can then consider the 
second question.

If the answer to the second question is no, then again, the present RDF
treatment
is valid. And the initial non-partition qn URI syntax is sufficient.

If the answer to the second question is yes, then not only do we need the
revised 
qn URI syntax such as above, but the need for explicitly defining
equivalences
between the different resulting resource identities must be clearly
documented;
i.e. we've got some major work to do.

--

At present, I'm unsure about the first question, though I'm leaning towards
yes,
even though QName partitions are non-normative. What is the view of e.g. the
XML Schema
or XPath communities? Since the XML-DEV folks seem to be revisiting this
issue
(c.f. http://www.xml.com/pub/a/2001/08/08/oldwounds.html) maybe we should
add this
additional chaff to the common fire...)

As for the second question, I firmly believe the proper answer is yes, if it
is
indeed determined that it is the XML Core standards, or the majority
interpretation
of them, that provides the positive answer to question 1.

Thus, if both answers are yes, then this QName to URI mapping issue has
become that 
much more serious a problem for RDF... (sorry to keep raining on the parade
;-)

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 Wednesday, 22 August 2001 06:00:20 UTC