Hi Rahul,
Interesting stuff.
Just a few additions:
Jena itself has a split between presentation APIs (e.g.
Model/Statement/Resource) and core system SPI (Graph/Triple/Node - you
can create illegal RDF at this level). There's no reason why there
can't be multiple presentation APIs nor indeed should it matter whether
it's part for the core system or an additional library independent of
other development.
I wonder if this is a possible step to creating a neutral de facto Java
API for RDF. If so, I'd suggest keeping technical ambitions low as
getting buy in from others is hard enough anyway. It woudl be a really
useful to have happen though.
Non-technical:
1/ If you take contributions to your project, keep a track of everything
(who contributed what, and when, emails, copyrights).
2/ MPL is one of Apache's "category B" licenses:
http://www.apache.org/legal/3party.html#category-b
which has source code implications.
Andy
On 29/02/12 02:05, Stephen Allen wrote:
On Tue, Feb 28, 2012 at 10:20 AM, Rahul Parundekar
<[email protected]> wrote:
Hello,
I was wondering if the new Jena API would be based on the W3C RDF
Interfaces draft
http://www.w3.org/TR/2011/WD-rdf-interfaces-20110510/
If not yet, I have a bunch of Java interfaces created based on the above
specifications at http://code.google.com/p/rdf-interfaces-api/ and am
willing to contribute them to the project.
Thanks,
Rahul
Hi Rahul,
I haven't heard of any plans to implement such an API (not to say that
it wouldn't happen).
However, having read the draft, I have a few concerns with the
specification as it relates to an API implemented in Java. Keep in
mind, these come from an RDF / SPARQL developer, who is used to
working in strongly typed languages like Java and C#, and has probably
had his mind warped from familiarity with Jena. I also don't really
have much experience with RDFa.
1) Triple interface
a) No type differentiation between Named Resources, Blank Node
Resources and Literals in the various subject, predicate, and object
positions. Instead it is represented as an attribute, which limits it
to runtime error checking (may not be an issue in ECMAScript, but is
rather ugly in strongly typed languages)
2) Graph interface
a) There are many iterator/enumerator methods which I believe should
not be included. These are available readily from other libraries
(such as LINQ in C#, Guava in Java, and jQuery(?) in ECMAScript).
These functions include toArray(), some(), every(), filter(),
forEach(), merge(), and the "limit" parameter of match(). Instead,
Graph should provide a iterator() method that allows the caller to
iterate over all the triples.
b) match() should return an iterator instead of a Graph. This
prevents having to materialize all the results if they aren't needed
c) Given the above, the following interfaces don't seem necessary:
TripletFilter, TripletCallback, TripleAction
3) No concept of an RDF Dataset (a default graph + a collection of
named graphs) the related Quad objects
4) TermMap does not correspond to anything RDF specific. I'm guessing
this is something from the RDFa world? Again, maybe an external
library would appropriate here.
5) Scope seems a little limited, there is no attempt to address SPARQL
/ SPARQL Update interfaces. Although if the original goal was to
focus on ECMAScript this is understandable, since those might not be
exposed to the open web anyway.
Ultimately, I would guess that Jena implementing this API would be
weighed against a few concerns: 1) user confusion/support costs for a
3rd RDF API (we already have two, Model and Graph), 2) effort to
implement the API, and 3) ongoing maintenance costs of the code.
Additionally, the specification is still in Working Draft form which
would make it more difficult to track and stay up to date with.
-Stephen
