Re: CURIEs vs. QNames

/ Ben Adida <ben@mit.edu> was heard to say:
|> | Do I really need to write the Dublin Core URI multiple times?
|>
|> That would work.
|
| Yes, it would "work," but it would violate one of our strong
| requirements that we help users not duplicate data unnecessarily. If
| a user wants to upgrade from one version of Dublin Core to the next,
| he shouldn't have to go change all the Dublin Core properties used
| throughout every document.

Interesting. I'm used to the argument that URIs are bad because
they're long and hard to type. Your argument above is for a level of
indirection, is that right?

|> I'd prefer to simply allow
|>
|>   <dc:creator>Norman Walsh</dc:creator>
|
| Seems like <meta property="dc:creator">Norman Walsh</meta> is close
| enough, though again that violates the TAG and overloads the QName
| usage. We're trying to fix that.

The relevant TAG finding says:

  | In so far as the identification mechanism of the Web is the URI and
  | QNames are not URIs, it is a mistake to use a QName for identification
  | when a URI would serve.

On the face of it, that would argue for

<meta property="http://purl.org/dc/elements/1.1/creator">Norman Walsh</meta>

which certainly avoids the problem. But I understand that's problemtic
for you. The finding goes on to say:

  | That said, the TAG recognizes that there are sometimes pragmatic
  | reasons for chosing short, lexical representations of more complex
  | names and accepts that QNames are an established mechanism for doing
  | so.

So if you need short names, the finding actually suggests using
QNames.

  | Where there is a compelling reason to use QNames instead of URIs for
  | identification, it is imperative that specifications provide a mapping
  | between QNames and URIs, if such a mapping is possible.

For RDF, I believe the established mapping is "concatenation".

  | Finally, we observe that a whole class of interpretation problems can
  | be avoided if the use of QNames can be restricted to contexts where
  | their identification is natural and unambiguous (element and attribute
  | names, simple content of type xs:QName, etc.) and we encourage
  | developers to employ such restrictions wherever possible.

If the property attribute (and other places where QNames occur in your
syntax) contains only a QName, then I don't think there's anything
wrong with using a QName there. You certainly don't have to invent
something new to satisfy the spirit of the TAG finding.

|> | Do I
|> | really need to start using XSLT just so I can define URI
|> | abbreviations? Or should I simply violate the TAG's recommendation
|> | that QNames not be used as URI abbreviations,
|>
|> Yes. That's what everyone else does, that's what everyone expects.
|> Doing something else is going to be more confusing.
|>
|> | and then be stuck with
|> | a mostly-working-but-not-quite-complete abbreviation scheme?
|>
|> Yes.
|
| I feel that the above approach is deeply broken. You're effectively
| saying "ignore the TAG, that's what everyone else does." Even worse,
| it seems that we should sometimes ignore the TAG, and at
| other times abide by the TAG rules quite strictly. Maybe this is the
| unwritten W3C rule and I'm just not used to it.

Read section 6 of that finding again. The TAG went out of its way to
frame the architectural principle in a manner consistent with actual,
real-world usage. The finding explicitly grants that there are
sometimes reasons to use QNames and gives guidance on how to
mitigate the problems they cause.

|> | I certainly understand the worries about the specific syntax that
|> | will be used for CURIEs, and the task force is actively discussing
|> | various options right now. However, I don't understand this reaction
|> | to the CURIE concept.
|>
|> Conceptually, I think it's going to be confusing to introduce another
|> syntax for something that can almost always be represented as a QName
|> without introducing a new syntax. Syntactically, I think overloading
|> the QName syntax is just plain wrong.
|
| So, if I understand you correctly, you're saying there is no right
| solution. The current solution of overloading QNames is syntactically
| (and possibly semantically) wrong. Yet everyone does it. And it
| violates the TAG recommendation. If we continue to live with "almost
| always," confusion will only get worse, and we are going to come up,
| at some point, with a series of scenarios that inevitably don't fit.

The only scenario I recall seeing was the one where the local-name
part of the putative QName is not an NCName. Are there other
scenarios, or is that the only one?

| Why are we afraid to start solving this problem? We have a very good
| reason to address it now. RDF clearly calls for using namespaces
| multiple times, particularly multiple namespaces in a given document.
| That's the point of RDF, in fact. Adding RDF to HTML, where certain
| attributes are already typed as URIs and cannot be changed willy-
| nilly, forces us to resolve the QName/URI conflict.
|
| The needs of expressing RDF in HTML present an opportunity to solve a
| long-standing problem. I can't see why punting on it yet again is a
| good thing.

Fair enough. I think I've made my points. I won't kibitz any further.
Please let me know when a draft of your proposed solution is
available.

Good luck!

                                        Be seeing you,
                                          norm

-- 
Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc.
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.