On 5 July 2011 10:04, Bertrand Delacretaz <[email protected]> wrote: > On Tue, Jul 5, 2011 at 7:55 AM, Fabian Christ > <[email protected]> wrote: >> 2011/7/4 <[email protected]>: >>> ...STANBOL-249 : >>> - temp hacks for integritycheck demos: session space is automatically >>> attached; classify writes and reads ontology back before classifying >> >> IMO such "temp hacks" should never be in the stable trunk of the >> source tree, In my opinion (but it is only my personal opinion), the trunk is currently the development area. Jenkins assure that committed code compiles correctly. Integration tests assure that rest services work properly and demos assure that functionalities are working as expected.
Working on trunk, developers are forced to take care of the whole project while developing their code, so don't loosing time when they discover that their component doesn't work when put in the whole stack (2 months needed to take old-kres components out of the 'kres' profile). In this scenario (which is something that is happening in this project, not a rule) branches should be used by developers who *do not want* have the problem of integration because they are experimenting *or* because they feel not sure about the stability of their code (and - apart from the compiling aspects - this is subjective). Releases is something different, we will select modules that will be in the release and maybe decide if this would require a redesign of the svn folders (I would do tags for releases, for example). If we want to define new criterias about what should be in trunk I am available, but I feel that top down decisions would not benefit the result, at this time. I am open to discuss this, if you wish. >> What does it mean in terms of functionality for other >> users? How long will the "temp" hack survive? Perhaps in this case >> nobody cares but we should create branches for such hacks if there are >> really needed at all.... What alessandro is calling hack is a solution to solve a functionality issue wrt to rdf data which is NOT an owl ontology when it is loaded by owlapi. Such model would not work on reasoners because the owlapi loads the assertions as annotations, because the RDF does not contain the description of the classes and properties used. In other terms, loading dbpedia entities rdf as owl ontology imply you have an ontology without any useful axiom for a reasoner, except "type of" information. This is obviously a major issue for the ontonet module, and is only indirectly related to the demo. The workaround for that (not a hack, because it works perfectly, it is only that is not an 'elegant' solution, this is why alessandro wrote 'hack' - but of course this is subjective...) is to reload the whole set of axioms from an rdf serialization. At that point the owlapi manager will find the ontology within the scope and the data within the session all in the same "ontology", thus creating working axioms for properties. IMO the problem is that this comment is too vague and things must be explained better in commit comments/jira issues (Alessandro let's say you where in a hurry, right?). > > Or at least immediately create a JIRA issue that's about removing > those hacks, so that we don't forget to cleanup. Depends on how bad > the hacks are I guess. Of course this is something that __must__ be fixed, moving the solution to how the ontonet session loads the data. This must be done carefully, since this one yes, is a change that could impact on the whole ontonet-rules-reasoners stack. We must open issues for problems found while developing the integritycheck demo asap, since demos are acceptance tests, in our case, right? Enrico > > -Bertrand > -- Enrico Daga -- http://www.enridaga.net skype: enri-pan
