Experience with Debian Science's Citations project? #45
Comments
|
Hello @katrinleinweber , I'm a member of Debian Med. As you see, we try to include citation information for every academic produced bioinformatic, medicine, or hospital related piece of software we package. Other teams within Debian do the same. @tillea can provide more up to date information on the status of the effort. |
|
Cool, thanks for the update! I'm not so much asking for details for myself, though, but whether there was a connection between efforts within Debian and within SCIWG ;-) Since you were not in the contributor list here I thought it's better to ask. |
|
Hi,
|
|
Thanks for explaining :-) I understand that a Debian Science user would need to:
If that's it: Neat! Aside from that, I noticed that you use |
|
@katrinleinweber Our initial focus was on research software with traditional publications. A quick search of the entire Debian code base shows only two instances of Looks like the two CITATION files were hand transformed to However I can't find any While we could autogenerate Once codemeta &/or the citation file format catches on we could obviously auto-ingest those. |
|
@mr-c Interesting. What would you need for the Citation File Format (and CodeMeta) to be auto-ingestable during your workflow? |
|
@sdruskat a script ( Is there any notion of presenting CodeMeta and/or CFF files in a standard location when applications are installed? In CWL we standardized how to discover them on the filesystem: http://www.commonwl.org/v1.0/CommandLineTool.html#Discovering_CWL_documents_on_a_local_filesystem
A similar approach would be useful for CodeMeta and/or CFF ( Debian could then take advantage of such a standardized location in several ways: for example we'd also install the citation/metadata files to the appropriate directory even if the tool author forgot to instruct their build system to do so. |
|
Hi Katrin,
I think one needs to be careful not to mix different concepts here.
What I see in the bibtex file maintained in Debian (
http://blends.debian.net/packages-metadata/debian.bib) is a great work
compiling "scientific articles" that "describe software" that is also
packaged in Debian. As such, the entry type @Article is quite appropriate
most of the time (for @tillea, conference proceedings, like aevol or
astroml, should be @inproceedings, not @misc, by the way).
On the other hand, citing "software" itself is really an open issue right
now.
On one side, the @software BibTeX entry type has no formal existence, as it
is not supported by any of the major bibliographic styles out there;
the fact that @software "works" in bibtex is just because bibtex and
biblatex use @misc as fallback for all "unknown" entries: you can add a
@foobar entry in your .bib file and it will "work" exactly the same :-)
On the other side, determining what should go in a citation for software is
a really complex issue: what would be the fields of a @software type? Which
ones are mandatory, which are optional? And even for an apparently simple
concept like "author", it is really not clear what names should be
included: in principle, it should be the software project's own
responsibility to come up with that list, but that's a touchy issue, as the
list changes over time.
…--
Roberto
Roberto Di Cosmo
------------------------------------------------------------------
Computer Science Professor
(on leave at INRIA from IRIF/University Paris Diderot)
Software Heritage E-mail : [email protected]
INRIA Web : http://www.dicosmo.org
Bureau C123 Twitter : http://twitter.com/rdicosmo
2, Rue Simone Iff Tel : +33 1 80 49 44 42
CS 42112
75589 Paris Cedex 12
------------------------------------------------------------------
GPG fingerprint 2931 20CE 3A5A 5390 98EC 8BFC FCCA C3BE 39CB 12D3
2018-02-21 9:04 GMT+01:00 Katrin Leinweber <[email protected]>:
Thanks for explaining :-) I understand that a Debian Science user would
need to:
1. include that .bib in their own workflow and
2. start citing the package names.
If that's it: Neat!
Aside from that, I noticed that you use @Article{…} and @misc{…} and didn't
find a mailing list discussion about using @software{…}
<https://lists.debian.org/cgi-bin/search?P=bib+%2Btype+%2Bsoftware+%2Bmisc&DEFAULTOP=or&B=Gdebian-med&B=Gdebian-science&SORT=&HITSPERPAGE=10&xP=bib%09type%09software%09misc&xFILTERS=Gdebian-med%7EGdebian-science%7E-%7E%7E4294967295>.
I heard that the latter item type is not yet fully supported in Bib(La)TeX,
but doesn't break anything, because it gets treated as @misc{...}. Do you
have experience with that? Have you considered encouraging the use of
@software{...}?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#45 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAp-v4kJpBi1QpKTLW6mTD6thPqq_xyYks5tW84FgaJpZM4SJdtJ>
.
|
|
@mr-c AFAIK, at the moment, there is no standard for placing CFF/CM files on a local file system. CFF suggests placing the file in the remote repo's root dir, and so does CodeMeta (right?). I'll have to think about the standard location concept for CFF. What you describe for Debian packages seems useful, although may not be portable for other types of software. As for a conversion script, I'll add https://wiki.debian.org/UpstreamMetadata to the list of formats that I'd like CFF (infrastructure) to support :). |
|
Hello @rdicosmo, yes, of course Regarding: |
Interesting! I understood it the other way round: CFF & CM being generated out of the community's existing metadata files/formats.
That would be very convenient for developers! It seems to me that a) pushing the option to generate these files to the developers' local machines will find lower traction than b) to centralise that task. Which OTOH, should be accompanied by offering a |
Can at least the |
CWL's choice of locations for discovery is not Debian specific. It was done by consulting the Filesystem Hierarchy Standard v3.0 and the XDG Base Directory Specification v0.6 neither of which is specific to a flavor/type of Linux/Unix. |
|
@mr-c Thanks, by "not portable" I meant other OSs, types of software that aren't installable; these however wouldn't be touched by that particular standard anyway, so makes sense. |
For example, eventually we may not need |
CFF at least, I've thought of as a source format rather than a target format (apart maybe for conversions from |
|
However I can't find any `octave` in http://blends.debian.net/packages-metadata/debian.bib, so perhaps there is an issue on our side. @tillea Any ideas here?
My first guess is the mentioned move from alioth.debian.org -> salsa.debian.org. Currently you should simply *expect* missings since I have not yet updated the code that is gathering the data from salsa.
Andreas.
|
|
@tillea D'oh, that's right, sorry for the bother. I was curious how the |
Hi!
I learned about https://wiki.debian.org/DebianScience/Citations recently and was wondering whether anyone here knows about that initiative? The "med" & "science" blends were apparently discussing and implementing (not sure how far) a system-wide way for users to gather citation info from packages they were using.
The text was updated successfully, but these errors were encountered: