I'm also interested in making Jena parsers and serializers usable directly from a Commons RDF perspective, without interaction with intermediate Jena core objects. E.g something like:
Stream<Triple> s = JenaCommonsRDF.read(inputStream, Lang.Turtle) And vice versa for write. Such a bridge should be possible on top of StreamRDF and RIOT, right? Perhaps a Worker thread is needed if there is pull vs push issues. Should we start a branch, or first flesh out the rough edges of such a bridge module in the wiki? On 13 May 2015 15:59, "Andy Seaborne" <[email protected]> wrote: > On 12/05/15 15:26, A. Soroka wrote: > >> At: >> >> http://commonsrdf.incubator.apache.org/implementations.html >> >> It says "Apache Jena is considering a compatibility interface that >> provides and consumes Commons RDF objects." >> >> I'm wondering if there have been any experiments to that end, or whether >> Jena is waiting for some resources to explore that possibility? I would be >> happy to give a go at making a simple module that just implements the >> current Commons RDF API types over >> jena-core in a simple way, to get things started. >> --- >> A. Soroka >> The University of Virginia Library >> >> > I have some code that mocks up commonsrdf over Jena in the sense that it > uses jena behind the RDFTermFactory; that's the easy bit. It's limited and > definitely not a bridge between the two APIs. It is merely exploring the > commonsrdf work. > > It would mess up the existing interfaces no end to add commonsrdf as > interfaces to Model/Resource; and Graph/Triple/Node is generalized RDF so > the type model does not fit. > > It needs a bridge module and a proper module would be good. > > ((I also have https://github.com/afs/commonsrdf-container which is even > more minimal than the "simple" implementation. Not Jena related.)) > > Some other interesting projects: > An in-memory dataset : JENA-624 > > Have a specifically in-memory DatasetGraph to complement the current > general purpose dataset. > > Bruno is working on JENA-632 > > In fact, I can see commonsrdf being at the center of a new API, very Java8 > specific, that is oriented around processing RDF stream style - see the > email from Paul Houle. > > Or take StreamRDF and add java8-stream-ness around it (maybe not directly > changing but making it the source for java8-streams - some issues of > pull-streams and push-stream styles here which are hard when efficiency is > considered). > > > Andy >
