Re: ISSUE-36 (Default vocab specification): Should Profile documents allow the specification of a default vocabulary? [RDFa 1.1 Core]

  Just some feedback that may be helpful when considering this Issue.

On 16/07/2010 13:22, RDFa Working Group Issue Tracker wrote:
> ISSUE-36 (Default vocab specification): Should Profile documents allow the specification of a default vocabulary? [RDFa 1.1 Core]
>
> http://www.w3.org/2010/02/rdfa/track/issues/36
>
> Raised by: Manu Sporny
> On product: RDFa 1.1 Core
>
> Markus proposed that Profile documents should allow the creation of a default vocabulary:
>
> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010May/0041.html
>
> This has a number of implications:
>
> 1. How does one declare a default vocabulary via the profile document?

link rel="profile" X/HTML5+ documents.
head @profile for XHTML 1.X and HTML4.X documents.

> 2. How does the declaration affect the @vocab attribute, would it override it and if so, in what order?
and @prefix

It shouldn't @profile should be of least importance in the food chain, 
an author may not have control of the document of @profile, where he 
does over the source document that contains @prefix and @vocab.

> 3. How does the declaration affect the CURIEs like ":next"?

not so sure about that one ;) my preference is RDFa1.1 should 
grandfather @rel values so none at all :P

> The biggest question is the value of this feature? What is the use case that we are attempting to support? Does this overly-complicate RDFa without much payback?
>

 From experience I have to run two parsers one to produce a list of 
prefix mappings (whether the profile has been cached or not) these 
prefix mapings (all of them) then have to be injected into a second 
instance in order to parse the containing RDFa of the referring page. I 
have found downloading a list of prefix mappings from 
http://prefix.cc/popular/all.file.txt and processing that faster at 
resolving prefixes than processing @profile. In short I'd rather not :)


Best wishes

-- 
Martin McEvoy

Received on Friday, 16 July 2010 13:57:29 UTC