In reply to
@MikeTaylor Cool. Thanks. I had planned a blog post. You just poked me at the right time. I will redraft as one.
In reply to
@MikeTaylor Cool. Thanks. I had planned a blog post. You just poked me at the right time. I will redraft as one.
In reply to
@keith_wilson Except that the fragility of an identifier correlates strongly with the degree to which semantic information is embedded in it (remember SICIs?). So generally preferable to put version information in the metadata and make the identifier itself opaque.
@MikeTaylor @CrossrefOrg @qeios As I said- it *might* be important to assign a new DOI to a version that corrects a single character typo- If the correction changes the meaning or crediting of the work (e.g. adding a critical decimal point) (thread)
But if the single change is trivial, then having different DOIs for the two versions just muddies the citation record- because it (amongst many other things) makes it more difficult to detect when people have cited the same content.
This practice helps clarify the citation record. For example, it enables me in the future to easily detect when somebody cited the article with the wrong number vs the article with the corrected number.
Changes in the bytestream of something do not always correspond to changes in the "meaning." This is why, even with software version control, we use both hashes and separate version numbers.
On the other hand, the version number in software conveys changes that are considered more significant- those that might effect the performance characteristics or fix bugs (minor point releases) and those that break backwards compatibility (major point releases).
The hash alone can convey a change in the bytestream, but that change might be trivial and not merit even a minor version bump. For example, removing a blank line or automatically running your code through autopep8 when you save it.
Minor copyediting changes should be treated similarly. They might result in a different hash, but you still want something other than the hash that tells you whether the change was likely to have effected the meaning.
And the same is true with content. The bytestream of the PDF and HTML copies of an article will be different, but not in a way that would normally effect crediting/interpretation of the work and so we don't assign separate citation identifiers to them.
NB that the software comparison breaks down in some cases, - particularly around the phrase "breaking changes"- but that is a subject for another day.
It is this latter thing that DOIs do when they are used in a citation context (e.g. by @CrossRefOrg, @DataCite, etc.).
In reply to
@MikeTaylor @CrossrefOrg @qeios “significant” means likely to change interpretation or crediting. Afraid that at some level it is an editorial decision and cannot always be decided automatically.
In reply to
@MikeTaylor @CrossrefOrg @qeios Do not recommend assigning DOI to “most recent version” as that will change over time- so seems dubious to “cite” something you haven’t seen yet. Instead you can use relations in metadata to point to more recent versions.