Linked Bug Data
Myriam Leggieri
I'm going to create linked bug data for a statistical sw development
analysis application, which collects bug data from sensors attached to
bug-trackers. I'd like to use Baetle to describe these bug data and
I've read somewhere that you're developing this ontology to make it
compatible with linked Data.
But which are the bug info that you're considering useful to state
that two bugs should be linked because similar? are they the IDs or
the bug summaries?
And, finally, are out there bug-trackers or tools applied to bug-
trackers, that are already publishing bug data using Baetle? I can't
find any list.
Or the only chance for me is to link web pages or XML (such as
http://www.netbeans.org/issues/xml.cgi?id=18177 ) instead of other
linked data as Linked Data principles would like me to do?
Thanks a lot in advance to everyone who would be so kind ^_^ to answer
me
cheers,
myriam
Daniel O'Connor
And, finally, are out there bug-trackers or tools applied to bug-
trackers, that are already publishing bug data using Baetle? I can't
find any list.
PEAR is:
http://pear.php.net/feeds/bug_14969.rss
and the PHP project might also be doing so soon too (maybe) - http://svn.php.net/viewvc?view=revision&revision=283768
Neither of these systems will currently point from one bug to another with a "this is the same as" assertation.
Henry Story
On 16 Jul 2009, at 01:03, Daniel O'Connor wrote:
> On Wed, Jul 15, 2009 at 8:27 PM, Myriam Leggieri
> <myriam....@gmail.com>wrote:
>>
>> And, finally, are out there bug-trackers or tools applied to bug-
>> trackers, that are already publishing bug data using Baetle? I can't
>> find any list.
>
>
> PEAR is:
> http://pear.php.net/feeds/bug_14969.rss
as it may introduce some intellectual property issues.
As a matter of interest would it not have been possible to use the
EvoOnt ontology?
http://www.ifi.uzh.ch/ddis/evoont.html
That has a namespace, and we even have a thesis on it.
Henry
Toby Inkster
> I just asked Dan Brickley, and he'd rather we not use that namespace,
> as it may introduce some intellectual property issues.
I'm happy to lend ontologi.es. Also, on vocab.org, Ian says he's happy
to host people's things. Some DERI people are probably on this list too,
who may be able to offer hosting on rdfs.org.
And of course, there's always purl.org, which it may be wise to use for
redirection no matter where you decide to host the ontology's schema.
--
Toby A Inkster
<mailto:ma...@tobyinkster.co.uk>
<http://tobyinkster.co.uk>
Myriam Leggieri
thanks a lot for your answer ;)
What I'm trying to do consists in:
I have a bug identified by a BugUri#5 on my localhost, and I want to
crawl external datasets available on the Web to search for other bugs
linkable with BugUri#5 through a rdfs:seeAlso predicate.
I've been suggested to search for an explicit reference to BugUri#5 in
the summary or description section of other external bugs. In this
way, however, it's necessary that other developers already know the
existence of my BugUri#5, otherwise there cannot be any explicit
reference to it in other bugs descriptions...this is a great
constraint and if someone knows a better way to check wether a
rdfs:seeAlso predicate can be used to link two bugs, please tell me.
However even using this mechanism to determine if two bugs are
linkable, I need to browse the external bug dataset; in other words I
need that these external datasets provide a Sparql endpoint. Moreover
I need to know the hosts of these datasets to send them requests, and
that's why I asked for them in my previous post.
> PEAR is:http://pear.php.net/feeds/bug_14969.rss
Does Pear provide a Sparql endpoint?
However alternatively to having a list of hosts publishing their bug
data using Baetle, I could, maybe, link a 'class' representing a
particular kind of hosts (such as 'Bug')and then automatically link
every instance of it, as proposed by Umbel (http://www.umbel.org/).
Does anyone know if this is possible or has already done it in the
past?
cheers ;)
myriam
Daniel O'Connor
way, however, it's necessary that other developers already know the
existence of my BugUri#5, otherwise there cannot be any explicit
reference to it in other bugs descriptions...this is a great
constraint and if someone knows a better way to check wether a
rdfs:seeAlso predicate can be used to link two bugs, please tell me.
I would take a look at Launchpad for a system that does both handling of external bug references and integration with a number of bug trackers.
It's not RDF, but it might give you insights on the best ways to do this; or code to do so.
They've got "56898 links to 525 bug trackers"
However even using this mechanism to determine if two bugs are
linkable, I need to browse the external bug dataset; in other words I
need that these external datasets provide a Sparql endpoint. Moreover
I need to know the hosts of these datasets to send them requests, and
that's why I asked for them in my previous post.
Does Pear provide a Sparql endpoint?
Fraid not, we're only just publishing a little rdf around the place at the moment.
Olivier Berger
(Apologies for not responding earlier, and Btw, some of the messages
you've sent were pretty hard to read, as they were quoted in a strange
way. I'd suggest not to use HTML on public lists, but it's just my
humble opinion.)
Le mercredi 15 juillet 2009 à 03:57 -0700, Myriam Leggieri a écrit :
> Hi everyone,
> I'm going to create linked bug data for a statistical sw development
> analysis application, which collects bug data from sensors attached to
> bug-trackers.
Quite interesting. In which context are you doing that ?
> I'd like to use Baetle to describe these bug data and
> I've read somewhere that you're developing this ontology to make it
> compatible with linked Data.
Excellent.
We're trying to work in a similar direction in the frame of the Helios
project (see
https://picoforge.int-evry.fr/cgi-bin/twiki/view/Helios_wp3/Web/ ), and
are working at providing RDF output for different bugtrackers.
> But which are the bug info that you're considering useful to state
> that two bugs should be linked because similar? are they the IDs or
> the bug summaries?
>
I don't know for similarities that could be 'auto-magically' detected,
but what I know is that once a software maintainer has identified such
relations between bugs, it'd be interesting to be able to represent them
in ontologies.
We're working at describing such links, for instance in order to
represent links between "upstream" bugs and "distribution" bugs in the
context of Open Source projects (like the forwarded-to property in
debbugs). See more details in :
http://www-public.it-sudparis.eu/~berger_o/weblog/2009/06/06/presentation-at-wopdasd-2009-weaving-a-semantic-web-across-oss-repositories-a-spotlight-on-bts-link-udd-swim/ for instance.
> And, finally, are out there bug-trackers or tools applied to bug-
> trackers, that are already publishing bug data using Baetle? I can't
> find any list.
Dunno for beatle, but I expect soon to be able to provide EvoOnt BOM at
least for some bugzillas or for Debian's debbugs.
SNIP
> Thanks a lot in advance to everyone who would be so kind ^_^ to answer
> me
> cheers,
> myriam
>
I hope this sheds some light on our efforts, and you'll be interested.
Best 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)
Myriam Leggieri
your info and the Helios project are really interesting, thanks so
much for sharing ;)
> Quite interesting. In which context are you doing that ?
> Dunno for beatle, but I expect soon to be able to provide EvoOnt BOM at
> least for some bugzillas or for Debian's debbugs.
data linkable with mine: let me know as you'll publish a way to
perform searches over your data (through a Sparql endpoint or an URI
lookup endpoint or anything else).
As far as issue datasets to link would be so few I won't search for
them using a semantic search engine, however I'll publish (and it
would be better if everyone does the same) a sitemap that will
describe my dataset using voID ontology and classes coming from Umbel,
to facilitate the retrieval of my own dataset also to whom is using a
semantic search engine.
However I've read you owl ontology and I think there are lots of
properties and classes linkable to Baetle's ones
cheers
myriam
P.S.
I'm sorry for your troubles in reading my messages: I didn't know that
HTML could cause such problems in public lists and I'll try to not
repeat my error ;)
Olivier Berger
> Hi Olivier
> your info and the Helios project are really interesting, thanks so
> much for sharing ;)
>
> > Quite interesting. In which context are you doing that ?
>
> this is the project I'm working on: http://code.google.com/p/hackystat-linked-sensor-data/
>
Btw, we've published a test server (see my previous post on this baetle
list).
You'll find linked bugs there in
http://kilauea.int-evry.fr:8081/triplify/UDD/forwardedupstream/nnnnn
where nnnnn is a Debian bug # for every bugs in Debian which have been
processed by bts-link. For instance,
http://kilauea.int-evry.fr:8081/triplify/UDD/forwardedupstream/35779
Hope this helps,
>
> > Dunno for beatle, but I expect soon to be able to provide EvoOnt BOM at
> > least for some bugzillas or for Debian's debbugs.
>
> I'm definitely interested because you could become a new source of
> data linkable with mine: let me know as you'll publish a way to
> perform searches over your data (through a Sparql endpoint or an URI
> lookup endpoint or anything else).
> As far as issue datasets to link would be so few I won't search for
> them using a semantic search engine, however I'll publish (and it
> would be better if everyone does the same) a sitemap that will
> describe my dataset using voID ontology and classes coming from Umbel,
> to facilitate the retrieval of my own dataset also to whom is using a
> semantic search engine.
>
> However I've read you owl ontology and I think there are lots of
> properties and classes linkable to Baetle's ones
> cheers
> myriam
>
> P.S.
> I'm sorry for your troubles in reading my messages: I didn't know that
> HTML could cause such problems in public lists and I'll try to not
> repeat my error ;)
> >
Henry Story
On 30 Jul 2009, at 13:58, Olivier Berger wrote:
>>
>> this is the project I'm working on: http://code.google.com/p/hackystat-linked-sensor-data/
>>
>
> Very interesting also !
>
> Btw, we've published a test server (see my previous post on this
> baetle
> list).
>
> You'll find linked bugs there in
> http://kilauea.int-evry.fr:8081/triplify/UDD/forwardedupstream/nnnnn
> where nnnnn is a Debian bug # for every bugs in Debian which have been
> processed by bts-link. For instance,
> http://kilauea.int-evry.fr:8081/triplify/UDD/forwardedupstream/35779
Nice. As it uses the evo-ont ontology, perhaps we should now start
moving the whole wiki page to use describe the evo-ont ontology, as it
is a lot more mature than baetle. What do people think here? I like
the baetle name, so perhaps we can just keep that :-)
Henry
Erling Wegger Linde
Nice to see things moving here. This is great =)
I agree with Henry that we should archive the "old" baetle ontology
drafts and update the wiki with information on the evo-ont ontology.
It is a bit confusing right now.
I agree that evo-ont BOM is not a good name - baetle is definitely
more catchy.
Cheers,
Erling
Olivier Berger
> Hi all!
>
> Nice to see things moving here. This is great =)
>
> I agree with Henry that we should archive the "old" baetle ontology
> drafts and update the wiki with information on the evo-ont ontology.
> It is a bit confusing right now.
>
> I agree that evo-ont BOM is not a good name - baetle is definitely
> more catchy.
Maybe it'd be possible to just identify shortcomings of EvoOnt BOM and
make baetle an improved BOM ?
For instance, in our Helios BT experiments
(https://picoforge.int-evry.fr/cgi-bin/twiki/view/Helios_wp3/Web/HeliosBtOntology) we've started adding a few things that were missing from EvoOnt BOM, like relations between bugs.
Btw, I just saw that bugzilla 3.4 will include such a seeAlso field to
link bugs between different bugtrackers, so our relations like :
isDuplicateOf, isMergedInto or reportedAlsoIn may become more useful
soon.
Just my 2 cents,