search

metadata-research / yamz

A crowd-sourced metadata dictionary
MIT License
9 stars 3 forks source link

Add relations for inter-term navigation #155

Open machawk1 opened 1 month ago

machawk1 commented 1 month ago

When viewing a term that has multiple entries, other entries with the same name (e.g., "Glacier") are not accessible from the term currently being viewed. This can be accomplished in a variety of ways and is a missed opportunity to leverage Linked Data, relations, etc. This might also assist the user in locating the term that more aligns with the variant of their understanding.

I can imagine this being implement from either/both of UI elements but also out-of-band semantic web info like the Link HTTP response header (a la Memento).

cr625 commented 1 month ago

Right now they are displayed when you click on the number in Alternative Definitions under the term itself. Is this what you mean? It's definitely not obvious, though.

machawk1 commented 1 month ago

@cr625 Yes, in terms of UI elements that suffices. Would we be able to surface that data in a machine-readable way? On the flip side, this would increase the size of the payload for each term, albeit perhaps trivially.

cr625 commented 1 month ago

@machawk1 we could return arbitrary data at a URL endpoint. Would this be a one-off or part of a more structured API?

machawk1 commented 1 month ago

@cr625 An API would be useful internally as a means to associate the terms with identical spellings. For example, considering the Glacier instance at ark:/99152/h5949 (which resolves to https://yamz.net/term/ark/h5949), upon resolution we might also use this "key" as a basis for an API to get ARKs of terms with the same spelling. The resulting association (e.g., the other Glacier ARKs and perhaps their term strings) could be represented in the HTTP response headers. This could be use to populate the UI element you mentioned as well.