Hello Peter, 2015-01-16 1:29 GMT+01:00 Peter Ansell <ansell.pe...@gmail.com>:
> The Clerezza team were all notified about the effort to put a common > RDF API together on GitHub and they responded positively at that > point. The only sticking point then and now IMO is the purely academic > distinction of opening up internal labels for blank nodes versus not > opening it up at all. Reto is against having the API allow access to > the identifiers on academic grounds, where other systems pragmatically > allow it with heavily worded javadoc contracts about their limited > usefulness, per the RDF specifications: > > > https://mail-archives.apache.org/mod_mbox/clerezza-dev/201406.mbox/%3c5398b07c.5000...@apache.org%3E > > However, for some more background we could refer back to discussion > about restructuring both Clerezza and Stanbol to make them more > maintainable and useful to the community: > > > https://mail-archives.apache.org/mod_mbox/stanbol-dev/201211.mbox/%3CCAA7LAO2X++Uk8PoNM+b9=f9v2dn5zdzljh2bje0mmrzcyaf...@mail.gmail.com%3E > > In particular, as Rupert Westenthaler mentions there, the goal to > simply promote the Clerezza RDF model as commons.rdf would not achieve > much given the share that Jena and Sesame have. > > The Commons RDF effort that Sergio has brokered, including Andy (Jena) > and I (Sesame), and including both Scala (w3c/banana-rdf@github) and > Clojure (drlivingston/kr@github) project representatives will provide > the common JVM RDF API that Rupert referred to as being necessary. > > The main points as I see it that are necessary before starting the > process that was aborted last time (echoing Sergio's comments): > > * Mailing list clutter: both in terms of the wide range of technical > discussions from commons rdf, and general email traffic from other > commons sub-projects discouraging potential participants from joining > in the discussion. > We're discussing this. I need to catch up with that discussion, since I've bin offline for a few days :-) > * Being able to use GitHub pull requests for code review, including if > necessary the sending of comments there to the apache mailing list > that is decided to be used for that purpose. The actual merging will > be done by hand in this case, but the code review features there are > too useful. The patching of PR comments back to apache mailing lists > has already done, so there is no technical issue for this, just > deciding which mailing list the comments will go to. > There is a infra hook that can forward any comments on github issues to jira issues. I think this would be sufficient. Github mirrors are read only, so you will have to live with the manual merge approach... > * Having it okay that the commons rdf api is a project that > principally aims to create a set of interfaces, and not host any of > the scalable implementations of the API. Stian Soiland-Reyes has > written a basic implementation, but in practice, any large dataset > will not load into that implementation and be queried efficiently, so > it is only going to be used for small in-memory tasks. > This is something you guys have to figure out :-) > > I hope there is no bad blood from the aborted effort last time. There > were a variety of causes, including the reasons above but we all > joined the GitHub discussion with the goal of hosting the project > inside of the Apache Foundation and IMO Apache Commons is still likely > the best way to do that for our small (in terms of code) project. > > Cheers, > > Peter > To sum this up: All that is blocking github commons rdf to join Apache Commons is the mailing list thing? Regards, Benedikt > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
