Re: RDFa Vocabularies

On 2010-1-12 16:13 , Manu Sporny wrote:
> Ivan Herman wrote:
>> It does put an extra load on implementation that is non negligible.
> 
> Yes, that's very true. Remote retrieval of vocabulary documents makes it
> impossible to do a Javascript implementation unless there is a new
> browser feature added (for retrieving plain text @vocab documents). For
> example:
> 
> var vocab = document.getVocabulary("http://example.org/vocab");
> 
> The http://example.org/vocab document would have to exist in the current
> document in a @vocab attribute in order for the browser to allow
> retrieving it. We may want to consider adding this requirement to the
> RDFa API document.
>

That is a tall order. I am not a JS expert but isn't it correct that
this restrictions is deeply rooted in the browser environment? Ie, we
would then have an implicit requirement that a full blown JS
implementation would not work as a library developed by a third party.
That would be real bad:-(

> The alternative is native, full-browser support for RDFa, which would
> take some time to implement in all browsers. We may have more luck
> getting a simple API call into the browser.
> 
>> I wonder whether we should not restrict ourselves to RDFa as an accepted
>> format. Implementations still have to, sort of, recursively call
>> themselves to interpret vocabulary files, but at least no further parser
>> is necessary.
> 
> Right, I agree that the document should be marked up in RDFa. The only
> reason the text isn't more specific about XHTML+RDFa or HTML+RDFa was
> because we may want to serve SVG+RDFa or ODF+RDFa from that URL via
> content negotiation.

Ah, good point. Actually, as this is going to be in RDFa 1.1, we may
refer to the general RDFa in XML document or HTML5/RDFa as the possible
target and that could cover all variations...

> 
> I'll try and put some language in there that makes it more clear that
> the RDFa Vocabulary document should be marked up in RDFa.
> 
>> - there is a danger for cycles.
> 
> Keeping a [vocabulary stack] around and pushing/popping vocabs processed
> via @vocab would be one way of solving that problem. When you process
> each @vocab URL:
> 
> 1. Check the stack to ensure that the URL doesn't already exist on the
>    stack. If it does, a cycle has been detected and you don't process
>    the vocab URL.
> 2. If the URL doesn't exist in the stack, you push the URL onto the
>    stack and process the document. Pop the vocab URL off of the stack
>    when you're done processing the document.
> 

Yeah, I realized that this is not a specification but an implementation
issue.

> Ben Adida tweeted:
>> suggest making the predicates non-RDFa specific, it's just
>> tokenization, it's not RDFa-specific.
> 
> So, instead of rdfa:term, we could do something like (pick one):
> 
> parser:token
> curie:token
> curie:prefix
> curie:reference
> xhv:token
> 
> I agree, it would be better to specify something broader than just RDFa.
> Perhaps Microdata and RDFa could share these vocabulary descriptions :)
> 
> *ducks*
>

:-)

Ivan


> -- manu
> 

-- 

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