RE: RDFa Vocabularies

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-request@w3.org [mailto:public-rdf-in-xhtml-tf-request@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-request@w3.org [mailto:public-rdf-in-xhtml-tf-request@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

Received on Sunday, 17 January 2010 16:50:09 UTC