Re: RDFa Vocabularies

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.

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.

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.

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*

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Monarch - Next Generation REST Web Services
http://blog.digitalbazaar.com/2009/12/14/monarch/

Received on Tuesday, 12 January 2010 15:10:28 UTC