Re: RDFa Lite API (JavaScript)

Hi Karl,

On Mon, Dec 10, 2012 at 11:09 PM, Karl Dubost <karld@opera.com> wrote:
> Niklas,
>
> thanks for your answer,
> PS: you could have replied with cc:public-rdfa-wg, I have no issues.

Right. :) I realized CC:ing the community list is probably better
though; and also Nathan, Alex and Dan, who I know have an interest in
this. Pardon me if this reply is a bit dense, but I want to cover a
bunch of perspectives.

(For context: my reply to Karl was about the current state of RDFa
data access using JS in the browser. I've referenced Green Turtle [1],
and my own RDFa Lab work [2].)

It should be noted that the RDFa WG is not chartered to develop an API
at this point. But many members have a great interest in the questions
about RDFa/RDF web app APIs.

> Le 11 déc. 2012 à 03:45, Niklas Lindström a écrit :
>> One of them
>> is to make it clear what parts are RDFa Lite and what are the advanced
>> features, but that's currently not made explicit.
>
> To speed up adoption, maybe an RDFa lite JS library would go faster. The main requirement would be to be VERY LIGHT. And it might be possible to do a shim on top of the microdata API to minimize the effort.
>
> See http://dev.opera.com/articles/view/microdata-and-the-microdata-dom-api/
> and http://www.w3.org/html/wg/drafts/microdata/master/Overview.html#microdata-dom-api

Yes, I've studied the microdata API, but since it hinges on only types
having URIs, I think a direct port will be tricky and/or misleading.
(And remember that RDFa Lite also supports prefixes for mixing
vocabularies.) Using a default vocabulary is of course quite feasible.
This is present in both examples I link to below.

As for implementation, I strive for a concise and small code base,
while still supporting all of RDFa. There are many different uses of
RDFa, and I want to support things scoped outside of Lite. Some of the
uses have become legacy patterns, and may be optimized away in the
future. But others are very useful for certain applications, so I
don't want to lose that. My implementation covers basically everything
(as does Alex's), so that part's already done.

But the question at hand is about how to expose this in as simple an
API and/or data as possible. I.e. how to make this palatable for use
by web developers with various backgrounds and time at hand.

> In the example I gave in
> http://lists.w3.org/Archives/Public/semantic-web/2012Dec/0012.html
>
> The piece of code for microdata would be this
>
>     <ul>
>         <li itemscope itemtype="http://schema.org/Place">
>             <span itemprop="name">Tsujido</span>
>             <div itemprop="geo"
>                  itemscope
>                  itemtype="http://schema.org/GeoCoordinates">
>                  <meta itemprop="latitude" content="35.336833"/>
>                  <meta itemprop="longitude" content="139.447083"/>
>                  </div>
>             </li>
>         <li itemscope itemtype="http://schema.org/Place">
>             <span itemprop="name">Meguro</span>
>             <div itemprop="geo"
>                  itemscope
>                  itemtype="http://schema.org/GeoCoordinates">
>                  <meta itemprop="latitude" content="35.633983"/>
>                  <meta itemprop="longitude" content="139.71600"/>
>                  </div>
>             </li>
>     </ul>
>
> with
>
>     var places = document.getItems('http://schema.org/Place');
>     for (var i = places.length - 1; i >= 0; i--) {
>        longitude = places[i].properties['geo'][0].properties['longitude'][0].itemValue;
>        console.log(longitude);
>     };

I used your example for a simple demo of the state of my API
experiments in the RDFa Lab. You can see that in action here:

    http://niklasl.github.com/rdfa-lab/examples/rdfa-api-comparisons.html

At this point, everything there uses the expanded, flat JSON-LD
produced by my extractor under the hood. Then the first example
compacts it (using the JSON-LD by Digital Bazaar [3]). The second
loads it into a Graph API implementation from my "lab", which is my
contribution/alternative to the discussion of what such an API should
look like and provide.

The compact JSON-LD example uses an experimental "connect" feature of
JSON-LD (with a spec under development at [4]). This glues together
JSON-LD data (even compacted) so that a graph is formed from the tree,
and also indexes each node by IRI and type (by the compact name
thereof). This basic pattern scales up to virtually any common use of
RDF (in code and templates) where the input form is generally known.

And for the other situations, where a graph needs to be navigated and
where types, properties, datatypes and languages vary unpredictably, a
full Graph API should provide an isomorphic but more explicit
IRI-centric access method (including CURIEs and a form of SPARQL
property paths).

(I also include the notion of inverses in both approaches, so that the
arcs can be traversed in both directions. From my experience, this
feature may be overlooked or considered advanced, but is often quite
crucial (in traversal from person to workplace to homepage and back,
in getting from a topic to the documents relating to it, etc.).)

So, how does this relate to lightweight and simple? Well, it depends,
of course. My firm belief is that a good design makes the simple
things simple, but does not exclude anything advanced (such as
inverses, or the interconnection of nodes in a graph, or the rich and
quite varied shapes of data in the wild). But we need to collect more
feedback, opinions and requirements regarding these example designs.

I have currently left out the work I've done for a live DOM-based API
[5] from this example (since it needs to be condensed). That is a bit
more directly related to the microdata API though, which passes the
actual elements in the page around, instead of extracted data. If
direct data access using that is needed, it could be done via the
Graph API (which I intend to work on). But that depends on which form
of access is desired. I have an inkling that these needs not
necessarily overlap. I.e. compact JSON is for picking out the data;
graph navigation backed by a live RDFa-lens of the DOM is another
story. That's an open question of course, and a wise design might
support both at different layers.

Best regards,
Niklas

[1]: http://code.google.com/p/green-turtle/
[2]: https://github.com/niklasl/rdfa-lab
[3]: https://github.com/digitalbazaar/jsonld.js
[4]: http://json-ld.org/spec/latest/json-ld-connect/
[5]: https://github.com/niklasl/rdfa-lab/wiki/RDFa-DOM-API


> --
> Karl Dubost - http://dev.opera.com/
> Developer Relations, Opera Software
>

Received on Wednesday, 12 December 2012 00:42:11 UTC