2011/7/5 Enrico Daga <[email protected]>: > 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?).
Yes, I think that's the point here. Cut the problems into smaller pieces that others can follow and create issues for each sub-problem. The commit message was then misleading in this case. >> >> 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 > -- Fabian
