Re: Proposal, allow Colon in a Term

Thought it might be worth clarifying on a use case, should this proposal 
be accepted, then I'm basically going to make a @vocab for myself which 
has a load properties in it, each defined something like..

   <#foaf:name> owl:equivalentProperty foaf:name .

And thus I'd refer to "foaf:name" as:

   <http://example.org/my-vocab#foaf:name>

Then at the top of all of my RDFa documents I'll simply do:

   vocab="http://example.org/my-vocab#"

and never worry about defining another prefix or profile for a very long 
time (or about one being undefined, copy pasting, what happens if a 
profile can't be dereferenced etc).

Best,

Nathan

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
> 
> 
>

Received on Monday, 7 February 2011 03:07:40 UTC