Potentials of the RDFa DOM API

Hi all!

I just came across the RDFa DOM API [1], and am very interested in
giving feedback and cooperate on that.

To give you an idea of where I come from in terms of "design think",
here's a short introduction. (Note that this really has nothing to
with RDFa, but with the API. I apologize if this is considered
off-topic!)

Some years ago I did an "ORM" for RDF in Python [2]. Over time though,
I've found that approach a bit artificial. Also, there are at least
three other similar O/R-implementations in Python alone (e.g. Sparta
and RDFAlchemy), not to mention the various Java approaches. In Oort I
view the mapper classes as queries or "views", as an indication that
these do not define "frames" as in traditional class-based OO, but are
merely bundles of definitions for how to get and set values for RDF
properties for a given resource from a programmatic perspective. (I
also just saw Spira [3], which takes a similar philosophy with the
"open model".)

I've left that mapper as it is, and focused on some other mechanisms
for using RDF programatically. One such thing has been RDF in JSON,
with my take being Gluon [4]. The focus there is on "profiles", which
is very close to (and directly inspired by) the "context" and "token"
approaches taken by others in this field (also similar to the Data
Context of the RDFa DOM API). As I was working on Gluon it became
apparent that this mapping technique is very similar to the "ORM"
approach, but with the crucial difference that it treats the property
as a first class thing, which is what RDF is about after all. (I'm
aware that at least Mark Birbeck has made similar observations in his
work with e.g. RDFj and RDFa 1.1 profiles.)

I've also experimented with "fancier" techniques for building RDF [5].
I subsequently generalized that approach (in Java, for my daytime
work), to provide a more convenient read/write API upon Sesame. This
(the "read" part) turns out to be very close in principle to the RDFa
DOM API. This isn't yet published work, but I put a snapshot of the
(Spock-based Groovy) Spec for it at [6] to give you an idea of how the
API looks right now.

I think that there is a huge potential here in aligning all these
efforts, and that this is important. It may be very ambitious, but I
think there's a general best practise pattern emerging here for
working with RDF data with regular programming languages -- at least
object-oriented ones. (A pattern that works well both for statically
typed languages and "extends" graciously to leverage the richer
options available in dynamic ones.) Whether or not the "profile"
technique as I defined it for Gluon can work for both how an RDF API
work *and* RDF JSON serialization I'm not certain, but I definitely
think so.

One thing that strikes me with the RDFa DOM API is that at its core it
is a general, usable RDF API for *reading*. It might be nice if this
was decoupled from the "RDFa" (and DOM) monikers, and that a bit more
was added regarding the store part (basically support for
contexts/named graphs), and setting/updating data. This API should
ideally be evaluated by the implementors of e.g. Jena, Sesame,
Redland, RDFLib and RDF.rb, to define the common ground (and/or the
"upper level" folks doing things like O/R-mappers, e.g. Oort ("me"),
RDFAlchemy, JenaBean, Empire, Spira). Then, the RDFa DOM API would be
based on that to define the RDFa- and DOM-specific bindings: to
document, how a triple is attached to a DOM node (and how that would
relate to a "quad" (triple+graph)) etc.

I think this boils down to three questions:

1. Do you see the same potential as I do of a general API?
2. Is it feasible to extract these non-DOM-intrinsic parts from the
RDFa DOM API?
2. Would it make sense to create a Working Group for such an API,
decoupled from RDFa?

Finally, will anybody working with the RDFa DOM API participate in the
RDF Next Steps workshop [7]? I think this is a great place to pitch
for a common API (but alas, I'm unable to attend and thus didn't write
any submission).

Best regards,
Niklas Lindström

[1]: http://www.w3.org/2010/02/rdfa/sources/rdfa-dom-api/
[2]: http://oort.to/
[3]: http://blog.datagraph.org/2010/05/spira
[4]: http://code.google.com/p/oort/wiki/Gluon
[5]: http://code.google.com/p/rdfextras/source/browse/rdfextras/tools/describer.py
[6]: http://pastebin.com/Zs4LK0m0
[7]: http://www.w3.org/2009/12/rdf-ws/

Received on Saturday, 22 May 2010 12:10:15 UTC