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
