Re: RDFa and Web Directions North 2009

On Tue, 17 Feb 2009, Dan Brickley wrote:
> On 17/2/09 07:47, Ian Hickson wrote:
> > On Fri, 13 Feb 2009, Ben Adida wrote:
> > > [...] we're not asking browsers to implement any specific features 
> > > other than make those attributes officially available in the DOM.
> > 
> > You presumably do want some user agents some where at some time to do 
> > something with these triples, otherwise what's the point? Whether this 
> > is through extensions, or through browsers in ten years when the state 
> > of the art is at the point where something useful can be done with any 
> > RDFa, or through search engines processing RDFa data, there has to be 
> > _some_ user agent somewhere that uses this data, otherwise what's the 
> > point?
> 
> Ben is saying that we are not asking _browsers_ to do anything beyond 
> expose the data. Ian reponds by talking about various ways in which 
> different kinds of user agent (including eg search engines) might 
> eventually use RDFa.

Yes. Specifically regarding browsers: I don't understand the relevance of 
browsers specifically here. Implementation cost is borne by every 
implementor; browser vendors aren't alone here.


> Of course, Ben and other RDFa enthusiasts would be delighted if browsers 
> did innately start doing interesting things with this RDFa-encoded data.

Well if we want _browsers_ specifically to implement this, then we should 
consider that use case and make sure that we satisfy the requirements of 
browsers. If we don't, then we shouldn't. However, it is critical that we 
not make the mistake of assuming that we don't want browsers to do 
anything, not consider their requirements, and then later turn around and 
say that we do want browsers to implement something. If browsers are to 
implement something, then they must be considered from the start.

(In particular, one requirement browser vendors would likely have is the 
requirement that there be only one processing model irrespective of 
syntax, also known as the "DOM Consistency" principle; Henri recently 
discussed this on this thread. We would have to contact browser vendors 
and get their input to find out what other requirements they might have.)

The RDFa community should decide whether or not browser involvement is 
ever going to be desired. I have often heard conflicting statements here 
from proponents of RDF and RDFa, on the one hand that the idea is to make 
browsers more usable, and on the other that there is no cost to browser 
vendors. Both can't be true.


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

Presumably the minimum is nothing, since anything the browser doesn't 
provide can be routed around using server-side shims.


> 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?

I don't understand what you mean by checks.

In any case, I recommend bringing browser vendors into the discussion if 
there is a desire to make things easier for browser vendors.

For what it's worth, I've seen browser vendors care especially about 
performance; I've also seen browser vendors shun prefix-based syntax (such 
as XML namespaces, QNames, or CURIEs), and I've also seen browser vendors 
shun the RDF data model as a whole (e.g. Mozilla moved away from RDF and 
towards a structured SQL database internally). Asking browser vendors 
directly is the only way to get a real answer here.


> 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...

The answers to these questions, phrased as requirement, would be very 
useful input as far as HTML5 goes.


> Ian - can you suggest terminology that will keep these conversations 
> mutually intelligible? Does the term "Web browser" basically cover the 
> HTML5 notion of "interactive user agent" here? And can "non-interactive 
> user agent" cover scenarios like search engines indexing and 
> re-presenting HTML5/RDFa in ways that require nothing beyond basic HTML 
> from user's browsers?

A non-interactive user agents are things like HTML-to-PDF convertors. 
Search engines and other such tools are what I would recommend calling 
"data mining tools".

The definitions of the various HTML5 conformance classes here describe the 
various terms I would recommend using for referring to various kinds of 
user agents:

   http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#conformance-requirements

HTH,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 17 February 2009 10:12:24 UTC