Recent searches
Search options
#ISBN is a centralized system, you even have to pay not insignificant amount of money to get a number.
I can't even figure out how to self-assign a #DOI .
Is there anything else that helps identify #publications that doesn't have gatekeepers?
Like some equivalent of a #torrent infohash?
Would a #blockchain solution solve problems like collisions easier than any alternatives?
@dcz There are URIs. You could use urn:uuid:, if you really want to avoid DNS (though https://nic.eu.org/ will provide a domain name to anyone who can fill in this form: https://nic.eu.org/arf/en/contact/create/).
@dcz There's no way to get a useful identifier without gatekeepers. Even the words I am using in this sentence are subject to convention. "No gatekeepers" is too high of a bar: "sensible gatekeepers" is a better standard, I think.
@wizzwizz4 That's why I mention blockchain. Once a single gatekeeper emerges, the network disintegrates.
Arguably, bitcoin is still useful regardless, so it is possible.
We can also publish bittorrents without a single gatekeeper through DHT and infohashes.
@wizzwizz4 DNS is full of gatekeepers, though. Registrars like the one you listed, the TLDs. Not resilient enough to survive 100 years IMO.
@dcz Opaque handles (hashes, UUIDs) are not going to last: a useful identifier needs some kind of provenance, and has to be dereferenceable without checking everywhere. URIs have a scheme and (often) an authority; DOIs have authorities; the publisher and approximate issue date can be derived from most ISBNs.
If you want something to last long-term, it has to be redundant, and useful to a librarian. Anything else is useless. Digital artefacts are incredibly fragile.
@dcz Example: suppose you reference a particular chapter of a book. You reference the second edition, but we've lost that: only the first and third editions remain. Not so bad, huh?
Except that's only useful if we have the book's title, author, approximate language and year of publication… enough information to identify the book within its social context. An xt magnet URN that's no longer seeded is completely useless. (Magnet URIs have a Display Name field, which can provide this redundancy.)
@wizzwizz4 ISBN shares the same issues: it doesn't include the title or the author or a lot other metadata. Hashes can also contain small metadata inside, except they won't be verified by a third party (but ISBNs are re-used so verification is a moot point).
Is there anything that can't be done by a hash that is done by ISBN?
@dcz For ISBNs there exists a redundantly-mirrored database of who issued them, and (in most cases) also the title, author and publication date. If that database is lost, we can reconstruct much of it by examining the books in libraries, knowing that ISBNs are allocated in blocks of various sizes.
There's no such database for hashes, afaik, and even if there were, you couldn't reconstruct it easily if it were lost. (You could only recreate entries for already-known files, not lost ones.)
@dcz Hashes don't normally contain metadata, but I understand that you're using the term broadly, and you're not wrong.
ISBNs are not often re-used. It happens enough that programmers need to take it into consideration, but it's still quite rare. (The Rust Programming Language book re-uses not only the ISBN, but the label "2nd edition" also. There's not much you can do about that kind of abuse, sadly.)
There's nothing wrong with using hashes in addition, but they're unsuitable as a sole ID.
@wizzwizz4 I'm not sure if I understand correctly. You can't recreate the metadata of lost books just by looking at other books, if you don't already know there's a book with matching metadata (there exists another book from the same publisher).
You can recreate a hash and metadata for a file you have just the same as you can the ISBN of a book (because it's printed on it).
The existence of a database is a matter of convention in both cases.
What's difference were you pointing out?
@dcz The Handle System, which is a superset of DOIs.