RDFa API for browsers

[Manu Sporny]

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/

[Toby Inkster-4]

On Tue, 2009-10-20 at 23:57 -0400, Manu Sporny wrote:
> 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].

Just some ideas...

// Query the union of all data found on the page:
var r = document.meta().query('SELECT ?foo WHERE ...');

// Just query the data found in RDFa:
var r = document.meta('rdfa').query('SELECT ?foo WHERE ...');
for (var i in r)
{
  // r[i].foo typeof 'RDFNode'.
  if (r[i].foo.type == 'literal')
    window.alert(r[i].foo.datatype);
}

// Get the RDFa data as a RDF/JSON-like object:
var data = document.meta('rdfa').data;

// Get the RDFa data as an array of triples:
var triples = document.meta('rdfa').triples;
for (var i in triples)
{
  // each triple has subject, object, predicate and graph properties
  var g = triples[i].graph; // named graph URI
  var s = triples[i].subject;

  // RDFNode.token returns a Turtle-like token
  // (i.e. URIs in <>, literals in "", bnodes start _:).
  if (s.type != 'bnode')
    window.alert(s.token);
}

// Can also grab data from Microdata and GRDDL if the browser
// supports those.
var data = document.meta('grddl').data;
var r = document.meta('items').query('SELECT ?foo WHERE ...');

--
Toby A Inkster
<mailto:mail@...>
<http://tobyinkster.co.uk>

[Mark Birbeck-4]

Hi Toby,

On Wed, Oct 21, 2009 at 9:48 AM, Toby Inkster <tai@...> wrote:

> On Tue, 2009-10-20 at 23:57 -0400, Manu Sporny wrote:
>> 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].
>
> Just some ideas...
>
> // Query the union of all data found on the page:
> var r = document.meta().query('SELECT ?foo WHERE ...');
>
> // Just query the data found in RDFa:
> var r = document.meta('rdfa').query('SELECT ?foo WHERE ...');

This is interesting...why would you prefer to keep the triples from
different formats separate?

I'm not saying you shouldn't. :)

It's just that I've always worked on the assumption that everyone
would want all the metadata to be bundled into one common, queryable
location.

There are two other partitioning mechanisms that I've been playing
with. The first is the idea of a store, which seems to be pretty
common to a number of RDF parsers.

If you did want to keep the output of the different syntaxes separate,
then the store could be the unit of partition, retaining 'meta' for
the general interface into this and all future metadata APIs:

  document.meta.store['rdfa'].query( ... );
  document.meta.store['microformats'].query( ... );

I.e., this is almost exactly the same as your syntax, but the
partitioning is pushed down one level. This is probably slightly
easier to implement, too, since the first thing a parser will do is to
create its own store:

  document.meta.store["rdfa"] = document.meta.createStore();


The second unit of partition I've been looking at is of course the named graph.

This is quite handy, because it means that you can manage groups of
triples separately, but still query across all of them if you want.

