4 ms·

In academia this is something that DOIs (see https://www.datacite.org/ https://www.datacite.org/) solve quite neatly.

by mwest 11y ago

IanCal 11y ago
DOIs don't solve mutable content, do they? They help solve problems around ambiguity, but there's nothing inherent in DOIs that stops you from updating/removing the content behind the scenes. I think the only way it helps the problem is that if you're abusing it you'll have the ability to mint DOIs revoked.
- 100ideas 11y ago
  Do content libraries that provide DOIs, such as MIT's DSPACE, at least promise that the content is immutable? http://dspace.mit.edu/bitstream/handle/1721.1/44962/BBFRFC20.pdf?sequence=1 http://dspace.mit.edu/bitstream/handle/1721.1/44962/BBFRFC20... It would be cool if the DOI was hashed to content. But I think immutability is part social contract of the DOI - the DOI never changes and neither does the document. New document, new DOI.
  - dalke 11y ago
    No. Nor can they. Here's an example. I recently found a mistake in an ACS (American Chemical Society) journal. The ACS has gone back and assigned a DOI even to print publications from decades ago. Even each letter to the editor was assigned it own DOI. I found an example where there were two letters to the editor on the bottom half of the same page. It wasn't easy to tell where the first ended and the second started. The indexer created one record, gave it a unique DOI, and used the title of the first letter and the author of the second article. What does "immutable" mean for this case? Does the DOI really refer (in some immutable way) to the first record? The second record? Or the aggregate? They resolved the problem by correcting the record so it had the author for the first letter to the editor, then creating a new DOI for the second letter to the editor. That seems the most reasonable. And in this case the content - an image of the page - was unchanged because both letters were on the same page. But had the content been limited to only the letter(s), or the second letter spilled over to the next page, this fix would have changed the content. In general, some paper scans are of mediocre quality. (Not of this journal though.) Here's one from DSpace which I would like to have at a higher resolution - http://dspace.mit.edu/bitstream/handle/1721.1/12664/28627690-MIT.pdf?sequence=2 http://dspace.mit.edu/bitstream/handle/1721.1/12664/28627690... . I can well believe that 10 years from now there may be a rescan with higher quality. "Immutable" doesn't make sense in that context, does it?
    - NoGravitas 11y ago
      > I can well believe that 10 years from now there may be a rescan with higher quality. "Immutable" doesn't make sense in that context, does it? I see your point, but for future research purposes, it may be highly relevant to know that what someone cited in an influential paper 20 years ago they got from a low-quality scan. At least in the humanities, that's actually the kind of thing that some researchers care about a lot.
      - dalke 11y ago
        Yes, the linked-to article elaborates on that: > Even when the search turns up the proper source, it might not turn up the proper edition of the source, and for scholars, that level of distinction very often matters. In order to ensure that Reader B has every possibility of seeing the same thing in a source text that Reader A saw, B needs to know whether A read the edition of a book published in 1819 or the revised edition published in 1831, or whether A read an article as originally printed in the journal or as it was repackaged for inclusion in a later edited volume. Much like the situation in a laboratory, these variables matter, and so this level of precision in their citation matters. That said, DOI does not make the "promise that the content is immutable". I'll quote the DOI FAQ at http://www.doi.org/faq.html http://www.doi.org/faq.html : > The IDF does not have any rules on this. Individual RAs adopt appropriate rules for their community and application. As a general rule, if the change is substantial and/or it is necessary to identify both the original and the changed material, assign a new DOI name. That means I was wrong. DOIs could be immutable in that way, but aren't. I made the incorrect assumption that what happened for chemistry-related fields was indicative of a general policy, which it isn't.
- verisimilidude 11y ago
  Fundamentally, you are correct. In the current environment, most DOIs are issued by established journals, backed by relatively mature publishing software that knows how to keep a DOI up-to-date. Therefore, empty DOIs are not much of a problem at the moment. Also for the moment, DOIs are far more reliable than URLs. URLs are terrible for citations, often going dead before an article is even published. However, like you say, I could easily envision a future in which the current environment breaks down, new kinds of sites with less reliable software start issuing DOIs, DOIs go stale, DOIs don't adapt to changes in content models, etc. DOIs feel more like a band aid than a permanent solution. Long-term, I like the idea of publishing articles on a system like IPFS, where the content determines the address via hash, that doesn't change, and any publishing system that needs to cite an article could hopefully just "pin" it for preservation. Perhaps you keep immutable copies of your article revisions in IPFS, and marry them together via a mutable IPNS interface for consumption. This would assume all articles are open access, maybe, but that wouldn't be a bad thing.
  - x1798DE 11y ago
    Does an IPFS system allow you traverse the revision tree? I think the ideal system would be one with a canonical identifier plus a content / version based identifier, so that if, for example, there is a retraction, you will know that by visiting the current version, but if you want to see the cited version, that is also available.
    - verisimilidude 11y ago
      I'd love to see that. I think versioning is possible in IPFS via merkle tree, but I haven't taken the time to understand how it would be implemented. https://github.com/ipfs/specs/tree/master/merkledag https://github.com/ipfs/specs/tree/master/merkledag
    - IanCal 11y ago
      That's something that would be possible with IPNS (which allows a mutable 'pointer' to an IPFS hash, though this is just my lay understanding). This way your IPNS address becomes your DOI equivalent, but also providing the IPFS hash would give a static reference to exactly what it was you saw. There are some kinks here, as there isn't currently a way of verifying that the IPFS hash given was seen at the IPNS address. You also can't take an IPNS address and get all previous versions. It does sound like that's possible to add to IPNS, but is a future plan. It would be a step forwards from the current system though. A bit of info on IPNS, which is in really quite early stages afaik: https://ipfs.io/ipfs/QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/example#/ipfs/QmQwAP9vFjbCtKvD8RkJdCvPHqLQjZfW7Mqbbqx18zd8j7/ipns/readme.md https://ipfs.io/ipfs/QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxd...

In academia this is something that DOIs (see https://www.datacite.org/ https://www.datacite.org/) solve quite neatly.

by mwest 11y ago

In academia this is something that DOIs (see https://www.datacite.org/ https://www.datacite.org/) solve quite neatly.

DOIs don't solve mutable content, do they? They help solve problems around ambiguity, but there's nothing inherent in DOIs that stops you from updating/removing the content behind the scenes. I think the only way it helps the problem is that if you're abusing it you'll have the ability to mint DOIs revoked.

100ideas 11y ago
Do content libraries that provide DOIs, such as MIT's DSPACE, at least promise that the content is immutable? http://dspace.mit.edu/bitstream/handle/1721.1/44962/BBFRFC20.pdf?sequence=1 http://dspace.mit.edu/bitstream/handle/1721.1/44962/BBFRFC20... It would be cool if the DOI was hashed to content. But I think immutability is part social contract of the DOI - the DOI never changes and neither does the document. New document, new DOI.
- dalke 11y ago
  No. Nor can they. Here's an example. I recently found a mistake in an ACS (American Chemical Society) journal. The ACS has gone back and assigned a DOI even to print publications from decades ago. Even each letter to the editor was assigned it own DOI. I found an example where there were two letters to the editor on the bottom half of the same page. It wasn't easy to tell where the first ended and the second started. The indexer created one record, gave it a unique DOI, and used the title of the first letter and the author of the second article. What does "immutable" mean for this case? Does the DOI really refer (in some immutable way) to the first record? The second record? Or the aggregate? They resolved the problem by correcting the record so it had the author for the first letter to the editor, then creating a new DOI for the second letter to the editor. That seems the most reasonable. And in this case the content - an image of the page - was unchanged because both letters were on the same page. But had the content been limited to only the letter(s), or the second letter spilled over to the next page, this fix would have changed the content. In general, some paper scans are of mediocre quality. (Not of this journal though.) Here's one from DSpace which I would like to have at a higher resolution - http://dspace.mit.edu/bitstream/handle/1721.1/12664/28627690-MIT.pdf?sequence=2 http://dspace.mit.edu/bitstream/handle/1721.1/12664/28627690... . I can well believe that 10 years from now there may be a rescan with higher quality. "Immutable" doesn't make sense in that context, does it?
  - NoGravitas 11y ago
    > I can well believe that 10 years from now there may be a rescan with higher quality. "Immutable" doesn't make sense in that context, does it? I see your point, but for future research purposes, it may be highly relevant to know that what someone cited in an influential paper 20 years ago they got from a low-quality scan. At least in the humanities, that's actually the kind of thing that some researchers care about a lot.
    - dalke 11y ago
      Yes, the linked-to article elaborates on that: > Even when the search turns up the proper source, it might not turn up the proper edition of the source, and for scholars, that level of distinction very often matters. In order to ensure that Reader B has every possibility of seeing the same thing in a source text that Reader A saw, B needs to know whether A read the edition of a book published in 1819 or the revised edition published in 1831, or whether A read an article as originally printed in the journal or as it was repackaged for inclusion in a later edited volume. Much like the situation in a laboratory, these variables matter, and so this level of precision in their citation matters. That said, DOI does not make the "promise that the content is immutable". I'll quote the DOI FAQ at http://www.doi.org/faq.html http://www.doi.org/faq.html : > The IDF does not have any rules on this. Individual RAs adopt appropriate rules for their community and application. As a general rule, if the change is substantial and/or it is necessary to identify both the original and the changed material, assign a new DOI name. That means I was wrong. DOIs could be immutable in that way, but aren't. I made the incorrect assumption that what happened for chemistry-related fields was indicative of a general policy, which it isn't.
verisimilidude 11y ago
Fundamentally, you are correct. In the current environment, most DOIs are issued by established journals, backed by relatively mature publishing software that knows how to keep a DOI up-to-date. Therefore, empty DOIs are not much of a problem at the moment. Also for the moment, DOIs are far more reliable than URLs. URLs are terrible for citations, often going dead before an article is even published. However, like you say, I could easily envision a future in which the current environment breaks down, new kinds of sites with less reliable software start issuing DOIs, DOIs go stale, DOIs don't adapt to changes in content models, etc. DOIs feel more like a band aid than a permanent solution. Long-term, I like the idea of publishing articles on a system like IPFS, where the content determines the address via hash, that doesn't change, and any publishing system that needs to cite an article could hopefully just "pin" it for preservation. Perhaps you keep immutable copies of your article revisions in IPFS, and marry them together via a mutable IPNS interface for consumption. This would assume all articles are open access, maybe, but that wouldn't be a bad thing.
- x1798DE 11y ago
  Does an IPFS system allow you traverse the revision tree? I think the ideal system would be one with a canonical identifier plus a content / version based identifier, so that if, for example, there is a retraction, you will know that by visiting the current version, but if you want to see the cited version, that is also available.
  - verisimilidude 11y ago
    I'd love to see that. I think versioning is possible in IPFS via merkle tree, but I haven't taken the time to understand how it would be implemented. https://github.com/ipfs/specs/tree/master/merkledag https://github.com/ipfs/specs/tree/master/merkledag
  - IanCal 11y ago
    That's something that would be possible with IPNS (which allows a mutable 'pointer' to an IPFS hash, though this is just my lay understanding). This way your IPNS address becomes your DOI equivalent, but also providing the IPFS hash would give a static reference to exactly what it was you saw. There are some kinks here, as there isn't currently a way of verifying that the IPFS hash given was seen at the IPNS address. You also can't take an IPNS address and get all previous versions. It does sound like that's possible to add to IPNS, but is a future plan. It would be a step forwards from the current system though. A bit of info on IPNS, which is in really quite early stages afaik: https://ipfs.io/ipfs/QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D/example#/ipfs/QmQwAP9vFjbCtKvD8RkJdCvPHqLQjZfW7Mqbbqx18zd8j7/ipns/readme.md https://ipfs.io/ipfs/QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxd...