Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
On 10/11/10 23:28, Jeremy Carroll wrote: - The core API for (mutable) graphs in: http://incubator.apache.org/clerezza/mvn-site/org.apache.clerezza.rdf.core/apidocs/index.html http://incubator.apache.org/clerezza/mvn-site/org.apache.clerezza.rdf.core/apidocs/org/apache/clerezza/rdf/core/TripleCollection.html#filter(org.apache.clerezza.rdf.core.NonLiteral,%20org.apache.clerezza.rdf.core.UriRef,%20org.apache.clerezza.rdf.core.Resource) IteratorTriple filter(NonLiteral subject, UriRef predicate, Resource object) vs http://jena.sourceforge.net/javadoc/com/hp/hpl/jena/graph/Graph.html#find(com.hp.hpl.jena.graph.Node,%20com.hp.hpl.jena.graph.Node,%20com.hp.hpl.jena.graph.Node) ExtendedIteratorTriple find(Node s, Node p, Node o) seems to be the fundamental choice. The latter was the choice Chris Dollin and I made in 2002/2003 and I still find it preferable, for program uniformity, to the closer to the spec choice in Clerezza. We were writing the spec at the same time, and I always saw it as a description of a Web exchange format, and not of a programming interface (for instance implementing RDF Semantics Rec is hard with the Clerezza interface). Isn't the model interface operation a more appropriate comparision because that is what the application sees? StmtIterator listStatements(Resource s, Property p, RDFNode o) Graph.find is the SPI interface to storage. The Graph level has named variables, not just RDF terms. SPARQL uses this, heavily. In SPARQL, literals can occur in any position during query processing. Patterns involving literals as subjects, or as predicates, just simply don't match the data (section 12.3.1). Once upon a time, when we were going Jena1-Jena2, the idea was that the application API was just one presentation. There could be other RDF APIs over the SPI. There's not been a second RDF presentation API but the design concept was there and still is. All the interfaces in the API are mainly implemented only once, and I'm not aware of any users which use the extensibility within the Resource API anymore (Parliament/BBN used to - I think they now use an associated datastructure to map to internal information for any API resources/literals from their storage). The Resource-level API implementation could be simplified if theer is only one implementation of that presentation. There is generality in Jena that we thought was a good idea at the time but looking at way the world has gone since, not all of it is used or useful nowadays. Better use of factory/interface at the SPI would be more helpful. The experimental Jena3 core also has extension nodes and graph nodes with an eye to future possible needs from the standards world. I am not quite sure what that means in terms of this discussion which is more procedural than technical. Same here. Advice on an appropriate discussion forum welcome - while we're in a state of exploring the relationships of projects, I'm guessing that here is the only common place there is. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
Hi, On Thu, Nov 11, 2010 at 11:21 AM, Andy Seaborne andy.seabo...@epimorphics.com wrote: ...Advice on an appropriate discussion forum welcome - while we're in a state of exploring the relationships of projects, I'm guessing that here is the only common place there is... Best might be to move this discussion to the clerezza dev list for now? Email clerezza-dev-subscr...@incubator.apache.org to subscribe - several Stanbol developers are subscribed AFAIK. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
- The core API for (mutable) graphs in: http://incubator.apache.org/clerezza/mvn-site/org.apache.clerezza.rdf.core/apidocs/index.html http://incubator.apache.org/clerezza/mvn-site/org.apache.clerezza.rdf.core/apidocs/org/apache/clerezza/rdf/core/TripleCollection.html#filter(org.apache.clerezza.rdf.core.NonLiteral,%20org.apache.clerezza.rdf.core.UriRef,%20org.apache.clerezza.rdf.core.Resource) IteratorTriple filter(NonLiteral subject, UriRef predicate, Resource object) vs http://jena.sourceforge.net/javadoc/com/hp/hpl/jena/graph/Graph.html#find(com.hp.hpl.jena.graph.Node,%20com.hp.hpl.jena.graph.Node,%20com.hp.hpl.jena.graph.Node) ExtendedIteratorTriple find(Node s, Node p, Node o) seems to be the fundamental choice. The latter was the choice Chris Dollin and I made in 2002/2003 and I still find it preferable, for program uniformity, to the closer to the spec choice in Clerezza. We were writing the spec at the same time, and I always saw it as a description of a Web exchange format, and not of a programming interface (for instance implementing RDF Semantics Rec is hard with the Clerezza interface). I am not quite sure what that means in terms of this discussion which is more procedural than technical. Like in all things people make different choices and have different preferences, and a decision to all use the same libraries would be a restriction in design freedom, on such issues, which might be good, or might be bad. === On http://mail-archives.apache.org/mod_mbox/incubator-clerezza-dev/201011.mbox/%3caanlktinwbvruoemfhh8ohdvvesgm09z0affgserbw...@mail.gmail.com%3e [[ - graph isomorphism code ]] what are the goals of the Clerezza isomorphism code? The Jena code is essentially scoped to testing, so that I checked that small pathological cases were OK, and larger non-pathological cases, but it is not meant to have production level performance, particular on graphs for which something like nauty would be more appropriate. Jeremy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
Olivier Grisel wrote: On 8 November 2010 15:54, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, I'm following up on discussions here regarding relationships between the incubating Clerezza podling and incoming Stanbol and Jena podlings (see proposals at http://wiki.apache.org/incubator). Do people agree with the following structure? 1. Clerezza, Stanbol and Jena are independent podlings, each aiming for top-level status There is a depedency relationship: - Stanbol is a of application level HTTP services and set of OSGi components that use: - Clerezza as an OSGi service provider which in turn is using: - Jena as a lib for parsing and serializing RDF models and as a SPARQL enabled triple store. These are, at the moment, the Jena classes used by some of the Clerezza modules: com.hp.hpl.jena.datatypes.TypeMapper com.hp.hpl.jena.datatypes.xsd.impl.XMLLiteralType com.hp.hpl.jena.graph.Graph com.hp.hpl.jena.graph.impl.GraphBase com.hp.hpl.jena.graph.Node com.hp.hpl.jena.graph.Node_URI com.hp.hpl.jena.graph.Reifier com.hp.hpl.jena.graph.Triple com.hp.hpl.jena.graph.TripleMatch com.hp.hpl.jena.mem.TrackingTripleIterator com.hp.hpl.jena.query.Dataset com.hp.hpl.jena.query.QueryExecException com.hp.hpl.jena.query.QueryExecution com.hp.hpl.jena.query.QueryExecutionFactory com.hp.hpl.jena.query.QueryFactory com.hp.hpl.jena.query.QuerySolution com.hp.hpl.jena.query.ResultSet com.hp.hpl.jena.rdf.model.impl.NodeIteratorImpl com.hp.hpl.jena.rdf.model.Literal com.hp.hpl.jena.rdf.model.Model com.hp.hpl.jena.rdf.model.ModelFactory com.hp.hpl.jena.rdf.model.RDFNode com.hp.hpl.jena.rdf.model.RDFWriter com.hp.hpl.jena.rdf.model.Resource com.hp.hpl.jena.rdf.model.RSIterator com.hp.hpl.jena.rdf.model.Statement com.hp.hpl.jena.rdf.model.StmtIterator com.hp.hpl.jena.shared.AlreadyReifiedException com.hp.hpl.jena.shared.Lock com.hp.hpl.jena.shared.ReificationStyle com.hp.hpl.jena.sparql.core.DatasetGraph com.hp.hpl.jena.sparql.core.Quad com.hp.hpl.jena.sparql.util.Context com.hp.hpl.jena.tdb.TDB com.hp.hpl.jena.tdb.TDBFactory com.hp.hpl.jena.util.iterator.ExtendedIterator com.hp.hpl.jena.util.iterator.Filter com.hp.hpl.jena.util.iterator.NullIterator com.hp.hpl.jena.vocabulary.DC com.hp.hpl.jena.vocabulary.RDF com.hp.hpl.jena.vocabulary.RDFS Reto Bachmann-Gmür wrote (on jena-devel): In Clerezza Jena is used in the implementation of some modules: - Jena Based Serializers and Parsers - Jena Sparql - Jena TDB Based storage - Implementation of the Jena API on top of Clerezza Graphs (jena.facade) Apart for the last one the modules are independent of Jena in terms of the API they expose. Clerezza can be used without any of these modules but if one of these are used Clerezza needs Bundles for the whole of Jena, it would be nice if the various modules could depend only on the parts of Jena that are actually needed by them. Paolo The dependency between Clerezza and Jena is optional as many OSGi services in Clerezza can also work with sesame as an alternative RDF lib and triple store. 2. A Semantic Commons area is created for common code between these (and other) projects. Details to be discussed, this does probably not warrant a separate Apache project, but might be managed by Clerezza, as they were here first. Ok on the principle but I would suggest not to create this as long we don't have any code that does not belong to one of the three previous projects. Developers of the upstream project should try to take care an not reinvent the wheel and try to move new features and bugfix to upstream if they naturally belong there. 3. It is expected that those projects will have a number of committers in common, as there are many collaboration possibilities. +1 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
Hi Jeremy One of Clerezza aims was to use an RDF api that is maximally close to RDF abstract syntax and semantics, on this RDF core api we have different façades and utilities as well as a frontend adapter implementing the jena API. Related standards like SPARQL and the various serialization formats are supported as well, respective engines can be added at runtime (when running in a OSGI container). We decided to design our own API as we found the various API available (jena, openrdf, rdf2go) would neither be as modular nor as close to the spec as we wanted them to be. The API comes with the typical utilities like a command line tool and a maven plugin for the transformation of vocabularies into classes Apart from core part tightly coupled to RDF and related specs Clerezza also provides a framework for implementing rest applications (JAX-RS). The encourages design pattern is that requests are answered in terms of RDF (i.e. a graph and typically a selected resource within this graph), clerezza takes care about content-negotiation and for RDF formats the serializer registered for that media type is used. For non RDF formats a template (typically a Scala Server Pages) is selected and takes care of the rendering. I described this parts of Clerezza because they seem to be quite close to what you suggest for commons. As it is hard to share utilities without having shared APIs for the core stuff our code deals with I think some efforts in this area could have the greatest benefit. If you have some time, I would like to encourage feedback on the respective APIs as currently used in Clerezza - The core API for (mutable) graphs in: http://incubator.apache.org/clerezza/mvn-site/org.apache.clerezza.rdf.core/apidocs/index.html - Utilities (including resource-centric API): http://incubator.apache.org/clerezza/mvn-site/org.apache.clerezza.rdf.utils/apidocs/index.html These two layers are similar to the Graph/Model separation in Jena. Cheers, Reto On Mon, Nov 8, 2010 at 7:32 PM, Jeremy Carroll jer...@topquadrant.comwrote: To make the commons discussion more concrete I would suggest the following items for the commons: - an IRI library - some code to do with vocabularies. - connecting to a URL and doing semweb aware content negotiation (this is typically done badly) (Actually the IRI code should probably be wider, Jena initially used the xerces URI code but then the needs exceeded what they supported) Jeremy On 11/8/2010 7:22 AM, Ian Dickinson wrote: On 08/11/10 15:09, Mattmann, Chris A (388J) wrote: Wow! Jena is proposing to come to Apache??! Yep, the proposal has been under discussion for some time within the project, and Ross is now taking the lead in bringing it publicly into the incubator process. Bertrand wrote: 1. Clerezza, Stanbol and Jena are independent podlings, each aiming for top-level status 2. A Semantic Commons area is created for common code between these (and other) projects. Details to be discussed, this does probably not warrant a separate Apache project, but might be managed by Clerezza, as they were here first. 3. It is expected that those projects will have a number of committers in common, as there are many collaboration possibilities. As an Apache newbie it's hard to comment definitively, but it's not clear to me what the common needs of the projects might be, and how dependencies would handled. Are there examples of existing commons areas between Apache projects, other than basic application-library dependencies? Ian - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
I haven't understood yet the relationship of Stanbol and Clerezza to be able to say anything about how a commons area between those two systems might work. In terms of direct dependencies, does Stanbol just directly depend on Clerezza and only indirectly on Sesame, Jena rdf2go and the OWLAPI that the proposal lists? Jena has two levels of API, the Model/Statement/Resource that applications usually use, and the SPI Graph/Triple/Node thathe the storage and inference layers plug into. Roughly, speaking, the API faces upwards to applications and the SPI downwards to components. There is also the same design for the support for RDF datasets for SPARQL. SPARQL, especially SPARQL Update, works on quads for named graphs. There are significant investments by users in uses of both API and SPI and the cost of change for users isn't trivial. Worse, the SPI is used by systems that are distributed on making any change over messy. There needs to be a real advantage to change. Speaking personally, I'm not strongly motivated by a common API; I don't think it helps the semantic web enough compared with other things I could work on. If others are working on one, I'll do what I can to make my contributions work as smoothly as possible with that through discussing what hooks and flexibility I can contribute to Jena to make it work smoothly with other systems. I'm not particularly worried about there being several APIs since that's the state we're in and I don't see it changing particularly quickly because there are large investments in deployed systems that exists. As some of these systems themselves are distributed onwards, chnage woudl be slow. Most of my contribution is storage and query which works at the lower level anyway, so it has less effect on me but the SPARQL related parts of the public APIs are mostly my fault. I am currently working on a SPARQL 1.1 compliant server - the on-the-wire standardization is more important. Working on storage and query does result in a slight obsession with efficiency - storage and query need to be tightly coupled for performance. Jeremy identified the IRI library as a potential contribution to a commons area. It is free-standing, and does not use or call any Jena RDF code - it depends only on ICU4J (and JUnit + Jflex in the build). The client-side content negotiation code in Jena could do with an upgrade so if there is system-independent code that can be reused for the systems here and more widely, that would be great. I would use it as I need to provide code-level access to for client SPARQL 1.1 access. If nothing else, shared knowledge and expertise would move things along faster, and even if functionality needs tying to specific systems, having all the projects in Apache greatly helps community. Andy PS Reto - GVS [*] isn't on the list of thing to contribute to Apache as we're focusing on the core system that is used and we support. But that does not preclude including GVS either now or later. It is covered by our agreement-in-principle with HP. Do you want to do that? [*] Reto wrote a graph versioning system for Jena several years ago. On 08/11/10 21:39, Reto Bachmann-Gmuer wrote: Hi Jeremy One of Clerezza aims was to use an RDF api that is maximally close to RDF abstract syntax and semantics, on this RDF core api we have different façades and utilities as well as a frontend adapter implementing the jena API. Related standards like SPARQL and the various serialization formats are supported as well, respective engines can be added at runtime (when running in a OSGI container). We decided to design our own API as we found the various API available (jena, openrdf, rdf2go) would neither be as modular nor as close to the spec as we wanted them to be. The API comes with the typical utilities like a command line tool and a maven plugin for the transformation of vocabularies into classes Apart from core part tightly coupled to RDF and related specs Clerezza also provides a framework for implementing rest applications (JAX-RS). The encourages design pattern is that requests are answered in terms of RDF (i.e. a graph and typically a selected resource within this graph), clerezza takes care about content-negotiation and for RDF formats the serializer registered for that media type is used. For non RDF formats a template (typically a Scala Server Pages) is selected and takes care of the rendering. I described this parts of Clerezza because they seem to be quite close to what you suggest for commons. As it is hard to share utilities without having shared APIs for the core stuff our code deals with I think some efforts in this area could have the greatest benefit. If you have some time, I would like to encourage feedback on the respective APIs as currently used in Clerezza - The core API for (mutable) graphs in: http://incubator.apache.org/clerezza/mvn-site/org.apache.clerezza.rdf.core/apidocs/index.html -
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
On Tue, Nov 9, 2010 at 1:19 PM, Andy Seaborne andy.seabo...@epimorphics.com wrote: Jeremy identified the IRI library as a potential contribution to a commons area. It is free-standing, and does not use or call any Jena RDF code - it depends only on ICU4J (and JUnit + Jflex in the build). Please note that Abdera already has an IRI library. http://svn.apache.org/repos/asf/abdera/java/trunk/dependencies/i18n/src/main/java/org/apache/abdera/i18n/iri/ Florent -- Florent Guillaume, Director of RD, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
On 09/11/10 16:22, Florent Guillaume wrote: On Tue, Nov 9, 2010 at 1:19 PM, Andy Seaborne andy.seabo...@epimorphics.com wrote: Jeremy identified the IRI library as a potential contribution to a commons area. It is free-standing, and does not use or call any Jena RDF code - it depends only on ICU4J (and JUnit + Jflex in the build). Please note that Abdera already has an IRI library. http://svn.apache.org/repos/asf/abdera/java/trunk/dependencies/i18n/src/main/java/org/apache/abdera/i18n/iri/ Florent, Thanks for pointing that out. I see it has a test suite as well and it would be good to make sure we've got things right. Illegal IRIs in data have been a bit of a plague in RDF data and the IRI library (written by Jeremy) is a response to that. It checks both rules for specific IRI schemes and also recommended forms as IRIs are often com pared for equality. The library is quite picky. It includes profiles for RDF URI references, IRI and the compromise we use in Jena as a balance of legacy and spec exactness. There is an online test service for RDF data in non-RDF/XML formats at: http://sparql.org/data-validator.html The IRIs are checked with the IRI library. Andy A few examples: http://example/a b Code: 17/WHITESPACE in PATH: A single whitespace character. These match no grammar rules of URIs/IRIs. These characters are permitted in RDF URI References, XML system identifiers, and XML Schema anyURIs. http://example/a[]b Code: 0/ILLEGAL_CHARACTER in PATH: The character violates the grammar rules for URIs/IRIs. http://example:80/ Code: 13/DEFAULT_PORT_SHOULD_BE_OMITTED in PORT: If the port is the default one for the scheme it should be omitted. http://example:80/ Code: 14/PORT_SHOULD_NOT_BE_WELL_KNOWN in PORT: Ports under 1024 should be accessed using the appropriate scheme name urn:xyz Code: 61/SCHEME_PATTERN_MATCH_FAILED in PATH: The scheme specific syntax rules are violated. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
On 11/9/2010 8:22 AM, Florent Guillaume wrote: On Tue, Nov 9, 2010 at 1:19 PM, Andy Seaborne andy.seabo...@epimorphics.com wrote: Jeremy identified the IRI library as a potential contribution to a commons area. It is free-standing, and does not use or call any Jena RDF code - it depends only on ICU4J (and JUnit + Jflex in the build). Please note that Abdera already has an IRI library. http://svn.apache.org/repos/asf/abdera/java/trunk/dependencies/i18n/src/main/java/org/apache/abdera/i18n/iri/ Florent I'll take a look, it may take a little time. Jeremy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
I could be accused of having gone overboard ... each of the slightly different specs as an explicit representation in the code ... Having changed job and looking at this from a different perspective I am less convinced by the pickiness. There is a largely unrealized goal in the IRI code to link errors right back to the specs so that the error messages quote chapter and verse. Jeremy On 11/9/2010 8:52 AM, Andy Seaborne wrote: On 09/11/10 16:22, Florent Guillaume wrote: On Tue, Nov 9, 2010 at 1:19 PM, Andy Seaborne andy.seabo...@epimorphics.com wrote: Jeremy identified the IRI library as a potential contribution to a commons area. It is free-standing, and does not use or call any Jena RDF code - it depends only on ICU4J (and JUnit + Jflex in the build). Please note that Abdera already has an IRI library. http://svn.apache.org/repos/asf/abdera/java/trunk/dependencies/i18n/src/main/java/org/apache/abdera/i18n/iri/ Florent, Thanks for pointing that out. I see it has a test suite as well and it would be good to make sure we've got things right. Illegal IRIs in data have been a bit of a plague in RDF data and the IRI library (written by Jeremy) is a response to that. It checks both rules for specific IRI schemes and also recommended forms as IRIs are often com pared for equality. The library is quite picky. It includes profiles for RDF URI references, IRI and the compromise we use in Jena as a balance of legacy and spec exactness. There is an online test service for RDF data in non-RDF/XML formats at: http://sparql.org/data-validator.html The IRIs are checked with the IRI library. Andy A few examples: http://example/a b Code: 17/WHITESPACE in PATH: A single whitespace character. These match no grammar rules of URIs/IRIs. These characters are permitted in RDF URI References, XML system identifiers, and XML Schema anyURIs. http://example/a[]b Code: 0/ILLEGAL_CHARACTER in PATH: The character violates the grammar rules for URIs/IRIs. http://example:80/ Code: 13/DEFAULT_PORT_SHOULD_BE_OMITTED in PORT: If the port is the default one for the scheme it should be omitted. http://example:80/ Code: 14/PORT_SHOULD_NOT_BE_WELL_KNOWN in PORT: Ports under 1024 should be accessed using the appropriate scheme name urn:xyz Code: 61/SCHEME_PATTERN_MATCH_FAILED in PATH: The scheme specific syntax rules are violated. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
On 09/11/10 16:59, Jeremy Carroll wrote:
I could be accused of having gone overboard ...
yes ... :-)
Having changed job and looking at this from a different perspective I am
less convinced by the pickiness.
At least leave the picky mode there, please. It's been very helpful in
working with data generated by one organisation and used by another.
Script generated IRIs have been
Once dubious data gets into a database, it's troublesome to get it out.
Having the data storage only cover the required spec common ground is
better.
TDB uses the IRI profile (not RDF URI references) as strict as possible
except that these two warnings are switched off:
ViolationCodes.UNWISE_CHARACTER
that is {, }, |, \, ^, `
It's the | that I found used in generated IRIs.
Whitespace is handled separately.
are syntax errors.
ViolationCodes.UNREGISTERED_IANA_SCHEME
because people invent schemes for data.
I did find the most strict mode a bit too strict :-)
Andy
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
On Mon, Nov 8, 2010 at 3:54 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: ...I'm following up on discussions here regarding relationships between the incubating Clerezza podling and incoming Stanbol and Jena podlings... Thanks everybody for your replies, I think they show that the proposed semantic commons might make sense, but we shouldn't rush things until there's actually something to put in there. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
2010/11/8 Reto Bachmann-Gmuer reto.bachm...@trialox.org I described this parts of Clerezza because they seem to be quite close to what you suggest for commons. As it is hard to share utilities without having shared APIs for the core stuff our code deals with I think some efforts in this area could have the greatest benefit. +1 Also in Clerezza there are some ontologies [1] defined which would be good to share in a semantic repository for ontologies. I think especially Clerezza and Stanbol would benefit from such a common repo. This, in my opinion, would fit well into semantic commons. Tommaso [1] : http://svn.apache.org/repos/asf/incubator/clerezza/trunk/org.apache.clerezza.parent/org.apache.clerezza.rdf.ontologies/src/main/resources/org/apache/clerezza/rdf/ontologies/
Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
Hi, I'm following up on discussions here regarding relationships between the incubating Clerezza podling and incoming Stanbol and Jena podlings (see proposals at http://wiki.apache.org/incubator). Do people agree with the following structure? 1. Clerezza, Stanbol and Jena are independent podlings, each aiming for top-level status 2. A Semantic Commons area is created for common code between these (and other) projects. Details to be discussed, this does probably not warrant a separate Apache project, but might be managed by Clerezza, as they were here first. 3. It is expected that those projects will have a number of committers in common, as there are many collaboration possibilities. WDYT? -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
As champion for Jena I agree in principle. I can't speak for the Jena team if course, but representatives are tracking this list and have started discussing in their project list. I will be making the formal Jena proposal here very soon (just as soon as I'm not limited to the iPhone) - its in the wiki if people want a preview. Ross Sent from my mobile device. On 8 Nov 2010, at 14:54, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, I'm following up on discussions here regarding relationships between the incubating Clerezza podling and incoming Stanbol and Jena podlings (see proposals at http://wiki.apache.org/incubator). Do people agree with the following structure? 1. Clerezza, Stanbol and Jena are independent podlings, each aiming for top-level status 2. A Semantic Commons area is created for common code between these (and other) projects. Details to be discussed, this does probably not warrant a separate Apache project, but might be managed by Clerezza, as they were here first. 3. It is expected that those projects will have a number of committers in common, as there are many collaboration possibilities. WDYT? -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
Wow! Jena is proposing to come to Apache??! Sweet! We've used it in OODT since 2003...looking forward to it! Cheers, Chris On 11/8/10 7:04 AM, Ross Gardler rgard...@apache.org wrote: As champion for Jena I agree in principle. I can't speak for the Jena team if course, but representatives are tracking this list and have started discussing in their project list. I will be making the formal Jena proposal here very soon (just as soon as I'm not limited to the iPhone) - its in the wiki if people want a preview. Ross Sent from my mobile device. On 8 Nov 2010, at 14:54, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, I'm following up on discussions here regarding relationships between the incubating Clerezza podling and incoming Stanbol and Jena podlings (see proposals at http://wiki.apache.org/incubator). Do people agree with the following structure? 1. Clerezza, Stanbol and Jena are independent podlings, each aiming for top-level status 2. A Semantic Commons area is created for common code between these (and other) projects. Details to be discussed, this does probably not warrant a separate Apache project, but might be managed by Clerezza, as they were here first. 3. It is expected that those projects will have a number of committers in common, as there are many collaboration possibilities. WDYT? -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.mattm...@jpl.nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
On 8 November 2010 15:54, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, I'm following up on discussions here regarding relationships between the incubating Clerezza podling and incoming Stanbol and Jena podlings (see proposals at http://wiki.apache.org/incubator). Do people agree with the following structure? 1. Clerezza, Stanbol and Jena are independent podlings, each aiming for top-level status There is a depedency relationship: - Stanbol is a of application level HTTP services and set of OSGi components that use: - Clerezza as an OSGi service provider which in turn is using: - Jena as a lib for parsing and serializing RDF models and as a SPARQL enabled triple store. The dependency between Clerezza and Jena is optional as many OSGi services in Clerezza can also work with sesame as an alternative RDF lib and triple store. 2. A Semantic Commons area is created for common code between these (and other) projects. Details to be discussed, this does probably not warrant a separate Apache project, but might be managed by Clerezza, as they were here first. Ok on the principle but I would suggest not to create this as long we don't have any code that does not belong to one of the three previous projects. Developers of the upstream project should try to take care an not reinvent the wheel and try to move new features and bugfix to upstream if they naturally belong there. 3. It is expected that those projects will have a number of committers in common, as there are many collaboration possibilities. +1 -- Olivier - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
On Mon, Nov 8, 2010 at 4:14 PM, Olivier Grisel ogri...@nuxeo.com wrote: On 8 November 2010 15:54, Bertrand Delacretaz bdelacre...@apache.org wrote: ... 1. Clerezza, Stanbol and Jena are independent podlings, each aiming for top-level status There is a depedency relationship:... Agreed - I meant independent communities, code dependencies are expected. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
Correction: actually not sure about 2003 but seems like we been using it for that long! Cheers, Chris Sent from my Verizon Wireless BlackBerry -Original Message- From: Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov Date: Mon, 8 Nov 2010 07:09:13 To: general@incubator.apache.orggeneral@incubator.apache.org Reply-To: general@incubator.apache.org general@incubator.apache.org Subject: Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT? Wow! Jena is proposing to come to Apache??! Sweet! We've used it in OODT since 2003...looking forward to it! Cheers, Chris On 11/8/10 7:04 AM, Ross Gardler rgard...@apache.org wrote: As champion for Jena I agree in principle. I can't speak for the Jena team if course, but representatives are tracking this list and have started discussing in their project list. I will be making the formal Jena proposal here very soon (just as soon as I'm not limited to the iPhone) - its in the wiki if people want a preview. Ross Sent from my mobile device. On 8 Nov 2010, at 14:54, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, I'm following up on discussions here regarding relationships between the incubating Clerezza podling and incoming Stanbol and Jena podlings (see proposals at http://wiki.apache.org/incubator). Do people agree with the following structure? 1. Clerezza, Stanbol and Jena are independent podlings, each aiming for top-level status 2. A Semantic Commons area is created for common code between these (and other) projects. Details to be discussed, this does probably not warrant a separate Apache project, but might be managed by Clerezza, as they were here first. 3. It is expected that those projects will have a number of committers in common, as there are many collaboration possibilities. WDYT? -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.mattm...@jpl.nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
On 08/11/10 15:09, Mattmann, Chris A (388J) wrote: Wow! Jena is proposing to come to Apache??! Yep, the proposal has been under discussion for some time within the project, and Ross is now taking the lead in bringing it publicly into the incubator process. Bertrand wrote: 1. Clerezza, Stanbol and Jena are independent podlings, each aiming for top-level status 2. A Semantic Commons area is created for common code between these (and other) projects. Details to be discussed, this does probably not warrant a separate Apache project, but might be managed by Clerezza, as they were here first. 3. It is expected that those projects will have a number of committers in common, as there are many collaboration possibilities. As an Apache newbie it's hard to comment definitively, but it's not clear to me what the common needs of the projects might be, and how dependencies would handled. Are there examples of existing commons areas between Apache projects, other than basic application-library dependencies? Ian -- Ian Dickinson Epimorphics Ltd, Bristol, UK mailto:i...@epimorphics.comhttp://www.epimorphics.com cell: +44-7786-850536 landline: +44-1275-399069 Epimorphics Ltd. is a limited company registered in England (no. 7016688). Registered address: Court Lodge, 105 High St, Portishead, Bristol BS20 6PT, UK - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
Hi Ian, On Mon, Nov 8, 2010 at 4:22 PM, Ian Dickinson i...@epimorphics.com wrote: ...Bertrand wrote: ... 2. A Semantic Commons area is created for common code between these (and other) projects. Details to be discussed, this does probably not warrant a separate Apache project, but might be managed by Clerezza, as they were here first As an Apache newbie it's hard to comment definitively, but it's not clear to me what the common needs of the projects might be, and how dependencies would handled. Are there examples of existing commons areas between Apache projects, other than basic application-library dependencies? The best example is commons.apache.org of course - my idea is that utilities and libraries that might be useful for several of those new semantic projects should be shared whenever possible, to avoid duplication of efforts. As Olivier notes, it's best to create such a commons area only when we really need it, there's no need to define things precisely right now. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
Perhaps db.apache.org would be a better example? Should there be a semantic.apache.org? On Mon, Nov 8, 2010 at 11:51 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi Ian, On Mon, Nov 8, 2010 at 4:22 PM, Ian Dickinson i...@epimorphics.com wrote: ...Bertrand wrote: ... 2. A Semantic Commons area is created for common code between these (and other) projects. Details to be discussed, this does probably not warrant a separate Apache project, but might be managed by Clerezza, as they were here first As an Apache newbie it's hard to comment definitively, but it's not clear to me what the common needs of the projects might be, and how dependencies would handled. Are there examples of existing commons areas between Apache projects, other than basic application-library dependencies? The best example is commons.apache.org of course - my idea is that utilities and libraries that might be useful for several of those new semantic projects should be shared whenever possible, to avoid duplication of efforts. As Olivier notes, it's best to create such a commons area only when we really need it, there's no need to define things precisely right now. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
Hi Donald, On 08/11/10 17:01, Donald Whytock wrote: Perhaps db.apache.org would be a better example? Should there be a semantic.apache.org? I looked around in db.apache.org and I couldn't see anything that said what the goals of that project are, separate from the goals of the individual sub-projects. Where should I be looking? As others have noted, the three semantic web-related projects currently being proposed have rather different objectives and provide different capabilities. I personally don't object in principle to factoring out common code or needs where that's useful, but +1 to Olivier: let's wait until a clear requirement is identified. Ian -- Ian Dickinson Epimorphics Ltd, Bristol, UK mailto:i...@epimorphics.comhttp://www.epimorphics.com cell: +44-7786-850536 landline: +44-1275-399069 Epimorphics Ltd. is a limited company registered in England (no. 7016688). Registered address: Court Lodge, 105 High St, Portishead, Bristol BS20 6PT, UK - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
For me this proposal means we should be aware of possibilities. There is no intention of forcing collaboration on incubating projects. Each project should continue to work on it's own graduation. However there will probably be code that fan be shared. The sharif of appropriate code can only serve to strengthen each of the communities. The key word being appropriate Sent from my mobile device. On 8 Nov 2010, at 17:30, Ian Dickinson i...@epimorphics.com wrote: Hi Donald, On 08/11/10 17:01, Donald Whytock wrote: Perhaps db.apache.org would be a better example? Should there be a semantic.apache.org? I looked around in db.apache.org and I couldn't see anything that said what the goals of that project are, separate from the goals of the individual sub-projects. Where should I be looking? As others have noted, the three semantic web-related projects currently being proposed have rather different objectives and provide different capabilities. I personally don't object in principle to factoring out common code or needs where that's useful, but +1 to Olivier: let's wait until a clear requirement is identified. Ian -- Ian Dickinson Epimorphics Ltd, Bristol, UK mailto:i...@epimorphics.comhttp://www.epimorphics.com cell: +44-7786-850536 landline: +44-1275-399069 Epimorphics Ltd. is a limited company registered in England (no. 7016688). Registered address: Court Lodge, 105 High St, Portishead, Bristol BS20 6PT, UK - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
I sense an iPhone at work here. Would that be Omar Sharif? On Mon, Nov 8, 2010 at 1:04 PM, Ross Gardler rgard...@apache.org wrote: For me this proposal means we should be aware of possibilities. There is no intention of forcing collaboration on incubating projects. Each project should continue to work on it's own graduation. However there will probably be code that fan be shared. The sharif of appropriate code can only serve to strengthen each of the communities. The key word being appropriate Sent from my mobile device. On 8 Nov 2010, at 17:30, Ian Dickinson i...@epimorphics.com wrote: Hi Donald, On 08/11/10 17:01, Donald Whytock wrote: Perhaps db.apache.org would be a better example? Should there be a semantic.apache.org? I looked around in db.apache.org and I couldn't see anything that said what the goals of that project are, separate from the goals of the individual sub-projects. Where should I be looking? As others have noted, the three semantic web-related projects currently being proposed have rather different objectives and provide different capabilities. I personally don't object in principle to factoring out common code or needs where that's useful, but +1 to Olivier: let's wait until a clear requirement is identified. Ian -- Ian Dickinson Epimorphics Ltd, Bristol, UK mailto:i...@epimorphics.com http://www.epimorphics.com cell: +44-7786-850536 landline: +44-1275-399069 Epimorphics Ltd. is a limited company registered in England (no. 7016688). Registered address: Court Lodge, 105 High St, Portishead, Bristol BS20 6PT, UK - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
To make the commons discussion more concrete I would suggest the following items for the commons: - an IRI library - some code to do with vocabularies. - connecting to a URL and doing semweb aware content negotiation (this is typically done badly) (Actually the IRI code should probably be wider, Jena initially used the xerces URI code but then the needs exceeded what they supported) Jeremy On 11/8/2010 7:22 AM, Ian Dickinson wrote: On 08/11/10 15:09, Mattmann, Chris A (388J) wrote: Wow! Jena is proposing to come to Apache??! Yep, the proposal has been under discussion for some time within the project, and Ross is now taking the lead in bringing it publicly into the incubator process. Bertrand wrote: 1. Clerezza, Stanbol and Jena are independent podlings, each aiming for top-level status 2. A Semantic Commons area is created for common code between these (and other) projects. Details to be discussed, this does probably not warrant a separate Apache project, but might be managed by Clerezza, as they were here first. 3. It is expected that those projects will have a number of committers in common, as there are many collaboration possibilities. As an Apache newbie it's hard to comment definitively, but it's not clear to me what the common needs of the projects might be, and how dependencies would handled. Are there examples of existing commons areas between Apache projects, other than basic application-library dependencies? Ian - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
On 11/8/2010 7:14 AM, Olivier Grisel wrote: There is a depedency relationship: - Stanbol is a of application level HTTP services and set of OSGi components that use: - Clerezza as an OSGi service provider which in turn is using: - Jena as a lib for parsing and serializing RDF models and as a SPARQL enabled triple store. Developers of the upstream project should try to take care an not reinvent the wheel and try to move new features and bugfix to upstream if they naturally belong there. I think all of the items I identified are currently in the Jena ballpark, and could safely stay there with this structure. Possibly no need to separate them out However we may want a vocabulary area in Jena where any dependent apache project can commit their specific vocabularies Jeremy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
Indeed this iPhone is a pain in so many ways. Even worse I seem to have become blind to so many of it's useful corrections. I suppose sharing of appropriate code makes more sense than sharif, but I wouldn't mind having Omar around if that can be pulled off. Sent from my mobile device. On 8 Nov 2010, at 18:15, Benson Margulies bimargul...@gmail.com wrote: I sense an iPhone at work here. Would that be Omar Sharif? On Mon, Nov 8, 2010 at 1:04 PM, Ross Gardler rgard...@apache.org wrote: For me this proposal means we should be aware of possibilities. There is no intention of forcing collaboration on incubating projects. Each project should continue to work on it's own graduation. However there will probably be code that fan be shared. The sharif of appropriate code can only serve to strengthen each of the communities. The key word being appropriate Sent from my mobile device. On 8 Nov 2010, at 17:30, Ian Dickinson i...@epimorphics.com wrote: Hi Donald, On 08/11/10 17:01, Donald Whytock wrote: Perhaps db.apache.org would be a better example? Should there be a semantic.apache.org? I looked around in db.apache.org and I couldn't see anything that said what the goals of that project are, separate from the goals of the individual sub-projects. Where should I be looking? As others have noted, the three semantic web-related projects currently being proposed have rather different objectives and provide different capabilities. I personally don't object in principle to factoring out common code or needs where that's useful, but +1 to Olivier: let's wait until a clear requirement is identified. Ian -- Ian Dickinson Epimorphics Ltd, Bristol, UK mailto:i...@epimorphics.comhttp://www.epimorphics.com cell: +44-7786-850536 landline: +44-1275-399069 Epimorphics Ltd. is a limited company registered in England (no. 7016688). Registered address: Court Lodge, 105 High St, Portishead, Bristol BS20 6PT, UK - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
On Mon, Nov 8, 2010 at 6:01 PM, Donald Whytock dwhyt...@gmail.com wrote: Perhaps db.apache.org would be a better example? Should there be a semantic.apache.org?... That's a possibility, but I would keep such a website for information that's common to ASF semantic projects, as opposed to making it an umbrella project. db.apache.org (and http://ws.apache.org/) are such umbrella projects that group a number of more or less closely related subprojects. The current trend is to move away from such umbrella projects, so that top-level projects are clearly focused and their PMCs can work towards a clearly defined set of goals. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
On 08/11/10 18:32, Jeremy Carroll wrote: To make the commons discussion more concrete I would suggest the following items for the commons: - an IRI library - some code to do with vocabularies. - connecting to a URL and doing semweb aware content negotiation (this is typically done badly) (Actually the IRI code should probably be wider, Jena initially used the xerces URI code but then the needs exceeded what they supported) Jeremy Good idea. The IRI code is independent of the rest of Jena and is valuable in it's own right. ARP (Jena RDF/XML parser) is also independent of the Jena code structure and once was (is it still possible to get just ARP?). It's just the final step of generation that turns the output of parsing into Jena-specific objects. Might be worth splitting out if it would be useful. The lowest level of RIOT parsing, which defines the tokens for creating any of the Turtle family of langauges, is not Jena dependent. The actual RIOT parsers themselves are as they directly generate Jena-specific objects to avoid the copy overhead. It's a performance trade-off. [RIOT is a set of faster parsers for non-XML serializations of RDF, currently part of ARQ, but should migrate to Jena core when fully stable. - original need was parsers for formats capable of delivering to the TDB database at full loading speed without heavy CPU load.] But the command line tools based on RIOT which parse or validate one format are reusable - they use Jena internally, but the input and output are completely standard. The RDF validator Eyeball is also a useful tool in its own right. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?
On 08/11/10 17:30, Ian Dickinson wrote: Hi Donald, On 08/11/10 17:01, Donald Whytock wrote: Perhaps db.apache.org would be a better example? Should there be a semantic.apache.org? I looked around in db.apache.org and I couldn't see anything that said what the goals of that project are, separate from the goals of the individual sub-projects. Where should I be looking? As others have noted, the three semantic web-related projects currently being proposed have rather different objectives and provide different capabilities. I personally don't object in principle to factoring out common code or needs where that's useful, but +1 to Olivier: let's wait until a clear requirement is identified. I agree. I don't think that a semantic XYZ is useful if that makes semantic some sort of different software. Semantic web technology is getting used more widely and a semantic commons or formal grouping of projects risks creating the idea that it's all or nothing, which isn't the case, hopefully. Andy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