At the moment I've been playing with named graphs within a store, but
we might consider making a store a referenceable named graph, too:

  document.meta.store['http://www.w3.org/1999/xhtml/vocab#rdfa'].add( ... );
  document.meta.store['http://www.w3.org/1999/xhtml/vocab#microformats'].add(
... );
  document.meta.query( 'SELECT ?foo FROM
http://www.w3.org/1999/xhtml/vocab#rdfa ...' );

Or alternatively, we could use the first technique:

  document.meta.store['rdfa'].add( ... );
  document.meta.store['microformats'].add( ... );

but then say that you can either query each individual store:

  document.meta.store['rdfa'].query( ... );
  document.meta.store['microformats'].query( ... );

or you can have your query passed to each store, and the result is the
union of the queries:

  document.meta.query( );

A general rule I think we should follow is that from a JS programmers
perspective, the default behaviour is that there is one store,
containing all of the metadata derived from the page. The fact that it
came via RDFa or uF is not important. If it is important for them,
then they can query the corresponding store directly.


> for (var i in r)
> {
>  // r[i].foo typeof 'RDFNode'.
>  if (r[i].foo.type == 'literal')
>    window.alert(r[i].foo.datatype);
> }

My preference here is for the default mode to be JSON objects. If you
look at it from the point of view of a JS programmer, then a query is
essentially a request to construct an array of JSON objects, that are
based on a certain template.

For example, a query for "?name" is really a request to create an
array of objects, each with the single property "name":

  [
    {
      name: "Toby Inkster"
    },
    {
      name: "Manu Sporny"
    }
  ]

There's no need for our JavaScript authors to be testing types, etc.
-- they should get back an immediately usable set of objects.

I know people are going to say "what about the difference between URIs
and literals?", "what about data types?"...and so on.

Yes..of course, we'll need to take all of those things into account. :)

But my argument is that we don't want to begin with a design model
that creates an API that looks no different to one that we would
create in Java or C, or that simply mimic triples in a data structure.
I think we should be creating a set of interfaces that take advantage
of JavaScript as a language, and therefore one that feels natural to
JS programmers.

For example, in my library I have a backward-chaining feature, that
from a JavaScript perspective simply adds properties to an object, if
they are missing. It's for handling the usual "if engine = true and
wheels = 4 then type = car" kind of examples -- but it's a very
powerful technique for programmers, and works really nicely if you do
it at the JS level rather than merely at the triple level.

Anyway, this part of the discussion -- the triple to/from JSON mapping
-- is worthy of a separate thread, I think.

> // Get the RDFa data as a RDF/JSON-like object:
> var data = document.meta('rdfa').data;
>
> // Get the RDFa data as an array of triples:
> var triples = document.meta('rdfa').triples;
> for (var i in triples)
> {
>  // each triple has subject, object, predicate and graph properties
>  var g = triples[i].graph; // named graph URI
>  var s = triples[i].subject;

Or we could just use query() as the interface mechanism, and specify
the output format we want:

  document.meta.store["rdfa"].query("SELECT ?foo ...", "raw");
  document.meta.store["rdfa"].query("SELECT ?foo ...", "JSON");
  etc.

It would be good to make the default values those that JS programmers
would expect, so that again, any idea of triples, etc., is hidden from
them. We could say that


>  // RDFNode.token returns a Turtle-like token
>  // (i.e. URIs in <>, literals in "", bnodes start _:).
>  if (s.type != 'bnode')
>    window.alert(s.token);
> }

This is how I've done things by default in my library. I think this is
better than having extra properties for types, since the most common
type for a JS programmer will be the plain string. However, the twist
in my library is that if the data is of a type that JS supports, then
it gets converted on output. For example:

  [
    {
      name: "Toby Inkster",
      foo: 17
    },
    {
      name: "Manu Sporny",
      bar: 93.25,
      action: function () {
        ...
      }
    }
  ]

As you can see, the principle is always to make the object feel
'natural' to a JS programmer, and in a sense to conceal its RDF
origins.


> // Can also grab data from Microdata and GRDDL if the browser
> // supports those.
> var data = document.meta('grddl').data;
> var r = document.meta('items').query('SELECT ?foo WHERE ...');

Assuming we do decide that we should allow access to the data
separately (and you are probably right here, that we do), then as I
said above, I think an array of stores would be slightly easier to
manipulate:

  var data = document.meta.store['grddl'].data;
  var r = document.meta.store['items'].query('SELECT ?foo WHERE ...');

Great thoughts though Toby! Hopefully we can keep this moving.

Regards,

Mark

--
Mark Birbeck, webBackplane

mark.birbeck@...

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

[Toby Inkster-4]

On Wed, 2009-10-21 at 11:12 +0100, Mark Birbeck wrote:

> This is interesting...why would you prefer to keep the triples from
> different formats separate?
>
> I'm not saying you shouldn't. :)

It might speed up practical implementations. If you only use RDFa on
your page, then calling:

        document.meta('RDFa').whatever();

means that the browser doesn't need to waste its time checking all the
page's profile URIs (if any are given) for GRDDL profileTransformations,
and namespace declarations (which will almost certainly be given on any
page that uses RDFa) for GRDDL namespaceTransformations.

Also, if different browsers support different serialisations (e.g. RDFa,
GRDDL, Microdata, eRDF, etc), testing whether document.meta('RDFa') is
empty might be a useful tool.

> It's just that I've always worked on the assumption that everyone
> would want all the metadata to be bundled into one common, queryable
> location.

I imagine that most people would, yes. That's why I showed meta() with
no parameters to return the union graph.

> > for (var i in r)
> > {
> >  // r[i].foo typeof 'RDFNode'.
> >  if (r[i].foo.type == 'literal')
> >    window.alert(r[i].foo.datatype);
> > }
>
> My preference here is for the default mode to be JSON objects. If you
> look at it from the point of view of a JS programmer, then a query is
> essentially a request to construct an array of JSON objects, that are
> based on a certain template.
>
> For example, a query for "?name" is really a request to create an
> array of objects, each with the single property "name":
>
>   [
>     {
>       name: "Toby Inkster"
>     },
>     {
>       name: "Manu Sporny"
>     }
>   ]

This is essentially the same as what I'm suggesting, but they'd get
back:

[
  {
    "name": {
      "value" : "Toby Inkster" ,
      "type"  : "literal" ,
      "lang"  : "en"
    }
  } ,
  {
    "name": {
      "value" : "Manu Sporny" ,
      "type"  : "literal" ,
      "lang"  : "en"
    }
  }
]

This is pretty similar to the SPARQL Results JSON serialisation
<http://www.w3.org/TR/rdf-sparql-json-res/> and RDF/JSON
<http://n2.talis.com/wiki/RDF_JSON_Specification>, both of which are
pretty widely implemented and supported.

