W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > February 2008

Re: A note on CURIE-s in tutorials, primers, examples...

From: Shane McCarron <shane@aptest.com>
Date: Wed, 27 Feb 2008 10:45:25 -0600
Message-ID: <47C593A5.5000808@aptest.com>
To: Ivan Herman <ivan@w3.org>
CC: W3C RDFa task force <public-rdf-in-xhtml-tf@w3.org>

This actually raises an interesting point I was agonizing over just 
yesterday.  Can someone explain to me *why* there is any value at all in 
permitting a safe_curie in @resource, @about, etc?  If the only value is 
"the resulting source file is shorter" I don't find that compelling.  I 
understand why I want to use CURIEs to scope identifiers in @rel, @rev, 
etc.  I get that they can be deferenced into nifty RDF magic.  But I 
don't see that making sense for @about or @resource.  I must be missing 

Ivan Herman wrote:
> I have spent some time in the past few days in adding RDFa to various 
> files, and I have realized that one of the recurring mistakes I did 
> was the protected curie vs URI-s. Ie, if I type in, say, a @resource 
> value, I'd put in a CURIE and I'd regularly forget to put the CURIE 
> into a '[' and ']' pair. Fortunately, my implementation has a flag to 
> generate warnings, and one of the warnings I added was when a value is 
> not protected, but does not begin with the usual 'http:', 'mailto:', 
> etc. It turned out to be very useful....
> The reason I say all that: it is probably worth emphasizing this 
> several times in the various documents. Of course, it is mentioned in, 
> say, the CURIE processing session in the syntax document, but maybe 
> more emphasis would be helpful... And we should probably draw 
> attention on this in tutorials and other places where we present RDFa...
> Of course, it may be only me...
> Ivan

Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com
Received on Wednesday, 27 February 2008 16:45:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:01:55 UTC