There's also some good info on motivation at [1]. However, looking at the RDFa working group site [2], I gather that it may be dropped due to time constraints. Not withstanding, there is an implementation for ECMAScript [3] available.
-Stephen [1] http://www.w3.org/blog/SW/2011/05/10/on_various_rdf_api_sa_b/ [2] http://www.w3.org/2010/02/rdfa/ [3] https://github.com/webr3/rdf-interfaces On Wed, Feb 29, 2012 at 2:31 PM, Andy Seaborne <[email protected]> wrote: > 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 > >
