Consider exposing database IDs for easier access

[ptkw]

Hello,

many thanks for your work on Metron! It is a very promising project and I have high hopes for its future. Here's a feature request for your consideration.

One feature that I know from various public databases that seems to be missing in Metron is the easy access to unique identifiers of all the various items.

As far as I understand it, currently the only way to learn the ID of a given item (other than a single issue - issues do have their IDs listed on their pages) is to ask the API for it (which requires mentioning the item by some other property, such as its name).

Compare it to services such as Comic Vine, BoardGamegeek or IMDb, where IDs of items are included in the URIs of their respective pages:

https://comicvine.gamespot.com/batman/4050-796/
https://comicvine.gamespot.com/bob-kane/4040-19137/
https://boardgamegeek.com/boardgame/42/tigris-euphrates
https://boardgamegeek.com/boardgamedesigner/2/reiner-knizia
https://www.imdb.com/title/tt0068646/reference/
https://www.imdb.com/name/nm0000338/

In the most relevant case of Comic Vine, note that I can access the same page for Batman Vol. 1 using the URL scheme I would also use when calling the API: https://comicvine.gamespot.com/volume/4050-796/ (with volume instead of Batman). This feature is apparently absent in Metron; I can't point somebody to an item's web page if I know only its ID (I would be forced to query the API for its resource_url first).

I think that exposing IDs in the catalog's URIs is a good practice. For one thing, it establishes a canonical way to refer to a given item (either in the link opened in a browser or in an API call). If I were compiling a personal comic database of some sort, I could then have a metron-id column that could be used for both generating links to Metron's catalog, and making some API calls about it.

Even if you don't like the URI idea (e.g. for SEO or aesthetic reasons), please consider adding the "Metron ID" field to page templates for all the kinds of items that have an ID.

[bpepple]

What would be the use-case for this? I'd be leery of making a change like this unless there was a real compelling reason to do so.

Regarding adding Metron ID field to the other resources, it's on my TODO list but fairly low-priority.

[ptkw]

I'm afraid you'd have to ask someone more knowledgeable about data science for a truly compelling argument; however, here's my best amateur attempt.

If Metron becomes popular as an open source of information about comic books, Metron ID could become the open standard for unambiguously referring to various comic-related entities in a wide variety of contexts, including integration of data from various sources (IMDb ID functions as a de facto standard of this kind for audiovisual material). It then seems plausible that someone, somewhere will end up with a piece of data containing only Metron IDs but no URLs to items on Metron website. It would simply be convenient to have the ability to convert IDs into working URLs, when the need for them arrives.

There is an added benefit from the perspective of keeping Metron website an authoritative source of information. URIs based on IDs can be stable over time, which isn't necessarily the case with URIs based on names. For instance, if a publishing business or a creator included in the database changes their name in the future, this would necessitate a change in the URL for their page (note that especially in the case of people, it sometimes becomes socially unaccaptable to refer to them by their former name); that, however, would cause link rot of any previous references to them on the web. An address of the form https://metron.cloud/{ID}/{name} would prevent this by providing what is called a persistent identifier. Note that on other database sites (or Amazon, for that matter), the portion after the /{ID}/ is often purely optional and included only for human readability or SEO.

Having the same scheme for API calls and website pages also removes the need for redundant fields in all kinds of future datasets that would refer to Metron in some way. It seems obviously easier and simpler to have a single metron-id field and derive website links from it if needed, rather than requiring an additional metron-url field along with it.

I'm just a lowly tinkerer, but for what it's worth, whenever I wrote scripts interacting with open databases for my personal use, I very often relied on copying and pasting IDs between my code and the address bar in my browser.

I should stress, however, that the whole website URL aspect of my feature request is actually secondary. I'm very happy that you're planning to include the Metron ID field on the entity pages in the future! Thanks for considering my suggestion in any case.

If you have a while, you can take a look at this PDF white paper which explains why permanent identifiers are a Big Deal in the open data world.

[bpepple]

I see some benefits, but I'm not really sold at this time that it's worth the time/effort to implement it. I've already got a fairly large list of projects to work on, but if someone else is interested in working on this I'd be willing to review it.