Add subdataset dataset DOI/url to subdatasets view

[jsheunis]

As displayed currently on the "Publications" view.

[jsheunis]

IIRC only the catalog's javascript code needs to be updated for this change, i.e. nothing would be needed re catalog entry generation/update.

[jsheunis]

Ok, it was both JS and html, but not a major change... Here's a sample:

[jsheunis]

One thing to know about the decision to go with https://shields.io/ is that the current link references the online badge images, i.e. connectivity is needed.

[mslw]

Personally i'm OK with connectivity, can't remember ever viewing the catalog offline.

Also personally, I think it a badge feels a bit heavy, visually. Curious to get other opinions.

[jsheunis]

Here's an example with URL also shown. the url property on a dataset is an array, since there could be multiple URLs. At the moment I'm arbitrarily displaying the last element in the array. Also, I'm not displaying it in the same way as the two-part DOI | some/doi, because a dataset URL might be quite long, and that is visually not great.

[mslw]

Going back to this issue and taking a fresh look, I think I'm leaning (slightly) towards having the DOI badge and no URL badge.

At first I thought that showing the DOI like all other fields are shown (version, modified) would make most sense, and a badge looks a bit off compared to all other elements. But now I think that a doi badge looks like a "distinction" awarded to the dataset, which is probably a positive thing to do in recognition of good practice. Having a URL is less of a distinction, and the badge (short or long) looks more off than the doi badge.

[mslw]

Note: one way to display badges without relying on external services could be to have two divs (one containing word "DOI" and the other containing doi itself) styled with color and border-*-radius, possibly in another div - GIN does that.

And BTW, the JS code powering shields.io, badge-maker is CC0. Badgen, the library powering badgen.net is ISC licensed, and should be lighter.