Re: tasks overview wishlist: Canonical citing reference
Le Wed, Nov 04, 2009 at 09:54:27AM -0600, Dirk Eddelbuettel a écrit :
> On 4 November 2009 at 16:18, Morten Kjeldgaard wrote:
> |
> | I can't remember seeing this discussion, but in some of my packages, I've
> | put a file debian/citation.bib, which is installed in the
> | /usr/share/doc/<package>/ directory.
>
> As one possibility for going one step further, consider what R supports (but
> not requires). If any of the add-on package CRAN has a CITIATION file, then
> the citation() function can be used to pretty-print the content, incl a
> Bibtex snippet, by giving the R package name as argument:
>
> edd@ron:~/src/debian/CRAN> r -e'print(citation(package="zoo"))'
Dear Dirk and Morten,
I actually also include a reference in my packages since last year, but in
debian/reference… When I do not forget, I install it in /usr/share/doc/<package>.
In one package I experimentally referenced it with a doc-base entry under a new
section, Bibliography. It works, but I am not sure how useful it is. Lately, I
have been moving the BibTex reference in a compound file, upstream-metadata.yaml.
It is trivial to pop it out with a YAML parser and to place it in
/usr/share/doc/<package>/, and as a bonus it is in a (willing to become)
standard place that is easy to find by parsers. I am definitely motivated to
send a patch to dh_installdocs or to write a separate dh_installrefs script
when things have shaped.
It would be great to standardise our efforts.
- Where do we place the BibTeX file? /usr/share/doc/<package>/, or
/usr/share/bibtex-references/<package>.bib ? And let's quickly settle on
one name.
- How do we make sure that the name of the references (the thing after
@article) do not clash between each other and the user's existing reference
database? Or can most programs cope with this at import time?
- Independantly from the above two points that are for binary packages, do we
want to standardise a preferred localisation(s) of the citation in the
source package itself? This could be exploited by tools that have access to
unpacked archive or that make advantage of the VCS URLs, to generate
bibliographic informations in web summary pages.
- How much information duplication are we willing to tolerate? The origin of
this discussion was a proposition to add the DOI to debian/control. While
I propose to put this in debian/upstream-metadata.yaml instead, I am still
considering that it will be much more used if we provide it directly instead
of requiring to retreive and parse a BibTeX references. Which in my case meant
adding a BibTeX reference, and cut-paste the DOI that was in to somewhere else.
Lastly, I have been systematically deleting the abstracts because they are
copyrighted material. Just let me know if you have counter-example
demonstrating that this is over-cautious (but let's avoid a discussion if we
have only vague opinions: then everyone does as he thinks).
Have a nice day,
--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
Reply to: