On Feb 20, 2009, at 07:49, Manu Sporny wrote:
Henri Sivonen wrote:
I'm particularly worried about ccREL succeeding to the point that an
alternative solution can no longer be launched into the market to
replace it and Free Culture then getting encumbered by the syntactic
complexity preventing even further success.
Which alternative solution to ccREL are you referring to?
A hypothetical alternative that isn't being developed because the
effort is put into ccREL in RDF.
Could you provide at least one alternate mechanism? The mechanism
should
not use full URIs, and should addresses most, if not all, of the
problems solved by using full URIs?
A backwards-incompatible alternative mechanism would be tokens of the
type "prefix-local" (or "prefix:local", but I'm trying to avoid
confusion here) where prefix *wouldn't map to anything*. That is,
processing would merely compare the "prefix-local" code point for
code
point without expanding it to anything. Prefixes would be from two to
four letters--preferably acronyms for the vocabularies--
Why are we imposing arbitrary limits on prefix-names? For example, we
(Digital Bazaar and the Microformats community) have created an Audio
RDF vocabulary, and we would like people to use "audio" for the prefix
in RDFa. Granted, we can't /make/ them do that, but do make a
best-practice suggestion that they spell it out so it's easier to read
the HTML code, for those that care about such things.
My point was that short prefixes provide enough space in practice. I
didn't mean to impose an arbitrary limit to vocabulary designers who
want a longer prefix.
a one-letter URI scheme
(e.g. 'r' for RDF) could be registered adding two characters of
overhead
per predicate: "r:prefix-local".
To add back dereferencability in pre-existing software and to use a
pre-existing registry system, a TLD called 'rdf' could be
registered and
the identifiers could take the form "http://local.prefix.rdf"; with 11
characters of overhead. If a software update for dereferencability is
OK, "r:prefix-local" could be defined as the identifier to compare,
but
to dereference it you'd map it to "http://local.prefix.rdf"; before
passing it to the HTTP layer.
I thought your whole point was to get away from using URIs of any
sort?
I'm a bit confused at this point, didn't you state that URIs were a
bad
thing and we shouldn't use them at all?
Right.
However, as an elaboration, I outlined a way to make masquarade short
strings as URIs to avoid disruptive changes to deployed RDF software.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
