Hi
Mark Birbeck wrote:
Using Julian's example:
<a xmlns:urn="http://purl.org/dc/terms/";
rel="urn:rights urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a"
href="http://example.com/terms_of_service.html";>
>Terms of service</a>
I have a more realistic example for a problematic prefix mapping that you might
actually want to use:
<a xmlns:http="http://www.w3.org/2006/http#"; rel="http:requestURI http://example.org/";
href="http://www.w3.org/2006/http#asterisk";>blah</a>
RESERVED VALUES V. RELATIVE PATHS
However, CURIE processing evolved a little, and what effectively
happens now is that any predefined tokens are checked for first,
before the whole prefix-processing steps kick in. So it's actually
possible to differentiate between a predefined token and a relative
URI, since it's either in the list, or it's not:
@rel="next"
@rel="relative-url"
I think this is a rather wonky solution because people use all sorts of values that are
not defined in any constant list - or with HTML 5 you have a dynamic list defined on some
wiki page. Google's "canonical" is one example.
DIFFERENTIATING BETWEEN CURIES AND URIs
Interestingly enough, it is possible to solve this problem, by simply
saying that any string of characters that begins with a predefined
prefix is a CURIE, and anything else is a URI.
This, as well, I find a bit wonky. You always have to keep an eye on which
prefixes you defined and which not. And if, say, you can only edit some snippet
of a site then you might not even see all the prefixes that are defined in the
whole document unless you look at its source. Not good for people who copy and
paste some code but don't know much about HTML otherwise.
Of course, we always had this hack of defining xmlns:http="http" and then you
can just use absolute HTTP URIs within @rel and @rev.
On a side note: In a template system I use CURIEs to access an RDF graph (that contains the data to
be put into the page). There for simplicity I just defined that everything starting with
"http:" is actually a HTTP URL. All other URIs, especially relative ones, have to be
escaped to "safe URIs", URIs in angle brackets.
PROPOSAL
So to bring everything together, the proposal is:
(a) RDFa should add support for URIs in attributes that currently only
support CURIEs;
(b) authors should be encouraged to use safe-CURIEs in those
attributes;
(c) but since ordinary CURIEs may still be used, we should differentiate
by saying that anything appearing before a colon, that is not a
mapped prefix, is a protocol.
(From an implementation point of view this is extremely easy to add;
if after splitting a 'potential CURIE' you find that the prefix does
not map to anything, then just treat the 'potential CURIE' as a URI.
Current processing requires the 'potential CURIE' to be ignored
altogether.)
You talk above about backwards compatibility for markup that already uses something like
rel="foaf:knows". But what about backwards compatibility for existing parser
implementations? Wouldn't they break on what you propose? Are you confident that all
existing implementations will be updated to that behaviour (if they don't already
implement it) and that deployed systems will be updated to those new versions?
Regards,
Simon
