Re: RDFa and Web Directions North 2009

Dan,

Thanks for a very helpful points.

> As an aside here, this is an approach to data exchange very much in the
> spirit of what we built with RDF. [...]

One of the important things we realized at Creative Commons early on is
how much of our machine-readable-license problem was solved by RDF, and
how much we could benefit from the existing and growing toolsets and
vocabularies (Adobe XMP, Dublin Core, FOAF, etc...)

> So yes, when search engine "(non-interactive) user agents" (like Yahoo
> SearchMonkey / BOSS) start doing things with this data, RDFa enthusiasts
> are pleased. But the makers of those search systems are not being
> requested to do anything; they chose to. Interactive user agents ( ~
> browsers ) are in a somewhat different situation, since their software
> stands between 3rd party .js and many kinds of potential in-page or
> in-browser features. Which is why the question of proper DOM support is
> so important to everyone here.

Exactly right.

A good model for this is the @rel attribute. It exists and validates in
HTML. Browsers pick it up and make it available in the DOM API. That's
it. Meanwhile, Google comes in and says that rel="nofollow" and
rel="canonical" now enable specific behaviors in the Google Search
Engine. Browsers don't need to change accordingly... though they could,
if they wanted to, provide a button in the Chrome to "go to the
canonical version of this page."

Same thing with RDFa attributes, only more expressive than @rel alone.
So, to be extra specific, we would like:

1) the HTML5 language to include RDFa attributes as valid.

2) the browsers to make those attributes available in their DOM APIs,
just like they already do with @rel.

3) enthusiastic user agents to parse the RDFa and make the triples
available via an API of their choice.

If browser vendors want to do (3), that's fantastic, but we're also
perfectly okay with them doing (2) and leaving (3) to extensions,
bookmarklets, or search engines.

> What's the minimimum needed from browser makers before others can do
> innovative things using RDFa triples parsed and consumed within the
> browser environment?

Nothing. What they do now with additional attributes is sufficient. This
is why we keep saying that the required implementation work is minimal.

> What checks can we make to ensure we're making it easier rather than
> harder for browser makers and others working within the browser UI to
> exploit RDFa efficiently?

Good question. I think it might be worth turning the RDFa JavaScript
parsing code into a "RDFa implementation evaluator" that checks to see
how easy it is to get at the RDFa. It currently is quite easy, and
hopefully it would stay that way in HTML5.

> Is there anything beyond "can parse the current document into triples
> from Javascript" that is necessary or very very useful for RDFa, in the
> browser environment? Any aspects that relate directly to user
> experience, such as speed of parsing, or consistency of behaviour after
> DOM updates?

If a browser vendor wants to be forward-looking and implement a native
RDFa parser (say, by including Fuzzbot) with incremental parsing based
on dynamic DOM updates, that would be fantastic. But it's not required,
and not something I would recommend putting in the HTML5 spec.

> Can the advanced facilities in HTML5 (eg. SQL persistence) be usefully
> combined with RDFa usage scenarios. For example, can we load/store/cache
> parsed RDFS/OWL schemas within the browser? Can we use the browser's
> crypto APIs to check the schema hasn't been maliciously interfered with?
> Can we serialize the in-page RDFa triples into the browser's SQL store
> and perform SPARQL queries on it (i) within the SQL environment through
> query rewriting (ii) using in-memory .js SPARQL implementations...

I would put this in the (3) enthusiastic category. I agree that there's
much promise in combining the existing HTML5 improvements with what RDFa
can provide.

-Ben

Received on Tuesday, 17 February 2009 17:02:47 UTC