Hi. It would be great if bug lists or bug pages could include RDFa content. Such content could be basic bug description. For instance in lists of bugs, a link like <a href="bugreport.cgi?bug=12345">...</a> could mention that the destination page is about a resource whose URI is <http://bugs.debian.org/12345/> Thus, in page <http://bugs.debian.org/12345/> one could find basic fields, like the title of the bug, and so on using common ontologies like Dublic Core. For bug ontologies, here's our proposal : http://heliosplatform.sourceforge.net/ontologies/2010/05/helios_bt.html For a reference on RDFa : http://www.w3.org/TR/xhtml-rdfa-primer/ maybe. The idea is to embed (much like using CSS directives) semantic tagging of the displayed elements to add metadata in addition to the presented data. Then, for instance instead of a link between a debbugs page and a PTS page, one would get a "semantic" link explaining that source page is a bug description page and target page is a source package description page, where 'bug' and 'source package' standard properties could be defined in an ontology that could be shared together with many other tools (other distros, for instance). The idea is that the pages of debbugs can be parsed by RDFa aware tools, without adding a complete new API to retrieve semantic information about bugs. FYI, #585740 exhibits similar ideas for the PTS. Best regards,
http://testforge.int-evry.fr/d2r-server/ This is work in progress and not meant for end-users. For reference on how we installed D2R to deploy this : https://picoforge.int-evry.fr/cgi-bin/twiki/view/Helios_wp3/Web/UltimateDebianDatabaseToRDF One will find metadata about bugs, but also some metadata about Debian packages (minimal), or Debbugs users (bug submitters), and Debian developers (out of carnivore), as SIOC and FOAF bits. Given one bug number, one may get an XML/RDF version using : curl -H 'Accept: application/rdf+xml' http://testforge.int-evry.fr/d2r-server/data/debbugs/585740 or the N3 version with : curl -H 'Accept: text/rdf+n3' http://testforge.int-evry.fr/d2r-server/data/debbugs/585740 Btw, on our D2R server, one can also query custom searches using SPARQL. For instance : http://testforge.int-evry.fr/d2r-server/snorql/?query=SELECT+DISTINCT+*+WHERE+{%0D%0A++%3Fs+%3Fp+%3Fo.%0D%0A++%3Fs+owl%3AsameAs+%3Chttp%3A%2F%2Fbugs.debian.org%2F585740%3E.%0D%0A}%0D%0ALIMIT+10 which will search bug properties for bug #585740 : SELECT DISTINCT * WHERE { ?s ?p ?o. ?s owl:sameAs <http://bugs.debian.org/585740>. } LIMIT 10 About people, for an example, here's my FOAF profile : http://testforge.int-evry.fr/d2r-server/resource/foafcarnivore/6688a14521cd97db162af8f9757f2e2232300e50 Given one's email address, it's easy to access one's FOAF profile there with for instance : curl -H 'Accept: application/rdf+xml' http://testforge.int-evry.fr/d2r-server/data/foafcarnivore/`echo -n "mailto:$DEBEMAIL" | sha1sum | sed 's/ .*$//'` Any comments welcome. Best regards,
Sounds interesting; just for my priority, etc, do you have an idea of how this information that you collect is going to be used eventually? [I'm also interested in trying to make sure that whatever inter-bug-tracker formats we settle on exporting are more widely supported, as my time to understand and implement format translators is relatively limited.] Don Armstrong
Le vendredi 30 juillet 2010 à 17:06 -0400, Don Armstrong a écrit : Mainly in providing lists of bugs that relate to same people or same packages. Such lists could be semantic feeds, to which people and apps could subscribe in other apps and/or desktop environments (semantic desktop, etc.) Imagine such meta-data repositories for many distributions bugtrackers, where one can query for instance bugs on same sets of packages or bugs he/she submitted in all these, using the same query language (SPARQL + same ontologies) For instance, upstream maintainers could monitor bugs on the packages for their programs in various downstream package bugtrackers. Provided that such information is in RDF and using compatible ontologies, it becomes semantically interoperable... that's the end goal. All this will require using DOAP to describe upstream projects, and a common ontology for packages, and a common ontology for links betw. bugs and packages... that's things we're working on, and our D2R server is meant to help test these. You may refer to a paper of ours for the general picture : "Weaving a Semantic Web Across OSS Repositories: Unleashing a New Potential for Academia and Practice" [0] (preprint available on demand). OSLC-CM V2's ChangeRequest specs [2] could be a valid candidate for encoding bug properties, either as RDFa or for plain RDF documents. Here I'm speaking only about the static dimention of OSLC-CM (RDF descriptions of bugs/change requests), not the REST protocol part, discussed in #565513. But OSLC lacks things like relations between bugs and packages, and that's what we're trying to work on in drafting a compatible ontology [1]. It's not all completely finished and our demonstrator is here to try and verify if our ontology choices are compatible with applications. Of course, when things clarify, it would be great to implement such extractors on debbugs side directly instead on separate converters ;) Best regards, [0] http://www-public.it-sudparis.eu/~berger_o/weblog/2010/07/29/weaving-a-semantic-web-across-oss-repositories-unleashing-a-new-potential-for-academia-and-practice-published/ [1] http://sourceforge.net/apps/wordpress/heliosplatform/2010/06/04/first-draft-of-helios_bt-bug-ontology-request-for-comment/ [2] http://open-services.net/bin/view/Main/CmSpecificationV2#CM_Resource_Definitions