RDFa API for browsers

These are snippets from an off-line conversation about RDFa APIs that
really should have been a public discussion. Moving the relevant bits to
 a public discussion thread so that the community can continue the
discussion.

The conversation started when I pointed out that we might want to start
focusing on an RDFa API for Javascript running in browsers since Mozilla
seems to be open to implementing the Microdata API[3]. We had not
specified anything previously because we didn't want RDFa to be an
implementation burden on browser vendors. Now that it seems it is not,
we should create an API so that Javascript running in any browser could
access triples expressed in pages with ease.

Ivan Herman wrote:
> (I cc this mail to Thomas Roessler, the domain lead of T&S, ie, the
> replacement of Ralph, and with whom we had a bunch of discussions on the
> subject. I also cc this to James Hollenbach, for reasons to be clearer
> below...)
> 
> I try to collect some random thoughts...
> 
> - as you know, we have been discussing the issue of an RDF(a) API for a
> few weeks now. Actually, a group at MIT (a bunch of PhD students,
> working with Tim, plus Eric Prud'hommeaux) have thought of collecting
> what API-s are out there for RDF and RDFa in Javascript. Mark and Ben
> have both promised to write down what they have...
> 
> James Hollenbach is the students at MIT who was involved with the recent
> discussions around the subject. The pointer he gave me is [1,2] but,
> unfortunately, I did not have the opportunity to dig into it yet...
> 
> James, is there anything more you can tell us about where you are with this?
> 
> Based on all these it should be possible to write down a strawman
> proposal quickly. I would try to do something very simple, at least for
> a start.
> 
> - it is an open issue for me whether it should be and RDFa API or an RDF
> API. From an RDF user's perspective there is little difference between
> and RDF data extracted from RDFa or, say, via a GET call to a SPARQL
> engine somewhere on the Web returning a graph. On the other hand, I see
> some application examples for RDFa specific things. This complicates
> things a bit, technically. James, again, I am not sure where exactly
> your package stands in this sense.
> 
> - if there is an RDFa API defined, what are the guarantees that the browser
> developers would implement it?

--------------------------------------------------------------------------
Thomas Roessler wrote:
> On 18 Oct 2009, at 17:40, Ivan Herman wrote:
>> - as you know, we have been discussing the issue of an RDF(a) API for a
>> few weeks now. Actually, a group at MIT (a bunch of PhD students,
>> working with Tim, plus Eric Prud'hommeaux) have thought of collecting
>> what API-s are out there for RDF and RDFa in Javascript. Mark and Ben
>> have both promised to write down what they have...
>>
>> James Hollenbach is the students at MIT who was involved with the recent
>> discussions around the subject. The pointer he gave me is [1,2] but,
>> unfortunately, I did not have the opportunity to dig into it yet...
>>
>> James, is there anything more you can tell us about where you are with this?
>>
>> Based on all these it should be possible to write down a strawman
>> proposal quickly. I would try to do something very simple, at least for
>> a start.
> 
> +1 to "quickly".  I'd really like to see a strawman hit the world within the next very few weeks -- frankly, the ideal scenario would be a strawman before TPAC and a lightning talk by Manu. :)
> 
>>
>> - it is an open issue for me whether it should be and RDFa API or an RDF
>> API. From an RDF user's perspective there is little difference between
>> and RDF data extracted from RDFa or, say, via a GET call to a SPARQL
>> engine somewhere on the Web returning a graph. On the other hand, I see
>> some application examples for RDFa specific things. This complicates
>> things a bit, technically. James, again, I am not sure where exactly
>> your package stands in this sense.
> 
> I think it needs to be an RDFa API.
> 
> When I say that, what I have in mind is that RDFa is woven into the HTML DOM.  RDFa is *not* just a way to deliver some RDF data within an HTML document: It's a way to show how the structure of the HTML and the structure of the RDF data are connected.  Therefore, the API that I'd like to see is one where you can go back and forth between the RDF and the DOM.
> 
> Thinking about this on a different level, microformats and microdata are ways to let data travel within the mark-up in a way that's easily discovered and procesed by both the web application itself (i.e., they are competing with that nasty JavaScript array that's sourced in somewhere), and by some external user -- think "search engine", think Operator plugin.  What RDFa adds is a connection to the data cloud, i.e., the ability to aggregate those data on a large scale, with (possibly) custom vocabularies, and without clashes.  What I suspect RDFa needs for deployment in this environment is the ability to compete with microformats and microdata as a data format that can be used for a web application's own purposes.
> 
>> - if there is an RDFa API defined, what are the guarantees that Firefox
>> would implement it? If Jonas (and the FF folks in general) were against
>> it so far, I am not sure that would change. Whom would you talk to at
>> Mozilla and co?
> 
> 1. spec
> 2. JavaScript library
> 3. Firefox plugin
> 
> Plugins don't need to come from browser vendors, but can be written by outside parties.  If the API is good enough and the plugin well-implemented enough, and enough buzz and momentum is built, then we might have some chance to see deployment. 

-------------------------------------------------------------------------------

Mark Birbeck wrote:
> A few things in no particular order.
> 
> 
> THE NEED FOR AN API
> 
> I agree that there is a need for an API. If we come up with a good
> API, it's far more important that it's implemented in the various Ajax
> libraries than that it gets implemented natively. Browser
> implementation would be a nice bonus.
> 
> GENERAL-PURPOSE RDF API V. JAVASCRIPT API
> 
> Although I like Ivan's idea of a general-purpose RDF API, which would
> include a JavaScript version, I think JavaScript is special enough to
> warrant its own kind of API -- for two reasons.
> 
> First, I think the kinds of interfaces we'll want are more fine-tuned
> than simply querying. For example, if I find an element that contains
> a subject, I should be able to obtain its predicates directly via an
> interface, without having to query across the whole triple store. This
> would hopefully make it easier for authors not aware of RDF to still
> get some value; for example, they could easily obtain values like a
> longitude and latitude from an element indicating an address, without
> having it express a full query.
> 
> The same interface would of course allow us to run queries too, and
> since the same interface could also exist on the document object, then
> authors could run queries across the entire triple store -- perhaps
> something like:
> 
>   document.meta.query( ... );
> 
> But this brings me to the second reason I think a DOM/JS API should be
> 'special'. JS is flexible enough that the result of a query could
> easily be an array of objects, each with properties that are the same
> name as the predicate, and with a value that is the value of the
> object:
> 
>   var ar = document.meta.query( ... );
> 
>   alert("Name: " + ar[0].creator);
> 
> It's essentially dynamic object creation, rather than 'querying' in
> the traditional sense, and really plays to JavaScript's strengths.
> 
> PRODUCING A DRAFT
> 
> In terms of speed, I think we could write a draft very quickly. I have
> no idea how people want to play this, but speaking for myself, I know
> that if I had some help (Shane? :)) then I could knock a first cut out
> pretty quickly.
> 
> Obviously I realise it would be subject to all the usual discussions,
> and not be set in stone, but the reason I'm confident I could do
> something fast is because this is exactly what I've been working on
> for a couple of years now. (Along with seeing how feasible it is to
> use things like Fresnel, but that's another story.)
> 
> Anyway, lots to talk about, and I'm all for moving forwards on this.
> 
> What do people think?

------------------------------------------------------------------------

Ben Adida wrote:
> Just a few points:
> 
> - absolutely this needs to be RDF*a* based, not just RDF. If it's SPARQL
> against the whole page, then there is zero advantage to RDFa vs <link
> rel>. You want to be able to do:
> 
> (a) what DOM element is the user pointing to?
> (b) what RDF triples pertains to this DOM element?
> 
> You need the visual/structured correspondence. That's why those RDFa
> design principles, the ones I keep hammering during every talk, matter!
> 
> - Having a proposal out there that someone can implement as a jQuery
> plugin, that's enough to get the discussion going.

-------------------------------------------------------------------------

-- manu

[1] http://code.google.com/p/rdfquery/
[2] http://code.google.com/p/rdfquery/wiki/RdfPlugin
[3] http://lists.w3.org/Archives/Public/public-html/2009Oct/0562.html

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Establishing an Open Digital Media Commerce Standard
http://blog.digitalbazaar.com/2009/09/28/a-digital-content-commerce-standard/

Received on Wednesday, 21 October 2009 03:57:40 UTC