Re: Proposal, allow Colon in a Term

I am not sure what 'Name' includes (and I am lazy to check it:-). Would that allow for characters like #, ? etc?

Remember that other thread on whether we can simplify the spec by referring to full URI-s as CURIE-s with specific prefixes? Ie, we could define, in our default profile (yes, I know, I will answer to that separately...) a prefix for "http" mapping to, hm, "http:", and all the rest of the spec could simply refer to CURIE-s. But then we would have to allow for the '/' and other characters in the reference

Ivan


On Feb 7, 2011, at 02:03 , Nathan wrote:

> Hi All,
> 
> I'd like to propose a change to the specification, the change is simply to specify "term" as being a "Name" rather than NCName, this would allow the use of colons in terms.
> 
> Note: this will only be possible / compatible if the definition of CURIE is changed as per my proposal on ISSUE-83 [1]
> 
> The only changes which would need to be made to the specification would be:
> 
> Under "7.4 CURIE and URI Processing" change the relevant text to:
> 
> [[
> TERMorCURIEorAbsURI
> If the value is a valid CURIE, then the resulting URI is used.
> If the value is a term, then it is evaluated as a term according to General Use of Terms in Attributes. Note that this step may mean that the value is to be ignored.
> If the value is a valid URI, that value is used.
> Otherwise, the value is ignored.
> ]]
> (rules 1 and 2 have been swapped)
> 
> 
> Under "7.4.3 General Use of Terms in Attributes" change the definition of term to:
> [[
>   term     ::=  Name
> ]]
> 
> This simple change will open the door to many different uses of RDFa, will give authors an alternative design pattern for having profile like functionality (one without any dereferencing involved, where the correct triples are always generated and with non of the negative side effects of profiles), and allow those who wish to treat strings such as "foo:bar" as simple lexical tokens without any "prefix based indirection" should they wish (and non of the negative effects of prefixes).
> 
> At the same time, nothing would change for anybody else who didn't want to utilize this functionality, it's entirely compatible with the current draft of RDFa Core and all examples, it's even compatible with default profile as described, general use of profiles, terms etc etc.
> 
> ps: this would partially address many of the concerns received from members of the HTML WG, allowing people to still use "foo:bar" style tokens without any of the indirection, and my own concerns about profiles, gives us all an alternative, and an opt-out of functionality we don't want, whilst not limiting RDFa or getting rid of any existing functionality.
> 
> [1] http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Feb/0035.html
> 
> Best,
> 
> Nathan
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf