Baetle future - refocusing the purpose considering recent activity in this area ?
Olivier Berger
I'd like to share a few thoughts about baetle, and how/where future work
should lead us, hoping to receive interesting feedback.
There are at the moment very interesting things happening on OSLC-CM
side (see my previous post :
http://groups.google.com/group/baetle/browse_thread/thread/82d5348aafa7c70e ) mainly in the area of REST APIs to allow interoperability between bugtrackers and other tools.
One of the main interests is the support of the OSLC-CM specs by Mylyn,
that may establish it as a defacto standard. We can hope that most
bugtrackers will some day support those specs.
The current process in OSLC-CM is to try and review the set of change
request properties (read bug properties) to be included in the next
revision of the standard.
I think the work that has been done in baetle could be reused by OSLC,
for sure.
They have a roadmap with milestones, so I think there will be a
continuous effort there that must be considered in terms of bug
interchange formats, ontologies, etc. (and the IP regime seems OK to
me).
We have ourselves been working on modeling bugs starting from EvoOnt, to
reach a first draft of ontology at :
https://picoforge.int-evry.fr/cgi-bin/twiki/view/Helios_wp3/Web/HeliosBtOntology which I think represents a progress compared to previous works.
We'll make good progress (I hope ;) in the 2 coming years, as we're busy
in the rest of the Helios project and the recently started COCLICO
project on forges interop, and will be developing http://fetchbugs4.me/,
etc.
I think Henry is no longer very much interested in working on baetle,
being more busy with the social semantic web (FOAF+SSL, etc.). Having
discussed with him a couple weeks ago, I think he hopes someone can take
care of Baetle for the better (hence my shaking the tree for feedback).
I see a lot of fragmented initiatives and none having delivered really
so far, so I'm trying to figure out if / how baetle should be positioned
in the current landscape, to avoid people implementing on obsolete
technology and similar dead-ends ;)
Maybe it's time to officially declare the baetle ontology, as it was
drafted in the SVN, something obsolete, and try and think more about
OSLC-CM in terms of implementation in bugtrackers ?
Maybe there could be somehow separate groups/communities/initiatives to
consider if working on bug modeling, standards and such :
- OSLC-CM on *low-level* bug-reports properties, as they are to
be managed in interchanges and APIs between bugtrackers and
other tools (low-level document format for bug reports,
tooling) ?
- Baetle / EvoOnt / Helios_BT (whatever it is named) being more
a *high-level* ontology that would correspond to modeling of
bugs in a larger ecosystem of Semantic Web resources, in terms
of projects, packages, real bugs in the code, quality analysis,
software evolution, mining, LOD and Sem Web, etc.
I'm not so sure about such distinctions, but my idea is that maybe
OSLC-CM covers more the bug *reports* (converters between properties,
implementation, tooling) and Baetle/etc. is more about links between
*bugs* (real ones in the code), links with the bug reports (in different
bugtrackers of Distributions), the navigation in all interlinked bugs on
the same packages, their annotations and general presence on the Social
Semantic Web (links with people interested), communities solving issues,
etc.
In the end, my only concern is the more efficient way to move towards
delivery of standards for interoperability at all levels, and avoiding
people reinventing similar wheels in parallel dimensions.
I hope this will receive constructive comments from you all ;)
... And in the meantime, I'm going to try and introduce the OSLC-CM
people to the work done in baetle.
Regards,
--
Olivier BERGER <olivier...@it-sudparis.eu>
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France)
Abraham Bernstein
When we at the University of Zurich (UZH) started our work we had to
goal of supporting software (evolution) analysis and mining in the
spirit of the International Working Conference on Mining Software
Repositories (MSR). EvoOnt can successfully support many of the analyzes
typically performed by authors of MSR publications.
We then hooked up with Henry and discussed folding the baetle & EvonOnt
efforts together. The result is that we posted EvoOnt on the baetle list
and many people seem to have used as a starting point. We never claimed
it is perfect or complete and have heard of a number of extensions over
the years.
Note that one of the major goals of EvoOnt was always to integrate bug,
source-code, and version information, since many analyzes struggle with
doing so. Indeed, such an integration is a nun-trivial problem (see our
ESEC/FSE 2009 paper on that subject).
I am very happy to see that new usages emerge. One usage is the one you
are describing, using such ontologies as a real-time exchange (rather
than analysis) format. This may, as you describe, require some
lower-level extensions. Luckily, it is exactly one of the core features
of OWL that allow for the simple extension of ontologies.
I agree with you that we might want to go towards some form of
consolidation. Such a consolidation might look as follows:
1) We meet (physically at one of the typical conferences or virtually)
to discuss:
- possible extensions to EvoOnt
- what extensions to keep outside EvoOnt (as supported by OWL) and
which ones to integrate
- what changes EvoOnt should undergo to serve as an upper ontology
(what you call high-level)
2) We participate in the efforts to standardize some of the exchange
formats and try to
establish lower-level ontologies to that end.
The OSLC-CM effort is one area of possible participation. I know of
similar efforts
that aim at lower level OWL-based software specification.
Any thoughts?
Best
Avi Bernstein
| Professor Abraham Bernstein, PhD
| University of Zürich, Department of Informatics
| web: http://www.ifi.uzh.ch/ddis/bernstein.html
Henry Story
On 21 Oct 2009, at 18:22, Olivier Berger wrote:
> I think Henry is no longer very much interested in working on baetle,
> being more busy with the social semantic web (FOAF+SSL, etc.). Having
> discussed with him a couple weeks ago, I think he hopes someone can
> take
> care of Baetle for the better (hence my shaking the tree for
> feedback).
I am interested, but I don't have the bandwidth currently... (which
comes to the same thing somewhat)
I would suggest linking your efforts up with the Linded Data movement,
because that is really what you are trying to do here. They have been
very successful, and I think they could all see the advantage of
helping open up bug databases.
http://lists.w3.org/Archives/Public/public-lod/
Really all the tools are there now. The ontology can't be that far off
from what is needed.
If they were able to open up all those databases it can't really be
that difficult to do the same with bugs.
Henry
Olivier Berger
Le samedi 24 octobre 2009 à 16:00 +0200, Abraham Bernstein a écrit :
> Dear Oliver, dear all
>
SNIP
>
> I agree with you that we might want to go towards some form of
> consolidation.
:-)
> Such a consolidation might look as follows:
>
> 1) We meet (physically at one of the typical conferences or virtually)
That'd be great to have IRL meeting, but may eventually be difficult as
we probably live in somewhat parallel universes (see how we managed to
work on similar subjects with the OSLC people for one year without ever
getting in touch)... so I hope we can build succesful collaboration
on-line for the moment ;)
> to discuss:
> - possible extensions to EvoOnt
We're currently working on such matters (at least for BOM), with respect
to bug traceability between development and packaging projects mainly,
see [0].
> - what extensions to keep outside EvoOnt (as supported by OWL) and
> which ones to integrate
I'm currently thinking about keeping some of the low-level things that
OSLC-CM V1 models (see [1]) outside of EvoOnt/Baetle (actually these are
only DC elements, essentially), even though some OWL "reasoning" may be
sufficient here... but I suppose that keeping only EvoOnt/Baetle for
upper layer would be best.
> - what changes EvoOnt should undergo to serve as an upper ontology
> (what you call high-level)
About the rest of EvoOnt not specifically related to Bugs modeling, I
think theres a great need for some standardization in order to foster
interoperability between tools and contribution to SemWeb.
We'll work on these matters as part of the COCLICO project for the next
2 years (see [3]). But this becomes a little bit off-topic here, as it
encompasses much more than bug reports / bugtrackers ;)
Back to baetle and bugs, in any case, I'd very much propose to "kill"
the original baetle ontology (the one from [2]), to avoid people
implementing things on top of it, since both EvoOnt and OSLC6CM seem to
be the future.
>
> 2) We participate in the efforts to standardize some of the exchange
> formats and try to
> establish lower-level ontologies to that end.
> The OSLC-CM effort is one area of possible participation. I know of
> similar efforts
> that aim at lower level OWL-based software specification.
I'd appreciate any pointers on these efforts.
>
> Any thoughts?
>
Glad to see your continued interest. Thanks for the feedback.
> Best
>
> Avi Bernstein
>
[0] : https://picoforge.int-evry.fr/cgi-bin/twiki/view/Helios_wp3/Web/HeliosBtOntology
[1] : http://open-services.net/bin/view/Main/CmResourceDefinitionsV1?sortcol=table;up=#XML_Representation_of_the_Change
[2] : http://code.google.com/p/baetle/source/browse/ns/
[3] : http://www.coclico-project.org/index.php/WP2_en
Best regards,
Olivier Berger
>
> On 21 Oct 2009, at 18:22, Olivier Berger wrote:
> > I think Henry is no longer very much interested in working on baetle,
> > being more busy with the social semantic web (FOAF+SSL, etc.). Having
> > discussed with him a couple weeks ago, I think he hopes someone can
> > take
> > care of Baetle for the better (hence my shaking the tree for
> > feedback).
>
> I am interested, but I don't have the bandwidth currently... (which
> comes to the same thing somewhat)
I hope you're busy for the best (FOAF+SSL, etc.) ;)
>
> I would suggest linking your efforts up with the Linded Data movement,
> because that is really what you are trying to do here. They have been
> very successful, and I think they could all see the advantage of
> helping open up bug databases.
>
> http://lists.w3.org/Archives/Public/public-lod/
>
> Really all the tools are there now. The ontology can't be that far off
> from what is needed.
>
> If they were able to open up all those databases it can't really be
> that difficult to do the same with bugs.
>
That's really one of the targets / side effects of our work that I'd
like to foster : bugtrackers no longer being silos but good citizens of
Web 3.
I'm already hanging around on LOD list and will probably try and push
there... but first we need some code working (hence fetchbugs4.me which
lags behing ATM ... too many thinks so few hours :-( )
> Henry
>
Best regards,