Re: RDFa API for browsers

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@tobyinkster.co.uk>
<http://tobyinkster.co.uk>

Received on Wednesday, 21 October 2009 10:43:48 UTC