Official RDFa Response: ISSUE-90: CURIEorURI Value Space Collisions

Niklas,

This is an official response from the RDF Web Applications Working
Group, previously the RDFa Working Group, on your 2nd Last Call comment
on RDFa Core 1.1. The issue has been tracked here:

ISSUE-90: CURIEorURI Value Space Collisions
http://www.w3.org/2010/02/rdfa/track/issues/90

Your comment raised the point that the value-space of a CURIE is
open-ended enough that a future Internet Protocol Scheme may conflict
with a CURIE prefix chosen before the scheme was realized. The best
real-world example is the 'http' vocabulary, which can be found at this URL:

http://www.w3.org/2006/http#

You assert that what the author intended is ambiguous when they specify
the following text:

http://example.org/

Do they mean:

http://example.org/

or do they mean:

http://www.w3.org/2006/http#//example.org/

The second one is probably not what they intended, but your suggestion
was that we may want to limit what is allowed in a CURIE to something
more strict, such as the regex: "[A-Za-z0-9_-.]+". Doing so would ensure
that the URI is the one that would be chosen by the RDFa Processor in
the example above.

We discussed this at length and found the following:

1. Limiting the CURIE to a regex arbitrarily limits the allow-able
   characters such that other use cases cannot be supported, such as
   CURIE references containing "@" or ":" or any internationalized
   character in them.
2. Limiting the character set still doesn't prevent false positives
   for very simple schemes like SIP. For example, to prevent a
   false positive for "sip:niklas@example.org", one would have to
   limit the "@" in all CURIEs. However, there may be some vocabularies
   that want to utilize the "@" sign. That is, we may think we know
   which characters are important now, but all that must happen for
   this approach to fail is that an Internet Scheme would appear that
   uses a character in the list of acceptable characters - for example,
   "-" or "."
3. CURIEs are not allowed in @href and @src, so the likely-hood that
   this will become a practical concern is lessened.
4. There is no ambiguity as far as an RDFa Processor is concerned.
   For example, if an "http" prefix is defined, then anything that
   accepts a CURIE would expand the "http" prefix. That is, if the
   prefix is defined, it is a CURIE. If it is not defined, it is an
   IRI. Authors will discover this very quickly and vocabulary
   maintainers are advised to avoid naming their vocabularies after
   Internet Protocol Schemes.
5. It would create a backwards-incompatible change to RDFa. The
   Working Group is not chartered to make this sort of change to
   RDFa.

In the end the group didn't think that limiting the value space of
CURIEs would actually solve the problem you are concerned about. It may
lessen the problem, theoretically, but nobody has demonstrated where
this leads to a critical real-world problem with RDFa. In the worst
case, the vocabulary prefix is changed in the RDFa document. In the end
the Working Group decided to not place additional limitations on the
value-space for CURIEs for the reasons listed above.

We discussed it during two telecons:

http://www.w3.org/2010/02/rdfa/meetings/2011-05-05#CURIEorURI_Value_Space_Collisions
http://www.w3.org/2010/02/rdfa/meetings/2011-05-19#ISSUE__2d_90__3a__CURIEorURI_Value_Space_Collisions

The decision is recorded here:

http://www.w3.org/2010/02/rdfa/meetings/2011-05-19#resolution_2

Since this is an official Last Call response, could you please respond
as soon as possible and let us know whether or not the Working Group has
considered your request and responded accordingly. Please let us know if
this is an acceptable outcome and whether you can live with the
decision. Thank you for reviewing the RDFa specification and sending in
your comments. :)

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Developer Tools and Demo Released
http://digitalbazaar.com/2011/05/05/payswarm-sandbox/

Received on Saturday, 28 May 2011 21:59:45 UTC