- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sat, 28 May 2011 17:59:07 -0400
- To: Niklas Lindström <lindstream@gmail.com>
- CC: RDFa WG <public-rdfa-wg@w3.org>
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