+1 for option 2 as well. Lets get all the pain done at once. On Mon, Jan 26, 2015 at 10:57 PM, Rob Vesse <[email protected]> wrote:
> Comments inline: > > On 26/01/2015 14:12, "Stian Soiland-Reyes" <[email protected]> wrote: > > >If we move out jena-riot, what is the gain? It relies on jena-core, and > >the > >core kind of needs read/write for everyday use. Core is not abstract like > >the Commons RDF API. > > Well the real "core" is, the basic interfaces and classes I.e. Node, > Triple, Graph, DatasetGraph, Dataset are fairly self contained and > relatively abstract. If we are talking about the Model, Resource, > Ontology API then those are a lot more complex > > It's also perfectly possible to use these APIs without ever needing any IO > (though perhaps unusual). > > > > >Could we at least call it jena-io if it goes solo? I know it also does > >streaming, but don't make it too hard to find ;-). > > > >Just today there was an email on one of the LOD lists where someone bailed > >out of Jena because it needed 4 jena-* JARs to do a remote SPARQL query. > >("the whole Jena stack"). How people survive without dependency management > >is beyond me, but not everyone is in Maven land :-). > > If they think Jena is bad (23 distinct modules) clearly they haven't seen > the list of Sesame artifacts lately (78 distinct modules) ;) > > Side note: This sort of think makes me both laugh and cry. Users want a > user friendly domain specific API but then balk as soon as they realise > that it means actually needing more than one library (because apparently > modularisation is bad practise in the minds of end users). Like you say > if you are a serious developer how you get by without using any kind of > proper build/package management tool really blows my mind. > > > > >I can however see one compelling argument for putting RIOT as a new module > >- if we are able to make both Core and ARQ work without it, and it also > >can > >reduce the list of external dependencies for users of those (e.g. avoid > >jsonld-java, thrift, httpclient?) > > Yes reducing unnecessary dependencies for those that don't need them is > always valuable > > Rob > > >On 26 Jan 2015 19:28, "Rob Vesse" <[email protected]> wrote: > > > >> Andy > >> > >> I would prefer proposal two, Jena 3 will be disruptive regardless (if > >>only > >> because of the time people spend updating import statements). A few > >>other > >> more minor changes to import statements and POM definitions wouldn't be > >> too big of a deal IMHO > >> > >> I would be strongly against leaving old package names with redirects > >>since > >> it only encourages people to not bother migrating code properly and just > >> to simply update the version in the POM and not be aware that there are > >> other changes that happened (e.g. RDF 1.1). A one time disruptive > >> migration forward to Jena 3 that makes me actually have to consider the > >> impact of the migration on my existing code is strongly preferable to a > >> staggered migration > >> > >> In that vein I would suggest that the IO components be moved into their > >> own package (jena-riot I assume?) at the same time, again the principle > >>is > >> to make people take a single larger disruptive migration rather than > >> requiring many smaller migrations. If Core needs to have some way of > >> wiring in IO automatically then I suggest we do it via the Java 7+ > >> ServiceLoader mechanism, I'm already using it a little in the Elephas IO > >> modules and it works pretty nice and I would be willing to help get this > >> set up for Jena 3 IO as necessary. > >> > >> I suppose the IO wiring comes back to the question of whether > >>Model.read() > >> and Model.write() are still relevant or if we force everyone over to > >>using > >> RDFDataMgr (which would be my preference) since the IO module has to > >>rely > >> on Core anyway for the relevant data model APIs and having Core somehow > >> rely on IO is an ugly circular dependency (or gets us into the same > >> problems we have now). Of course the alternative solution to that is to > >> have the Resource API also broken out into its own module so that Core > >> really is only the core low level data structures. > >> > >> With regards to packaging if people are using higher level POM artifacts > >> like apache-jena-libs then the module changes should remain fairly > >> transparent to them. > >> > >> Rob > >> > >> On 24/01/2015 10:34, "Andy Seaborne" <[email protected]> wrote: > >> > >> >[[ > >> >oaj = org.apache.jena > >> >chhj = com.hp.hpl.jena > >> >]] > >> > > >> >One major possible change target is the core/arq split. > >> > > >> >Much of this comes down to where quads/datasets go in the package tree. > >> > They started as a SPARQL (1.0) feature but are now RDF 1.1 and parser > >> >related. > >> > > >> >The general idea is move dataset/quad support to core, move parsers to > >> >core (separate into their own package later??) and have jena-arq be > >> >SPARQL only. > >> > > >> >The question is how much change to go through to achieve that > >> > > >> >Possibility 1 : Less change > >> > > >> >Move DatasetGraph* to oaj.dataset.* > >> > > >> >API visible: > >> > > >> >Migrate Dataset from chhj.query.Dataset to oaj.rdf.dataset (c.f. > >> >oaj.rdf.model) > >> > > >> >Move DatasetGraph and Quad to oaj.dataset (c.f. oaj.graph) > >> > > >> >Try to leave indirection class in chhj.query.Dataset somehow. > >> > > >> > > >> >Possibility 2 : More change, more disruption (but one time) > >> > > >> >Pull oaj.rdf.model up to oaj.rdf and put Dataset there. This is the > >> >"RDF API". > >> > > >> >Use oaj.graph for DatasetGraph and Quad. > >> > > >> >Hmm - actually writing this down, I am tending towards possibility 2 if > >> >that works as cleanly as it sounds. > >> > > >> > Andy > >> > > >> > >> > >> > >> > >> > > > > > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
