Open poikilotherm opened 3 years ago
@poikilotherm it sounds like we'd be able to clean up how Topic Classification looks. Right now there are long URLs at the end like this...
... but with your proposal, we could make the terms into hyperlinks, like this:
(This example is from https://doi.org/10.7910/DVN/TQBAEE )
FWIW: As discussed in DCM2021, the new external vocab support as currently defined (#7946) would not use this feature, as it has the service-specific JavaScript handle display. That nominally allows the JavaScript to reorganize compound fields into nicer html as discussed here (or do #6289), and to do that when there's only a single term URI field as well. (It also allows the JavaScript to get i18n versions of the term/vocab names involved (the internal CVV field definitions can have translations and #7923 will get them displayed, but external vocabularies don't store i18n values the same way, and with the option to just use a single term URI field instead of a compound field, having the JavaScript manage i18n as well helps keep things simple.))
@qqmyers now that external vocab support is in place, I have a question for you.
Is the JavaScript thing also saving a searchable composed string in Solr or is this HTML display related only? This would also be a thing for metadata retrieval via API, where no Javascript can be involved.
Asking this because I know you wanted to do caching of fetched data, so maybe the composed UI string is stored for a composed field, too.
If this is not the case, do you think it would be a feasible extension to implement this?
@doigl @pdurbin Rethinking the search part, it might be a good idea to add a new column exportFormat
. Some metadata fields make profit from allowing HTML tags for UI candy, but this is bad for searches.
A formating as cleartext might not only benefit compound fields, but also others that would benefit from an enhanced UI view and a clean, maybe machine interoperable export value.
Once we have an exportFormat
, this would be nice for metadata export formats, fetching via JSON API and searches.
(@pdurbin when attacking this, would it be a good time to transform the TSV to JSON/YAML to make it more readable and extensible? Would prefer YAML because comments.)
The current implementation indexes the URI and leverages the Javascript to allow you to type the term name/leverage the autocomplete functionality to select a search term. So the user is typing in their language/using the term name, but the search itself is for the URI, which matches the URI in the index.
Context
Problem
author
, only theauthorName
, etc)We want users to input metadata with as much detail and structure as possible (controlling vocabularies, ...). Yet recipients think in bigger context/pictures, expecting composed views (both text or images like in #6289) and easier to memorize search tags (
author
, notauthorName
).Examples
operatingSystem
as part of the CodeMeta MDB (#7844):operatingSystemName
(a CV) andoperatingSystemVersion
operatingSystem:"Windows 10"
oroperatingSystemName:Windows AND operatingSystemVersion:10
, but alsooperatingSystem:"Windows.*"
) oroperatingSystemName:Windows AND (operatingSystemVersion:7 OR operatingSystemVersion:10)
keywordValue: "Surfactants"
keywordVocabularyURI: "http://data.loterre.fr/ark:/67375/37T-JDM7BJHX-0"
<a href="http://data.loterre.fr/ark:/67375/37T-JDM7BJHX-0">Surfactants</a> (Loterre chemistry vocabulary)
Proposal
displayFormat
for compound fields, too.#subFieldName
.Extensions
displayFormat
, to lookup text parts from a subfields value (example: lookup a link prefix to generate a clickable author identifier, for example using the ORCID to link to https://orcid.org/..., but also usable for other types of identifiers.)