Re: Some issues with the RDF export
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)
Reply to: