The PTS now produces Turtle RDF meta-data alongside HTML and RDF/XML - Was: Re: Some issues with the RDF export
Hi.
FYI, The PTS now implements an RDF export in the Turtle format which
should be more easy to use that the XML variant that had been added
previously.
Turtle is supposed to be the best option for implementing Semantic Web
and Linked Data applications nowadays.
As an example, see for instance
http://packages.qa.debian.org/a/apache2.ttl (or :
$ curl -L -s -H "Accept: text/turtle" http://packages.qa.debian.org/apache2 )
For more details, see also my blog post on the subject :
http://www-public.telecom-sudparis.eu/~berger_o/weblog/2013/02/01/the-debian-package-tracking-system-now-publishes-turtle-rdf-meta-data/
In addition to the default format change, the contents of the meta-data
has been improved too, including some of the suggested improvements made
by Kjetil.
I hope this will be inspirational for other uses of Turtle in Debian
(instead of YAML, for instance).
Any comments, bug reports or feature requests most welcome.
Best regards,
Olivier Berger <olivier.berger@it-sudparis.eu> writes:
> Hi.
>
> Kjetil Kjernsmo <kjetil@kjernsmo.net> writes:
>
>> Hi there!
>>
>> It is really nice to see that Debian exports RDF! Great work! I was just
>> made aware of it by Jonas Smedegaard, who have packaged most of the
>> Perl+RDF stack as well as other semweb packages.
>>
>
> Glad you find it interesting :-)
>
>> I have some comments, most pertaining to this small excerpt:
>>
>> <http://packages.qa.debian.org/librdf-linkeddata-perl>
>> a admssw:SoftwareProject;
>> doap:description "Debian librdf-linkeddata-perl source packaging";
>> doap:homepage "http://packages.debian.org/src:librdf-linkeddata-perl";;
>>
>>
>>
>> 1) Shouldn't the subject URI be to something else than the QA package? I
>> don't think the QA page itself is a SoftwareProject, the latter is an
>> abstract thing. So, it should IMHO be something like
>>
>> <http://packages.qa.debian.org/librdf-linkeddata-perl#project>
>
> It could be done like this, but on the other hand, the URI is
> dereferenceable as RDF/XML to retrieve the RDF document... and the
> "packaging project" behind every source package isn't so much an
> abstract thing ?
>
> But, yes, maybe the document should be distinguished from the
> resource. That would also allow documenting the retrieval date for
> indexers, etc.
>
> But in such case, we have the RDF documents at URLs like
> http://packages.qa.debian.org/libr/librdf-linkeddata-perl.rdf if need
> be...
>
> I'm not so sure what's the best option.
>
>>
>> The same goes for all the other mentions of admssw:SoftwareProject in the
>> document.
>>
>
> Other SoftwareProject (upstream projects) are already fragment-ed :
>
>> 2) DOAP has a doap:shortdesc property. I suggest using that for the current
>> description, and perhaps use doap:description for the full
>> description?
>
> We could, but my prority was to implement ADMS.SW 1.0, which is
> implemented using doap:description.
>
> admssw:SoftwareProject is a subClass of doap:Project, so nothing forbids
> having both... so if I can get the full description from the XSLT
> stylesheet used by the PTS, I could add doap:shortdesc (not sure if it
> is available though).
>
>>
>> 3) doap:homepage shouldn't be a literal, it should be a URI, so pointy
>> brackets, not quotes. There seems to be the same for all the doap:homepage.
>>
>
> Indeed : doap:homepage doesn't seem to force that, but inherits from
> foaf:homepage that seems to be referencing a foaf:Document, ok, then.
>
>> 4) Finally, to really make it linked data, it would be cool to add links to
>> e.g. upstream where it exists. For all the Perl packages, there exists URIs
>> for everything on CPAN. The upstream URI of this package is
>>
>> http://purl.org/NET/cpan-uri/dist/RDF-LinkedData/project
>
> Great :-)
>
> OK, so for RDF::Trine, it's :
> http://purl.org/NET/cpan-uri/dist/RDF-Trine/project
>
> Very interesting. I wonder if ADMS.SW is in the radar of the creator of
> this (are you ?)...
>
> There are also Apache DOAP files (of which I couldn't match URLs of
> homepages), and Gnome ones (currently trying to see if matches
> apply). Clearly, promoting DOAP and its publishing is something
> important, IMHO. I've worked on adding DOAP/ADMS.SW generation for
> FusionForge too.
>
>>
>> Some heuristics could probably done to add this, but perhaps a field in the
>> package description would be better?
>
> Yes, that's clearly one of the goals to be able to do that, but
> unfortunately, we don't necessarily have such information in the
> debian/control files yet, so the PTS may not know, at least in the context
> where I'm generating the current RDF files.
>
> I'd like to investigate possible ways on doing such interlinking with
> all interested parties.
>
> This needs to be discussed together with other upstream metadata
> collection, in line with work already started like :
> http://wiki.debian.org/UpstreamMetadata
>
> We just have to find a way to discuss that with the different Debian
> contributors interested (and probably other parties, like upstream
> projects).
>
> I'd welcome all sugestions on how to proceed (some previous discussions
> have happened on -project or -devel lists... I'm not sure where to
> continue...).
>
> In any case, thanks for your comments. I'll try and fix some bits for
> next runs.
>
> 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)
>
>
> --
> To UNSUBSCRIBE, email to debian-qa-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: http://lists.debian.org/873934tttd.fsf@inf-8657.int-evry.fr
>
>
--
Olivier BERGER
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)
Reply to: