[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Adding ADMS.SW RDF descriptions of source packages to the PTS



Hi.

I've started working on #685605, i.e. adding some RDF+XML documents
generated for the PTS static pages.

Appologies for those not Semantic Web aware in advance ;-) I hope the
code and following example can help illustrate my goal, still, beyond
the jargon.

I've committed a first admssw.xsl stylesheet in the SVN, which outputs
this kind of document for the 'fusionforge' source package :

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; xmlns:admssw="http://purl.org/adms/sw/"; xmlns:doap="http://usefulinc.com/ns/doap#"; xmlns:dcterms="http://purl.org/dc/terms/"; xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"; xmlns="http://www.w3.org/1999/xhtml"; xmlns:str="http://exslt.org/strings";>
  <admssw:SoftwareProject rdf:about="http://packages.qa.debian.org/fusionforge";>
    <doap:description>Debian fusionforge source packaging</doap:description>
    <doap:homepage>http://packages.debian.org/src:fusionforge</doap:homepage>
    <doap:name>fusionforge</doap:name>
    <doap:release rdf:resource="http://packages.qa.debian.org/fusionforge_5.0.2-5"/>
    <doap:release rdf:resource="http://packages.qa.debian.org/fusionforge_5.2~rc1-5"/>
    <doap:release rdf:resource="http://packages.qa.debian.org/fusionforge_5.2~rc1wheezy1~exp1"/>
  </admssw:SoftwareProject>
  <admssw:SoftwareRelease rdf:about="http://packages.qa.debian.org/fusionforge_5.0.2-5";>
    <dcterms:description>Debian fusionforge source package version 5.0.2-5</dcterms:description>
    <rdfs:label>fusionforge 5.0.2-5</rdfs:label>
    <doap:revision>5.0.2-5</doap:revision>
    <admssw:project rdf:resource="http://packages.qa.debian.org/fusionforge"/>
  </admssw:SoftwareRelease>
  <admssw:SoftwareRelease rdf:about="http://packages.qa.debian.org/fusionforge_5.2~rc1-5";>
    <dcterms:description>Debian fusionforge source package version 5.2~rc1-5</dcterms:description>
    <rdfs:label>fusionforge 5.2~rc1-5</rdfs:label>
    <doap:revision>5.2~rc1-5</doap:revision>
    <admssw:project rdf:resource="http://packages.qa.debian.org/fusionforge"/>
  </admssw:SoftwareRelease>
  <admssw:SoftwareRelease rdf:about="http://packages.qa.debian.org/fusionforge_5.2~rc1wheezy1~exp1";>
    <dcterms:description>Debian fusionforge source package version 5.2~rc1wheezy1~exp1</dcterms:description>
    <rdfs:label>fusionforge 5.2~rc1wheezy1~exp1</rdfs:label>
    <doap:revision>5.2~rc1wheezy1~exp1</doap:revision>
    <admssw:project rdf:resource="http://packages.qa.debian.org/fusionforge"/>
  </admssw:SoftwareRelease>
</rdf:RDF>

The goal is to publish meta-data about the packages for consuming by
machines, as an alternative to the SOAP API, using the Linked Open Data
principles (some few more details in #685605).

FYI, I've just recently worked on implementing similar RDF support for
FusionForge projects, which means that some day upstream projects and
alioth packaging projects could benefit from similar inter-linkable
descriptions all part of the Linked Open Data cloud.

The generated file would be named hash/SOURCE-PACKAGE.rdf, generated in a similar
way as hash/SOURCE-PACKAGE.html, just adding admssw.xsl to the existing
pts.xsl, and adding a few rewrite rules.

The main implementation choices I've mase so far :

- represent each source package as a admssw:SoftwareProject : the naming
  is somehow confusing, but that's an inconvenience in ADMS.SW : read
  Software Product (which has different releases). That allows
  differentiating the packaging effort from the upstream software (a
  suitable ontology remains to be used to interling these resources -> TODO)

- reusing the PTS short URL http://packages.qa.d.o/SOURCE-PACKAGE as a
  reference URI for such a resource (hoping it's gonna be a stable
  reference identifier over the Linked Data cloud). This URL should
  ideally be dereferencable with a Accept application/rdf+xml for
  content-negociation, provided that the rewrite rules are adapted (I
  hope it's doable), so that the generated hash/SOURCE-PACKAGE.rdf file
  can be served in place of the hash/SOURCE-PACKAGE.html

- its homepage could have been the same but I chose to point to
  http://packages.debian.org/src:fusionforge as does the PTS Web UI
  somewhere : feedback on more interesting link ?

- doap:name could be src:fusionforge ?

- admssw:SoftwareRelease resources are generated for all the versions
  currently pointed to by the PTS (for all the suites suitable : similar
  XSLT processing code as in pts.xsl), in the same document as the
  SoftwareProject. Maybe these should be in their own RDF documents ?

- the different releases' URIs are constructed as
  http://packages.qa.d.o/SOURCE-PACKAGE_VERSION which could have been
  done also as http://packages.qa.d.o/SOURCE-PACKAGE/VERSION but maybe
  that's safer WRT the rewriting rules. We could also think of
  http://packages.qa.d.o/SOURCE-PACKAGE#VERSION but I'm afraid there
  could be # already in Debian package versions... any other options ?
  Anyway, I've not yet tested the fact that dereferencing such a URI
  could indeed serve a document containing that resource as RDF,
  i.e. the same document SOURCE-PACKAGE.rdf

I've had to struggle with the de-duplication of the versions for the
same versions corresponding to different suites, but that would have
been too easy otherwise (see the XSLT, any improvement welcome).

Now, there are tons of other informations that may be added in these RDF
documents, including links to binary packages, etc. The most interesting
things I'd ultimately like to be able to add would be inter-links
between upstream project and other downstreams RDF descriptions and the
PTS' so that one can "navigate" the Linked Open Data cloud between
versions of packages cross project and cross distros without any
converter involved, as everyone would compatible formats, based on
ADMS.SW, SPDX or likes. That's a great TODO ahead of me/us... but I
should find a way to be paid to continue that work ;)

We could also think about providing other RDF representations like
turtle (easy : just adding some rapper processing) or JSON (JSON-LD
if/when it's standardize and we have conversion tools).

But before going much further, I thought I would ask for opinions from
other PTS maintainers or QA people first.

Thanks in advance for your feedback.

Best regards,
-- 
Olivier BERGER 
http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


Reply to: