Hi Ivan, I did understand that @vocab would be in addition to the current mechanisms. And if it becomes part of the standard, then we would have to discourage people in our organization from using it. But if it is part of the standard, then there would be the possibility that there might be a commercial product that utilizes the mechanism, so we might have to deal with it. This would make XHTML+RDFa less attractive as a standard for what we are trying to accomplish.
It would still complicate the standard even if it is optional. If the intent is to make it easier for authors to use semantic markup, it seems there are another approaches that would accomplish the same goal without affecting the standard. A post-processing script that replaces the tokens allows authors to take advantage of the shortcut mappings without impacting performance or introducing this complication. This approach has the potential of making it even easier for authors since it could automate decisions about using @rel vs @property, @content vs @resource, safe curie vs curie, or empty @content vs no @content vs XMLLiteral @content. There are many other possible additions to RDFa that can make it more efficient for semantic markup and encoding RDF (eg. markup on table columns vs each row, lists as containers, SPARQL named graphs, and reification in general). Perhaps it would be best to focus on making these enhancements first and then evaluating if the standard could handle further complications without becoming unwieldy. Brian -----Original Message----- From: public-rdf-in-xhtml-tf-requ...@w3.org [mailto:public-rdf-in-xhtml-tf-requ...@w3.org] On Behalf Of Ivan Herman Sent: Sunday, January 17, 2010 4:10 AM To: Brian Peterson Cc: 'RDFa mailing list' Subject: Re: RDFa Vocabularies Brian, I think you have legitimate issues that have to be handled (eg, what happens if there is a name clash). However... I do not thing anybody at any time proposed the @vocab as a replacement of the current mechanism. In other words, applications can stay with URIs and CURIEs and ignore this mechanism if they want. Is this the way you understood it? Sincerely ivan On 2010-1-17 06:35 , Brian Peterson wrote: > The document indicates that comments from the public are welcome, so if you > don't mind... > > I'm part of a group that is promoting a Linked Data architecture at our > organization, and we're advocating XHTML+RDFa as the primary response format > for web services. We find there are many benefits for using XHTML+RDFa for > data requests as well as web pages. > > The CURIE syntax appeared at first to be a small step away from URIs, but > they've proven useful for reducing the size of the docs, so I've come to > accept them. Plus, the URIs can be recovered easily enough. > > Using this @vocab framework is a giant leap away from URIs. At least CURIEs > could be processed with just local information; now there could be many > additional dereferences required just to parse the document for data. This > has the potential to kill attempts to use XHTML+RDFa for Linked Data because > of the possible inefficiencies. > > Doesn't this introduce the possibility of name clashes? If you download the > @vocab docs and some have different mappings for a term, which one do you > take? All? > > I think this proposed addition should be declined, even if the specification > covers this issue of terms with multiple mappings. RDF uses URI references > specifically to avoid this issue (among other reasons, of course). I would > prefer to see other solutions to help authors rather than diluting or > weakening the RDF basis for RDFa. > > It appears to me that this change would come at a high cost, particularly > when there are other ways of helping authors with semantic markup. Perhaps > editors could be made to assist with semantic markup? Maybe allow for a vocab > mapping shortcut but use a post-processing script that replaces the terms > with URIs or CURIEs. That way the cost is paid up front, once, and consumers > don't have to worry about it. This would allow for authoring convenience > without requiring the additional complexity, inefficiency, and ambiguity to > parsing. > > Brian Peterson > > > -----Original Message----- > From: public-rdf-in-xhtml-tf-requ...@w3.org > [mailto:public-rdf-in-xhtml-tf-requ...@w3.org] On Behalf Of Manu Sporny > Sent: Monday, January 11, 2010 11:02 PM > To: RDFa mailing list > Subject: RDFa Vocabularies > > I had an action to generate spec text for pulling in external vocabulary > documents. Here's the first cut: > > This document outlines an extension to the the syntax and processing > rules that would allow the list of reserved words recognized by RDFa to > be extended. The goal of this mechanism is to make authoring RDFa easier > for web developers and designers. > > http://rdfa.digitalbazaar.com/specs/rdfa-vocab-20100111.html > > -- manu > > [1] http://www.w3.org/2010/01/07-rdfa-minutes.html#action03 > -- 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 vCard : http://www.ivan-herman.net/HermanIvan.vcf
