learndb VS tag

I ran into the same problem while building https://learnawesome.org/ . Forget the broad class of "learning resources", even the "books" category doesn't have a usable unique ID. Not everything gets an ISBN for example. There's also the ambiguity between a "work" and an "edition" of a work.

This is probably why OpenLibrary supports mapping of books with 40+ identifiers: https://github.com/internetarchive/openlibrary/blob/master/o...

I loved using Svelte for these two open-source projects but haven't yet an opportunity to use it at work:

- An SVG-based graph dataset editor: https://codeberg.org/nilesh/grapher

- A curated collection of educational resources: https://github.com/learn-awesome/learndb

Compared to React, developing with Svelte felt like a breath of fresh air.

A couple of my tools that don't require signup:

- Grapher (a visual editor for graph datasets with features like nested nodes, custom attributes on nodes and edges, and export in Cytoscape JSON or SVG format. Accessible at: https://grapherx.netlify.app/

- LearnDB (A curated collection of links to educational resources organized by topics, formats, reviews and other tags). Accessible at: https://learndb.vercel.app/

For those who're curious, the app is mostly completed - although the dataset could be enriched further. You can try it online here: https://learnawesome.vercel.app/ but it's designed to work best when run locally: https://github.com/learn-awesome/learndb

Nature + Identifiers is an issue (e.g. see https://github.com/tdwg/tag/issues/36). I've routinely mentioned to others in my field to look at other industries for ways forward, particularly ones like the music industry, so its interesting, if unsurprising to see all the same problems arise there. For those who know, in our field, when Identifiers comes up in conversation at conferences etc., we tiptoe away, somehow people can't learn from the past issues.

There are two issues that keep coming up in my mind 1) People want Identifiers to do something (like resolve), rather than just be identifiers and 2) People think that there are such things as "unique" identifiers (one identifier per "thing"). Neither, in my mind, are the purpose of identifiers. Identifiers should do one thing, localize you to some concept. By localize I mean that if you can find the digital space (or in physical collections where identifiers are used the physical "printed" identifier) that "contains" the identifier then you should have a reasonable probability of finding the thing/concept that identifier is for. That's all. No certainty, no uniqueness. It's very akin to what we do when we cite something in a publication, we are giving the research a reasonable chance of finding the origin. This isn't to say that we shouldn't try to keep identifiers unique though, it's to say that when it comes down to crunch time we should never assume 1) they are unique, and 2) that their special properties (e.g. that they resolve) actually work.

I've seen numerous identifier schemes come and go, we've specifically designed a 1-many for our things-to-identifiers in our systems (sitting on top our internal IDs). DOIs? They must be unique, right? Nope. Institutional CODENs? Nope (though the botanists have done it pretty well through community peer-pressure).

As others have noted, identifiers really are just labels, though things like UUIDs have the game-changing property ofreducing the probability that you're looking at a homonymous label.