Henri Sivonen wrote:
On Aug 27, 2008, at 16:33, Smylers wrote:
So that is one disadvantage of URIs: they are long. In fact they are so
long that people have gone to the bother of inventing additional syntax
to avoid having to write them out.
Moreover, having to look up the URIs is a major pain when writing
software that processes namespaced XML. I can remember "xhtml", "xlink"
or "svg", but I can't remember the namespace URIs. What random year do
they contain? Is there a slash in the end?
I always use copy & paste. So I really don't care a lot.
The RDF community has minted a lot of namespace URIs over the past 10
years. In addition to minting URIs, they have minted canonical prefixes
for each one. It would be interesting to analyze how often those
canonical prefixes actually collide and how often the local property is
within the namespace also collide when the prefix collides.
Make sure that when you do that analysis, you don't forget to check for
prefixes of less-popular vocabularies, or prefixes used behind closed
doors (intranets).
HTML5 isn't really giving language users the choice. It gives the choice
to designers of language extensions.
It seems to me that if the RDF community isn't going to stop using URIs
when they mint new property vocabularies, the only way to get a
bidirectional generic registryless open-ended mapping between syntax
going into text/html resources and RDF easy using URIs for identifying
properties.
Yes.
So the cost of using URIs should be weighed against the benefit of
having such a generic bidirectional mapping that is open-ended in the
sense that the mapping algorithm doesn't need new out-of-band input from
a registry (other than the URI scheme and domain name registries
apparently...) when someone mints a new vocabulary.
. . .
If we didn't want the mapping to be bidirectional and only wanted it to
be unidirectional from HTML identifiers onto URIs, we could specify that
you can make a URI from any identifier you find in HTML by concatenating
it to a common URI prefix. It doesn't really matter much if we call the
prefix http://www.w3.org/1999/xhtml/vocab#,
http://n.whatwg.org/rdf-compat# or something else. (To avoid collisions
between e.g. rel and class, you could put the attribute name in the URI:
http://n.whatwg.org/rdf-compat/rel#keyword http://n.whatwg.org/rdf-compat/class#class-name.)
That's a possibility, and furthermore exactly the way the Atom link
relations registry works.
. . .
But with a scheme that maps HTML syntax to *some* URIs, can the Power of
RDF solve the rest? After all, the Power of RDF already assumes that
clients have hard-coded knowledge of URI schemes (at least http) and can
consult DNS dynamically. Moreover, the Power of RDF already assumes a
dynamically consulted mapping registry (like
http://creativecommons.org/ns#) per each vocabulary. We could just say
that HTML5 is one big vocabulary, so it can have one mapping registry.
I'm not so sure that what you call "the Power of RDF" actually
*requires* namespace names to be resolvable.
The HTML5 draft already specifies a registry for rel values:
http://wiki.whatwg.org/wiki/RelExtensions
Which seems to be defunct, none of the entries has the state "accepted".
I'm also very skeptic about
'For the "Status" section to be changed to "Accepted", the proposed
keyword must either have been through the Microformats process, and been
approved by the Microformats community; or must be defined by a W3C
specification in the Candidate Recommendation or Recommendation state.'
because that requires to either go through the W3C process or the MF
community. I still believe that a simple IANA registry will work better.
...
BR, Julian