The main difference would be that these objects like {
      "value" : "Manu Sporny" ,
      "type"  : "literal" ,
      "lang"  : "en"
} would also have some object methods defined, such as ".token()" which
outputs a Turtle-compatible token.

> There's no need for our JavaScript authors to be testing types, etc.
> -- they should get back an immediately usable set of objects.
>
> I know people are going to say "what about the difference between URIs
> and literals?", "what about data types?"...and so on.

If people care about whether things are URIs or literals, and what
datatype has been used, and the language, then they can look
at .type, .datatype and .lang. If they don't care, they can just look
at .value and ignore the rest.

> For example:
>
>   [
>     {
>       name: "Toby Inkster",
>       foo: 17
>     },
>     {
>       name: "Manu Sporny",
>       bar: 93.25,
>       action: function () {
>         ...
>       }
>     }
>   ]
>
> As you can see, the principle is always to make the object feel
> 'natural' to a JS programmer, and in a sense to conceal its RDF
> origins.

I can see the value in "flattening" the structure, so that {
  "value" : "foo" ,
  "type"  : "blah"
} just becomes a simple string "foo", but the problem is that it's
impossible to go the other way - to get back to the unflattened
structure reliably.

If the outer array was replaced by an iterator object that could act
like an array but have methods, then your flattened structure could be
returned using:

var r = document.meta.query('...').simple();

I wonder how much of this could be prototyped in a Javascript library
before browser pick it up? (And to allow scripts using document.meta to
function in older browsers.) Probably quite a lot. GRDDL might be
difficult because of cross-site requests.

--
Toby A Inkster
<mailto:mail@...>
<http://tobyinkster.co.uk>

[Mark Birbeck-4]

Hi Toby,

On Wed, Oct 21, 2009 at 11:43 AM, Toby Inkster <tai@...> wrote:

> On Wed, 2009-10-21 at 11:12 +0100, Mark Birbeck wrote:
>
>> This is interesting...why would you prefer to keep the triples from
>> different formats separate?
>>
>> I'm not saying you shouldn't. :)
>
> It might speed up practical implementations. If you only use RDFa on
> your page, then calling:
>
>        document.meta('RDFa').whatever();
>
> means that the browser doesn't need to waste its time checking all the
> page's profile URIs (if any are given) for GRDDL profileTransformations,
> and namespace declarations (which will almost certainly be given on any
> page that uses RDFa) for GRDDL namespaceTransformations.

Ah, I see.

I was imagining a different model. You have one or more parsers, that
run after page load. Each parser is independent, but places its data
into a common location. As a programmer using a library, you don't
need to know whether there is one parser or five running against the
page.

In that scenario, the only issue is whether to put the data into one
location, or multiple ones. I don't have a problem with having
multiple stores, though.


> Also, if different browsers support different serialisations (e.g. RDFa,
> GRDDL, Microdata, eRDF, etc), testing whether document.meta('RDFa') is
> empty might be a useful tool.

I think we should work towards a standard interface for metadata,
regardless of how the data was originally obtained. So I feel that:

  document.meta

should provide the basic 'entry point' and then from that, we have one
or more stores. Anything can create a store, including the programmers
themselves, although a store will most likely be created by a
processor for one of the formats that you mentioned.

Obviously, if you can think of any interfaces that would be specific
to a format, then they could be placed on format-specific objects, but
I think it best to avoid going that route if we can, and just have a
set of common interfaces on the store object.


>> It's just that I've always worked on the assumption that everyone
>> would want all the metadata to be bundled into one common, queryable
>> location.
>
> I imagine that most people would, yes. That's why I showed meta() with
> no parameters to return the union graph.

Sure.

>> > for (var i in r)
>> > {
>> >  // r[i].foo typeof 'RDFNode'.
>> >  if (r[i].foo.type == 'literal')
>> >    window.alert(r[i].foo.datatype);
>> > }
>>
>> My preference here is for the default mode to be JSON objects. If you
>> look at it from the point of view of a JS programmer, then a query is
>> essentially a request to construct an array of JSON objects, that are
>> based on a certain template.
>>
>> For example, a query for "?name" is really a request to create an
>> array of objects, each with the single property "name":
>>
>>   [
>>     {
>>       name: "Toby Inkster"
>>     },
>>     {
>>       name: "Manu Sporny"
>>     }
>>   ]
>
> This is essentially the same as what I'm suggesting, but they'd get
> back:
>
> [
>  {
>    "name": {
>      "value" : "Toby Inkster" ,
>      "type"  : "literal" ,
>      "lang"  : "en"
>    }
>  } ,
>  {
>     "name": {
>      "value" : "Manu Sporny" ,
>      "type"  : "literal" ,
>      "lang"  : "en"
>    }
>  }
> ]

