[long] Re: Mapping bugzilla bugs to RDF as EvoOnt BOM ontology : RFC
Olivier Berger
olivier.berger at it-sudparis.eu
Wed Aug 5 10:56:27 UTC 2009
Le mardi 04 août 2009 à 17:05 -0700, Max Kanat-Alexander a écrit :
> Olivier Berger wrote:
> > FYI, as part of our work on the Helios project [0], we've devised a
> > prototype of a small app based on triplify [1] to export data about
> > Bugzilla bugs as RDF, using the EvoOnt BOM [2] ontology (and
> > extensions).
>
> Hey Olivier! I think the first question that we'd have is--could you
> explain to us how the RDF generated by triplify is different and more
> useful than the RDF normally generated by Bugzilla itself for a buglist?
> I don't think any of us (or at least, very few of us) are familiar with
> triplify.
>
Yes, obvious questions, of course.
To make it short, we're trying to produce "real" standard-based RDF,
containing resources, classes, etc. and using ontologies that are not
application specific, in order to foster interoperability, and make sure
that such RDF can participate the LinkedData ecosystem.
Here triplify is just one such tool that can do RDBMS to RDF conversion,
to serve as a demonstrator, but of course this is just to have a
reference, and such RDF should ideally be produced by Bugzilla itself,
IMHO.
Long version bellow. Pardon me in advance if I'm a bit pedantic... as
I'll try and explain what I find great in RDF and standard ontologies.
<RDF lesson>
RDF is just about triples like "subject verb object". And the magic of
it is to allow to embed, in the same document (for instance as XML+RDF)
several schema/ontologies which describe the same object/resource.
On which ontologies are used to do so, depend the usefulness of such
data, and its ability to interlink resources on the Semantic Web.
Compared to traditional XML (with DTDs for instance), RDF brings
*semantics*, which can be agreed on, in turn benefiting to
interoperability.
</RDF lesson>
In the case of the bugzilla RDF (which if I understand it well, is
acquired by using &ctype=rdf in some CGIs), it's RDF, but it's not so
much more interesting, I would say, than what you get in the classical
XML output.
For instance, the severity, priority, status and other such fields are
not typed...
<bz:bug rdf:about="https://bugzilla.mozilla.org/show_bug.cgi?id=177692">
<bz:id nc:parseType="Integer">177692</bz:id>
<bz:bug_severity>normal</bz:bug_severity>
<bz:priority>--</bz:priority>
<bz:op_sys>All</bz:op_sys>
<bz:assigned_to>general@bugzilla.bugs</bz:assigned_to>
<bz:bug_status>NEW</bz:bug_status>
<bz:resolution></bz:resolution>
<bz:short_desc>normalize column names and make them consistent with those reflected externally in RDF</bz:short_desc>
</bz:bug>
Here, there's not much semantics that you can extract from it, as it
doesn't relate to standard ontologies, nor to real Semantic Web
resources.
By comparison, we're seeking to provide RDF which would use more
Semantically-defined ontologies, which would help render such RDF
consuming applications interoperable with any bugtracker. We're trying
to reuse as much as possible standard ontologies (FOAF, SIOC, DC etc.),
and to propose a standard for bugs description (based on EvoOnt BOM)
For instance, when dealing with relationships between user accounts on
the bugzilla and (real) people, and the bugs they submitted, we
implement links between a resource in a bug ontology (EvoOnt BOM's
"Issue" class), an account (SIOC's "User" class) and a person (FOAF's
"Person" class).
It gives things like (converted from the triplify output):
<rdf:RDF
xmlns:bom="http://www.ifi.uzh.ch/ddis/evoont/2008/11/bom#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:foaf="http://xmlns.com/foaf/0.1/"
xmlns:helios_bt="http://picoforge.int-evry.fr/projects/svn/helios_wp3/helios_bt.owl#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:s="http://www.w3.org/2000/01/rdf-schema#"
xmlns:sioc="http://rdfs.org/sioc/ns#">
<foaf:Person rdf:about="http://kilauea.int-evry.fr:8081/triplify/bugzilla/person/1">
<s:seeAlso rdf:resource="http://kilauea.int-evry.fr:8081/triplify/bugzilla/user/1"/>
<foaf:holdsAccount rdf:resource="http://kilauea.int-evry.fr:8081/triplify/bugzilla/user/1"/>
<foaf:mbox_sha1sum>6688a14521cd97db162af8f9757f2e2232300e50</foaf:mbox_sha1sum>
<foaf:name>Olivier Berger</foaf:name>
</foaf:Person>
<sioc:User rdf:about="http://kilauea.int-evry.fr:8081/triplify/bugzilla/user/1">
<sioc:email_sha1>6688a14521cd97db162af8f9757f2e2232300e50</sioc:email_sha1>
<bom:isReporterOf rdf:resource="http://kilauea.int-evry.fr:8081/triplify/bugzilla/issue/1"/>
<s:label>Olivier Berger</s:label>
<s:seeAlso rdf:resource="http://kilauea.int-evry.fr:8081/triplify/bugzilla/person/1"/>
</sioc:User>
<bom:Issue rdf:about="http://kilauea.int-evry.fr:8081/triplify/bugzilla/issue/1">
<dc:title>make_snapshot script complains on error</dc:title>
<bom:bugURL>http://erty.int-evry.fr/bugzilla/show_bug.cgi?id=1</bom:bugURL>
<bom:hasAssignee rdf:resource="http://kilauea.int-evry.fr:8081/triplify/bugzilla/user/1"/>
<bom:hasComputerSystem rdf:resource="http://kilauea.int-evry.fr:8081/triplify/bugzilla/computersystem/42"/>
<bom:hasPriority rdf:resource="http://picoforge.int-evry.fr/projects/svn/helios_wp3/helios_bt.owl#BugzillaPriorityP2"/>
<bom:hasReporter rdf:resource="http://kilauea.int-evry.fr:8081/triplify/bugzilla/user/1"/>
<bom:hasResolution rdf:resource="http://picoforge.int-evry.fr/projects/svn/helios_wp3/helios_bt.owl#BugzillaResolutionFIXED"/>
<bom:hasSeverity rdf:resource="http://picoforge.int-evry.fr/projects/svn/helios_wp3/helios_bt.owl#BugzillaSeveritynormal"/>
<bom:hasState rdf:resource="http://picoforge.int-evry.fr/projects/svn/helios_wp3/helios_bt.owl#BugzillaStateRESOLVED"/>
<bom:isInProduct rdf:resource="http://kilauea.int-evry.fr:8081/triplify/bugzilla/product/2"/>
<bom:isIssueOf rdf:resource="http://kilauea.int-evry.fr:8081/triplify/bugzilla/component/2"/>
<s:label>Bug 1</s:label>
</bom:Issue>
</rdf:RDF>
I hope you can see the difference (yes, I know, it's verbose ;-)
Another way to see it, as turtle, may be more human friendly :
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix s: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix dc: <http://purl.org/dc/elements/1.1/>.
@prefix sioc: <http://rdfs.org/sioc/ns#>.
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix owl: <http://www.w3.org/2002/07/owl#>.
@prefix bom: <http://www.ifi.uzh.ch/ddis/evoont/2008/11/bom#>.
@prefix helios_bt: <http://picoforge.int-evry.fr/projects/svn/helios_wp3/helios_bt.owl#>.
<http://kilauea.int-evry.fr:8081/triplify/bugzilla/person/1>
a foaf:Person ;
foaf:name "Olivier Berger" ;
foaf:mbox_sha1sum "6688a14521cd97db162af8f9757f2e2232300e50" ;
foaf:holdsAccount <http://kilauea.int-evry.fr:8081/triplify/bugzilla/user/1> ;
s:seeAlso <http://kilauea.int-evry.fr:8081/triplify/bugzilla/user/1> .
<http://kilauea.int-evry.fr:8081/triplify/bugzilla/user/1>
a sioc:User ;
s:label "Olivier Berger" ;
sioc:email_sha1 "6688a14521cd97db162af8f9757f2e2232300e50" ;
s:seeAlso <http://kilauea.int-evry.fr:8081/triplify/bugzilla/person/1> ;
bom:isReporterOf <http://kilauea.int-evry.fr:8081/triplify/bugzilla/issue/1> .
<http://kilauea.int-evry.fr:8081/triplify/bugzilla/issue/1>
a bom:Issue ;
s:label "Bug 1" ;
dc:title "make_snapshot script complains on error" ;
bom:bugURL "http://erty.int-evry.fr/bugzilla/show_bug.cgi?id=1" ;
bom:hasAssignee <http://kilauea.int-evry.fr:8081/triplify/bugzilla/user/1> ;
bom:hasComputerSystem <http://kilauea.int-evry.fr:8081/triplify/bugzilla/computersystem/42> ;
bom:hasPriority helios_bt:BugzillaPriorityP2 ;
bom:hasReporter <http://kilauea.int-evry.fr:8081/triplify/bugzilla/user/1> ;
bom:hasResolution helios_bt:BugzillaResolutionFIXED ;
bom:hasSeverity helios_bt:BugzillaSeveritynormal ;
bom:hasState helios_bt:BugzillaStateRESOLVED ;
bom:isInProduct <http://kilauea.int-evry.fr:8081/triplify/bugzilla/product/2> ;
bom:isIssueOf <http://kilauea.int-evry.fr:8081/triplify/bugzilla/component/2> .
The real interest here will be if/when every bugtracker would start
outputing facts about its bugs in the EvoOnt BOM (if agreed on), FOAF,
etc.
That's why we sought your opinion on what EvoOnt BOM and our extensions
may provide.
Thanks in advance for your comments, and sorry for the long post.
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)
More information about the developers
mailing list