Related identifiers
Closed this issue · 10 comments
While we often need to cite a specific version of software, e.g. a release, we also need a way to cite the software in general, and to link multiple releases together. For this reason we need more than one persistent identifier for each software: a) a general one, and b) a specific one for each release.
This issue is similar to what we see with versions for data. One use case would be to link all versions of a piece of software with a Zenodo DOI together, and then also associate the stars and forks of the code repository.
I'm tempted to say that this is a complex issue that is beyond the scope of this document, though I understand your use case, and think that it does need to be addressed somewhere (though perhaps not here).
For one thing, I don't think we know what such a citation mechanism is, so I'm reluctant to say that we should do X.
Other thoughts are very welcome.
At STFC the Mantid software which is persistently identified using DOIs, there is a DOI for the concept, and then DOIs issued for each version, with relationships made between these different objects.
I think there are different reasons for citing different software objects and this depends on the usage and so I don't think the citation principles should go into that level of detail. It should be clear what the cited object is.
I don't necessarily want to complicate the discussion, but the approach described by @cm-j0nes (with different identifiers for concept and version) almost sounds like a good use case for citing a software paper vs. a specific version of the software itself.
The software paper may describe the concepts behind the software and overall implementation "theory", which may not really change between version—that can then be used as a "link" to all of the versions (somehow...). Of course, you would still need to cite the software (including version) directly when describing research that used the software.
I think that we want to be generic, allowing the different scenarios (concept, software paper, release, etc.). The important point for me is that we want to capture that there is often more than one thing describing the software.
From the data citation side (at least from some members of the RDA dynamic data citation working group), I've heard proposals to manage the collection/granule citation with a kind of overloaded DOI. So the collection (one of the MODIS sets, for example) is assigned the DOI and then the cited subset is that DOI plus relevant bits appended to the end. Semi-structured and similar to a "Cool" URI:
shoulder/id/MODIS/v25/some_granule_info/...
I'll note that the indexers rarely come up in these conversations so whether that is a viable implementation for data or software? At least something to be aware of.
Given the choice between adding a new type object that could be treated like a DOI or changing the existing DOI, I strongly favor the former
Sounded more like using the current DOI but with a very long ID string to capture the citation metadata. Like you should be able to understand the dynamic data citation solely from the DOI string.
It is likely a moot point - DOIs aren't concordances, resolvers can't handle it, it raises authority issues...
subsubsection added in 5 (in 23208d2) to address this.
I liked the changed text. Thanks @danielskatz!
Me too!
Catherine
From: Martin Fenner [mailto:notifications@github.com]
Sent: 18 April 2016 00:50
To: force11/force11-scwg
Cc: Jones, Catherine (STFC,RAL,SC)
Subject: Re: [force11/force11-scwg] Related identifiers (#98)
I liked the changed text. Thanks @danielskatzhttps://github.com/danielskatz!
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHubhttps://github.com//issues/98#issuecomment-211130480