3 ms·

> Whilst we could adopt Multihash here, it's much more complex than we need (famous last words?!?). So OP has the option of adopting an existing (and clear) sp

• adamretter 6y ago
  > So OP has the option of adopting an existing (and clear) spec, with existing libraries (and and existing governance structure) and because of what feels like a not-invented-here mentality (yeah well, I can't imagine needing this complexity), OP has decided to develop a new standard, without an existing spec, without existing libraries and without existing governance structure. I think perhaps my article was too light on the requirements that we face as a National Archive, or perhaps the Digital Preservation and Access domains are just quite specialised. The article was designed as a thought experiment to solicit feedback on one possible idea. The project is currently in a Proof-of-Concept phase and so such experiments are quite valid. We certainly have not yet decided on this scheme. That being said, Archives have very different requirements in their identifier schemes and standards to other organisations. It is not so much a "not-invented-here" as "must-work-here" mentality. We always look around at existing standards and specifications before developing anything ourselves, we have to have good reasons not to use something that already exists, i.e. it won't work in an archival preservation context. > All these ideas in online data sharing, semantics and interoperability are great, but I think people underestimate how much effort it actually is to create a good standard, a good spec, and how exponentially more effort it takes to keep such a standard in a shape that's working for more people. I hope I have a fairly good idea what it takes to establish a standard. I was an invited expert to three W3C Working Groups, and I have also participated in a number of Community standards groups ;-) > The extensibility for OP's identifier is extremely narrow. Just look at how many hash functions and properties are currently already supported by the IPFS I think that missed the point of the what is required. For use in an archival context we don't need to support every hash-scheme out there. Quite the opposite, we want to support as few as possible. In 100 or 1000 years we don't want digital archaeologists to have to work hard to access the data. Ideally we will support just 1 hash scheme right now... something robust that will likely have no intentionally crafted collisions for many years (e.g. Blake256). If and when a collision is developed for that hash, then we will support a second hash algorithm, and so on ;-) I actually really like IPFS and Multihash, but are they suitable for use as archival identifiers within a National Archive?
  • zvrba 6y ago
    > Quite the opposite, we want to support as few as possible. Indeed. It's impossible to tell whether two given hashes, computed with different algorithms, refer to the same object. I can imagine that's kind of bad in an archival context.
  • lcrz 6y ago
    Hi OP, First of all, let me say I'm not questioning your expertise or your good intentions. I'm a great fan of (and following closely) a few standards or proposed standards championed by the W3C, mostly related to RDF, verifiable credentials and digital identity, so a bit different from digital archiving. To be a bit more constructive instead of my comment above, I think if the aim is rediscoverability in 100 to 1000 years, what your current proposal is missing, is semantics. Bits are just bits. Discovering what the bits mean is actually a great deal more difficult than checking if a checksum is still valid. Indeed, this gives bits a certain color. A question that you pose, is 'If I change the name of the file, is it still the same digital file?', but you do not get further into an answer. While a filename might be an arbitrary label, the color of the bits (or the intent of the creator/archiver of the file), in my opinion, might be interested for inclusion.