Re: Javascript Stub of the RDFa DOM API 1.1

On 04/13/2010 07:50 AM, Benjamin Adrian wrote:
> In a great Skype call yesterday with Manu, we simplified the RDFa DOM
> API a lot.
> We also tried to regard Javascript language features in order to let the
> RDFa DOM API
> be implemented in a good Javascript style. (as mark demanded).

Indeed, it was a very productive phone call and the attached Javascript
file does a great job of summarizing the changes that we discussed.
Nicely done, Benjamin!

We focused on making the code as natural and compact as possible for
languages like Javascript, Python, Ruby and Perl. Effort was put into
simplifying the object model to only include the instance-able types of RDF:

URI, BlankNode, TypedLiteral, and PlainLiteral

We also focused on ensuring that languages that support automatic
casting, like Javascript, could auto-cast TypedLiterals naturally. So,
if you had this:

<#person>
   measure:weight_in_kg
      "65"^^xsd:float

that value could be retrieved into an array [subj, pred, obj], and you
could do this:

var moreWeight = 10.0 + obj;
// moreWeight would equal 75.0 (typed to float)

We also focused on using the natural looping constructs, so one could do
things like this:

// iterate through all triples with subject "http://example.org/#me"
for each [subj, pred, obj] in rdfa.filter("http://example.org/#me")
{
   // do something
}

or one could even use list comprehensions in Javascript 1.7:

// get all plain literals for #me subject
var plainTriples =
   [x for ( [subj, pred, obj] in rdfa.filter("http://example.org/#me")
            if obj instanceof PlainLiteral ) ];

and support low-memory iteration:

// iterate over all items that have an "rdfs:label" predicate
var ti = rdfa.iterate(null, RDFS["label"]);
while(var t = ti.next())
{
   // do something with t
}

> Nevertheless we payed attention to not outspace languages like Java.

Right - while the syntactic sugar of Javascript/Python/etc is nice, a
design goal is to support languages like Java that don't have some of
the nicer scripting features that Javascript has (like aggressive
automatic type casting).

So, one can still do this:

<#person>
   measure:weight_in_kg
      "65"^^xsd:float

We may encapsulate the RDFTriple object in a typed object "triple"
PlainLiteral weight = triple.obj;
String weightInString = weight.toString();

> In order to let us feel the Javascript Outcome, I tried to implement
> it in Javascript and used mock-ups where ever the code has really to
> parse RDFa and DOM data.
> It is documented and should be understandable for non-Javascript
> developers.
> The attached JS file runs on the latest RHINO and SpiderMonkey JS
> interpreter.

Great idea! It's a very good idea to do the design work like this. It
proves that the API works in a modern Javascript interpreters.

> In the playground section you can try out the API.
> I hope this will give you the chance to play with it and better discuss
> or try possible alternatives and
> changes.

Some suggestions/changes:

* I don't think that toString() should return TURTLE representation. I
think it should return a plain string for URIs, TypedLiterals, and
PlainLiterals with a language element. We want to make sure that
re-using the subject/predicate/object is as easy as possible in
Javascript. If we output in TURTLE format, the developer may need to
strip the TURTLE representation from the string value... which would be
annoying.

* We need to simplify the filter() examples to demonstrate some of the
simpler goals of the API, such as 1) filtering on subject, 2) filtering
on predicate, 3) filtering on object, 4) using a very simple filter
function... and then go into some of the more complex examples.

This is a step in the right direction... Looking at the code, I think we
can simplify the API even more... I'll try to mock something up after
the call on Thursday.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarming Goes Open Source
http://blog.digitalbazaar.com/2010/02/01/bitmunk-payswarming/

Received on Tuesday, 13 April 2010 13:13:53 UTC