[OSLC-CM] Reusing results from baetle and others... links/distinction with/from other efforts ?

[Olivier Berger]

Hi.

(appologies for this long meta- rant in advance)

I'm wondering if the work conducted in the frame of the baetle project
("Bug And Enhancement Tracking LanguagE" :
http://code.google.com/p/baetle/) or in EvoOnt BOM have been
identified / considered for the next step of CM CommonProperties
modeling ? 

I'm trying and make useful connections with prior art on modeling with
ontologies, RDF and such, and to think about the semantic distinctions
that may need to be made.


I think there's a very good overlap concerning the mapping of CR
attributes and the bug reports properties modeled in baetle :
http://code.google.com/p/baetle/wiki/Bugtrackers2baetleMappings

Also, we have been working on reviewing opensource bugtracker bug
reports attributes and their mapping to EvoOnt BOM (see arly mapping
that had been done in
http://code.google.com/p/baetle/wiki/EvoOntBomMappings

That's good news : in general, I think open source bugtrackers are quite
well mapped by the current proposed CmCommonProperties (but will provide
more detailed feedback in other mail).


I'm also worried (mainly since we worked for one year without any
contacts although we tried our best to review current similar efforts)
and thinking about reducing fragmentation of efforts conducted in
parallel dimensions, so I hope there will be more merging between people
that have started implementing baetle or other ontologies and OSLC in
preparing OSLC-CM V2.


I think there may be several layers about (CR / bugs / issues)
modeling :

        - the need of standards for tooling, APIs, integration and
        interchange between bugtrackers and other tools in software ALM
        scenarii, where OSLC-CM would be leading the standardization
        efforts,
        
        - and maybe a somewhat higher level modeling of Semantic Web /
        Linked Open Data / Software evolution and other Social Semantic
        aspects relating to Open Source software bugs management that
        may be covered by different (still interoperable) standards, and
        that may be elaborated by a slightly different community, with
        different use cases (like those mentioned in the baetle project,
        or for our R&D activity on large scale bug tracking on the
        SemWeb)
        

I think that such a perspective may help separate CR attributes in
different categories which would then probably be modeled using
different ontologies in order to better manage their respective
evolutions (different use cases, different communities, etc.)


For instance, for "higher level" bug monitoring in the general Open
Source landscape, links between bug reports that are duplicated in
different bugtrackers require that the links between software packages
and bug reports are established (think about gathering all bug reports
on Firefox in all GNU/Linux distributions).
These links may correspond to the (lower-level) Products and Components
categorizations of reports in one bugtracker, but not necessarily (think
about the tons of packages (components) managed in RedHat or Debian...
are these components ?).
So 2 (or more) different ontologies may be used to describe "software
packages" on one side and "bugtracker components" on the other one,
which may eventually be interlinked by some kind of reasoning ?.


Depending on people's concerns with bug modeling, standardization may
then be discussed in the most appropriate community (if not merged ;).


How does this description of the current efforts and separation of
concerns sound to you ?

In our own case, all aspects are interesting, so I'm trying to bridge
all potential communities by posting in different places about these
concerns, still trying to figure out where to discuss what ;)

Best regards,

-- 
Olivier BERGER <olivier.berger at 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)