Hi John, Yes, I have stepped away from the PMC, but I have been reviewing pull requests on Github, mostly the RDF4J and JSONLD-Java integrations which I am a contributor to.
Most of my contributions were done before moving the project into Apache incubation. The previous repository has been archived, but still exists to delineate the crossing point: https://github.com/commons-rdf/commons-rdf/graphs/contributors Cheers, Peter On 22 November 2016 at 13:47, John D. Ament <johndam...@apache.org> wrote: > Sometimes, we have to believe in github's data. > > https://github.com/apache/incubator-commonsrdf/graphs/contributors > > It indicates its primarily Stian, a bit of Sergio. Andy has helped a bit, > but I do believe Peter has stepped away from the project based on the mail > archives. > > John > > On 2016-11-17 12:11 (-0500), Gary Gregory <garydgreg...@gmail.com> wrote: >> I am more concerned about the size of the community here. Is Paul still >> involved in the code, still wants to be involved, or do we have an SME pool >> size of 1? >> >> Gary >> >> On Nov 16, 2016 11:09 PM, "Benedikt Ritter" <brit...@apache.org> wrote: >> >> > I think we can move RDF to Commons regardless of the maturity of the API. >> > We have other proper components which never had a release. RDF already had >> > three. >> > >> > Benedikt >> > >> > Stian Soiland-Reyes <st...@apache.org> schrieb am Mi. 16. Nov. 2016 um >> > 23:52: >> > >> > > Another is that ServiceLoader don't work well under OSGi without careful >> > > hand holding, so it may be best to leave that to the consumer code rather >> > > than say have a static method in the API with a fixed ServiceLoader. >> > > >> > > (I always have trouble with the ServiceLoader instances built in to Java, >> > > which become very sensitive to which thread initates first) >> > > >> > > It might be worth adding the OSGi service @annotations (or corresponding >> > > XML files) so RDF implementations can be used as OSGI services; all >> > Commons >> > > RDF modules should already be bundles. >> > > >> > > OSGi is probably a good fit with Commons RDF as a library can export only >> > > use of interfaces org.apache.commons.rdf.api, but depend on say RDF4J >> > > internally or get any RDF implementation injected as an OSGi service; >> > which >> > > would not be visible to clients of said library. >> > > >> > > And as the Commons RDF API is interoperable, another part of the >> > > application may use Jena (without knowing it) and pass say a Graph to >> > said >> > > library without any problems. >> > > >> > > BTW, anchor link didn't work because GitHub and Maven have different >> > > Markdown flavours, link is instead: >> > > >> > > >> > > https://commonsrdf.incubator.apache.org/userguide.html# >> > Finding_an_RDF_implementation >> > > >> > > As noted in there, care must be taken with reuse of an RDF instance and >> > > labeled blank nodes: there is no RDFFactoryFactory. >> > > rdf.getClass().newInstance() should work for anything from a >> > ServiceLoader >> > > (but not an OSGi Service which uses proxy classes). >> > > >> > > On 16 Nov 2016 10:02 pm, "Peter Ansell" <ansell.pe...@gmail.com> wrote: >> > > >> > > > Hi Gary, >> > > > >> > > > There is support for java.util.ServiceLoader with the relevant >> > > > META-INF/services files and default constructors, detailed in the >> > > > userguide.md file currently, but could also be in README.md: >> > > > >> > > > https://github.com/apache/incubator-commonsrdf/blob/ >> > > > master/src/site/markdown/userguide.md#Finding_an_RDF_implementation >> > > > >> > > > However, users may be aware of which implementation they prefer and >> > > > use it specifically, to match up with their database drivers or other >> > > > libraries so the direct constructor patterns will be used regularly >> > > > also. >> > > > >> > > > The main reason for that would be that if you use the ServiceLoader >> > > > approach (just using the RDF interface) you don't have object level >> > > > access to the mutators to create native Jena/RDF4J/etc. objects out of >> > > > the Commons RDF objects. There should still be static methods for >> > > > those cases, but they are less simple to use than the mutators in >> > > > general. >> > > > >> > > > Cheers, >> > > > >> > > > Peter >> > > > >> > > > On 17 November 2016 at 02:49, Gary Gregory <garydgreg...@gmail.com> >> > > wrote: >> > > > > In the read me I see a link to an example that has >> > > > > >> > > > > public RDF createFactory() { >> > > > > return new SimpleRDF(); >> > > > > } >> > > > > >> > > > > Is/should a service loader be used to allow pluging in/discovering >> > > > > implementations? >> > > > > >> > > > > Gary >> > > > > >> > > > > On Nov 16, 2016 5:22 AM, "Stian Soiland-Reyes" <st...@apache.org> >> > > wrote: >> > > > > >> > > > > Commons RDF (incubating) has been in the Apache Incubator since 2015, >> > > > > with an aim to graduate into the Apache Commons PMC. I think now >> > the >> > > > > time has come to propose such a move. >> > > > > >> > > > > >> > > > > This route was agreed with the Commons PMC at the time, and we have >> > > > > had good guidance from our mentors, including Commons PMC folks Gary >> > > > > Gregory, Benedikt Ritter and lately myself :) >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > As noted in the 0.3.0 release today, Commons RDF aims to provide a >> > > > > common Java API for RDF 1.1 graphs and datasets. Commons RDF 0.3.0 >> > > > > adds API bindings for Apache Jena, Eclipse RDF4J, JSON-LD Java as >> > well >> > > > > as a standalone implementation. >> > > > > >> > > > > http://commonsrdf.incubator.apache.org/ >> > > > > >> > > > > >> > > > > Now I think Commons RDF is stabilized and is ready to graduate to be >> > a >> > > > > component under Commons PMC where we can do a 1.0.0 release to mark >> > > > > the spot. >> > > > > >> > > > > >> > > > > (Concurrent thread on dev@commonsrdf: >> > > > > https://lists.apache.org/thread.html/760b2d58e344e51550dcc9f6452395 >> > > > > efe72e97d3dc06169ef72f09c6@%3Cdev.commonsrdf.apache.org%3E >> > > > > ) >> > > > > >> > > > > >> > > > > I must admit that community-wise Commons RDF is not as strong as when >> > > > > the podling started - forming a uniform API across multiple >> > > > > implementations and use cases did mean many hard technical and >> > > > > semantic discussions which caused some people to withdraw for a >> > while. >> > > > > Several has since returned as indirect contributors (e.g. code >> > > > > review). >> > > > > >> > > > > >> > > > > Now that the Commons RDF API has settled, and given that Commons has >> > a >> > > > > "any ASF committer have write access" policy and an open development >> > > > > mode, I would like to propose here (and at dev@commonsrdf) that the >> > > > > component graduate to be owned by Apache Commons PMC. >> > > > > >> > > > > >> > > > > Views..? >> > > > > >> > > > > >> > > > > Here's a project maturity report >> > > > > https://github.com/apache/incubator-commonsrdf/blob/ >> > master/MATURITY.md >> > > > > >> > > > > >> > > > > >> > > > > Want to crunch some code ? Have a look at >> > > > > >> > > > > https://commonsrdf.incubator.apache.org/download >> > > > > https://github.com/apache/incubator-commonsrdf/ >> > > > > https://commonsrdf.incubator.apache.org/apidocs/ >> > > > > >> > > > > >> > > > > -- >> > > > > Stian Soiland-Reyes >> > > > > http://orcid.org/0000-0001-9842-9718 >> > > > > >> > > > > ------------------------------------------------------------ >> > --------- >> > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > > > > For additional commands, e-mail: dev-h...@commons.apache.org >> > > > >> > > > --------------------------------------------------------------------- >> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > > > For additional commands, e-mail: dev-h...@commons.apache.org >> > > > >> > > > >> > > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