But that's not the same. :)

I'm suggesting that we put JavaScript features to the fore, not simply
use it to mirror triples.


> This is pretty similar to the SPARQL Results JSON serialisation
> <http://www.w3.org/TR/rdf-sparql-json-res/> and RDF/JSON
> <http://n2.talis.com/wiki/RDF_JSON_Specification>, both of which are
> pretty widely implemented and supported.

Techniques such as RDF/JSON use JS simply as a serialisation mechanism
for triples, whilst what I'm proposing is the creation of 'semantic
JavaScript'.

I'm not suggesting that we get all of this 'semantic JS' in one go --
but I'd like to see us put the foundations in place.


> The main difference would be that these objects like {
>       "value" : "Manu Sporny" ,
>      "type"  : "literal" ,
>      "lang"  : "en"
> } would also have some object methods defined, such as ".token()" which
> outputs a Turtle-compatible token.

My approach is almost completely the other way around.

Why do we need these 'exploded' objects? What we're doing here is
ignoring the objects that are provided to us in the language (strings,
integers, dates, etc.), and replacing them with RDF objects. That's
not something JS programmers will thank us for. :)

If we have an integer, then why not just make it an integer? Same for
floats, functions, and so on.

True, the difference between a literal and a URI is more subtle, but
here we simply add some helper methods to take a string containing "<"
and ">", and convert it to a URI. (In other words, where you have a
function to go from exploded object to a turtle string, I'm using
strings by default, and providing functions to convert URIs.)

>> There's no need for our JavaScript authors to be testing types, etc.
>> -- they should get back an immediately usable set of objects.
>>
>> I know people are going to say "what about the difference between URIs
>> and literals?", "what about data types?"...and so on.
>
> If people care about whether things are URIs or literals, and what
> datatype has been used, and the language, then they can look
> at .type, .datatype and .lang. If they don't care, they can just look
> at .value and ignore the rest.

Exactly. So why not go the further step and use native JS objects,
rather than everything the programmer writes having to have '.value'
on it?

>> For example:
>>
>>   [
>>     {
>>       name: "Toby Inkster",
>>       foo: 17
>>     },
>>     {
>>       name: "Manu Sporny",
>>       bar: 93.25,
>>       action: function () {
>>         ...
>>       }
>>     }
>>   ]
>>
>> As you can see, the principle is always to make the object feel
>> 'natural' to a JS programmer, and in a sense to conceal its RDF
>> origins.
>
> I can see the value in "flattening" the structure, so that {
>  "value" : "foo" ,
>  "type"  : "blah"
> } just becomes a simple string "foo", but the problem is that it's
> impossible to go the other way - to get back to the unflattened
> structure reliably.

It's not impossible, but yes, there are issues.

But before we go any further with that, we'd need to define the
use-cases for going the other way; we don't want to make this more
complicated for programmers, because we want to allow for something
that never happens.

In the main I see the results of a query as being something that
programmers then work with, but not necessarily put back into the
triple store. However, longer term I do have an idea that there would
be 'live' JS objects, which when updated cause the triple store to
also be updated, but I think that's probably too ambitious for now.

As it happens, in my parser I do allow JSON objects to be imported
into the triple store, and I think it's reasonable to map JSON
integers to XSD integers, etc.

Are there other scenarios that you are thinking of?


> If the outer array was replaced by an iterator object that could act
> like an array but have methods...

Right. In fact I see this containing object as having a number of
other properties that would help when processing the data. For
example, it could contain a base URL, against which all URLs within
the data objects are relative. It might also contain prefix mappings,
so that CURIEs could be used within URIs as well. That kind of thing.


> ... then your flattened structure could be
> returned using:
>
> var r = document.meta.query('...').simple();

That's possible, although I would still prefer my 'JS-native' format
to be the default, because I think we should aim to make the default
functionality as 'natural' as possible for JS programmers.


> I wonder how much of this could be prototyped in a Javascript library
> before browser pick it up? (And to allow scripts using document.meta to
> function in older browsers.) Probably quite a lot. GRDDL might be
> difficult because of cross-site requests.

Most of what I've described here is in my Ubiquity RDFa parser [1]; it
uses document.meta, but there is only one store for the triples:

  document.meta.store.query( );

However, it wouldn't take much to expose it using the technique we've discussed:

  document.meta.store["rdfa"].query( );

and start to make it play nicely with other parsers.

The library is currently going through a revamp (being merged with my
other JS libraries, such as XForms, notifications, and SMIL), and a
rename -- which is why I haven't mentioned it a great deal yet.

But I'm working on it now, to get it into a position where some of
these ideas can be tested out.

Regards,

Mark

[1] <http://ubiquity-rdfa.googlecode.com/>

--
Mark Birbeck, webBackplane

mark.birbeck@...

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)