GREI 5: HDV Task - Test and gather feedback on TK Label vocabulary support on demo.dataverse.org

[cmbz]

Overview

• Support for the TK Labels controlled vocabulary is now available on demo.dataverse.org
• Prospective users will test the feature and provide feedback in the comments on this issue.
• Feedback period:
  • 2024-08-22 to 2025-01-15

Related

• GREI 5: HDV Task - Indigenous Data Support #170

[cmbz]

Status: August 2024

• Feedback period for TK Labels controlled vocabulary testing began and will continue until 10/31/2024

[cmbz]

Status: September 2024

• See comments here: GREI 5: HDV Task - Indigenous Data Support #170 (comment)

[sbarbosadataverse]

From Amber:

Wonderful, I'm in and created a test record with the linkage to a test TK label https://demo.dataverse.org/dataset.xhtml?persistentId=doi:10.70122/FK2/P0KTIF

Few things for later:
The TK label box that appears in the metadata and on the dataset landing page is quite large, I get that might be to support many labels/etc. But wonder if this could be optimized to fit the size/number of labels in the future?
I wasn't sure if the DOI lookup was ready, I didn't see anything appear when attempting to search for a "doi..." is there a doi you recommend? So I also did notice that it was allowing free-text searching and I linked to a "test TK label" for this dataset, in the future, what will be the recommended workflow/ practice for searching for a LC project? It appears that I can link to anything and everything if I want, and I'm not sure this will work for the LC/ general recommendations and just knowing that a lot of people might see this and link to something inadvertently....
I noticed the LC TK labels URL shows up the Metadata Export JSON record , yay! But is not available for DataCite, or schema.org - looking forward to seeing how those mapping conversations go, and fyi as an aside I recently attended a national metadata group's meeting here in Canada and a Oceans Data group mentioned that they would like to see LC TK labels be mapped into ISO 19115 - Geospatial data as well. I know DV doesn't support that standard metadata (yet!), but just highlights the interest from the community and the wider adoption of LC TK labels in other repositories 🙂
Thats all for now, many thanks!

[amberleahey]

Issue with the display of the TK labels disappearing after some time

[transfluxus]

https://github.com/gdcc/dataverse-external-vocab-support/blob/5c341a0c2ec727c9c65026faaab7eff5ea221bd9/packages/local_contexts/local_contexts.js#L114

after checking for an uuid, it should also check if its a complete project_url (e.g. https://localcontextshub.org/projects/54be05d7-aa5c-4886-abd9-dc45b2fa8df4 ) and in that case hit the api like with the UUID

change the text here:
https://github.com/gdcc/dataverse-external-vocab-support/blob/5c341a0c2ec727c9c65026faaab7eff5ea221bd9/packages/local_contexts/local_contexts.js#L90C1-L90C83

to
"Search for a project by name or paste the exact project ID or url"

I dont have my testing instance anymore but something like this:

if (uuid_regex.test(params.term)) {
    //await get_or_fetch(params.term)
    return `${serviceUrl}api/v1/projects/${params.term}`
} else if(params.term.startsWith(`${serviceUrl}projects/`)) {
    const uuid_part = params.term.slice(`${serviceUrl}projects/`.length)
    return `${serviceUrl}api/v1/projects/${uuid_part}`
} else {
    return `${serviceUrl}api/v1/projects/?search=${params.term}`
}

[transfluxus]

When entering a UUID into the searchfield searches the project, but the result items, has the UUID as 1. item and the project name as 2nd. It should only have the project name

[transfluxus]

the script is making a lot of calls to the LC server, during typing.

also, the script is including an image linking to:
https://localcontexts.org/wp-content/uploads/2023/04/White-Background.png

@arojas1 is there a better location, where we can pull it from

[sbarbosadataverse]

From Janet (Australia) to Local Content Folks:
Q for LC: Will public LC Projects ever be restricted periodically due to cultural reasons?
Should LC private projects ever be made available in Dataverse?

[arojas1]

the script is making a lot of calls to the LC server, during typing.

also, the script is including an image linking to: https://localcontexts.org/wp-content/uploads/2023/04/White-Background.png

@arojas1 is there a better location, where we can pull it from

@transfluxus I believe you are using your own script to mimic what we did for the embeds, is that correct? If so, feel free to leave the LC logo out of the script. As long as the link back to the Project is available, that is enough for that block. If Dataverse would like to use the LC logo elsewhere, we can discuss other options!

It is up to you but if there is a way to have a search button, that may help with the typing to search function. So they can type the title either partially or fully but the API won't be called until they click search. For our search options we typically add a few seconds delay between input and API calls. Not sure if it is already doing this but that is another option as well.

---

From Janet (Australia) to Local Content Folks: Q for LC: Will public LC Projects ever be restricted periodically due to cultural reasons? Should LC private projects ever be made available in Dataverse?

@sbarbosadataverse LC Public Projects will never be restricted. We leave that privacy option up to the users. If they feel the need to change a Project's privacy from public to contributor or private, that is up to them, but we won't remove access to public Projects ourselves.

With v2 of the API coming out in January, there will be the option for users to search by their private and contributor Projects via their API key, but it is not recommended when it comes to displaying on a database or repository like Dataverse if it is meant to be publicly visible. Now, if the Dataverse instance is an internal use for staff or a similar situation, there can be an argument made that the Project is kept private or in contributor view for the community (if notified or Labels applied) or the internal staff to see. But if visible by the public, we would hope that the Project will be public on the LC Hub as well as a reference to that Project and the associated Labels/Notices.

I hope this makes sense! Happy to answer any additional questions or take a closer look at use cases.

[philippconzett]

Thanks for pulling all this work together to create a Dataverse Local Contexts integration! - and sorry for my late feedback.

I've gone through LC documentation and the docs @sbarbosadataverse pointed to in her message on Zulip, and left some comments and questions in the technical plan document. My main concern is that the current implementation doesn't support the need to reflect metadata changes of the Local Contexts Project related to a dataset in Dataverse. In principle and to ensure traceability, I'd expect any metadata changes to be reflected in a new (minor) version change of the dataset, with the complete metadata of the previous version being stored in the Dataverse database. This behavior is even more important in cases where this provenance information is not kept (or at least not obviously displayed) in the source application, e.g. LC Hub or ROR. I also think providing this information locally in Dataverse is more important in the LC case than, e.g., for keywords entered directly into the Dataverse citation metadata schema. For example, a change of a TK Permission Label from TK Open to Commercialization (TK OC) to TK Non-Commercial (TK NC) has direct consequences for the further (re)use of the data made accessible in a dataset related to a LC Project, whereas a change of keyword often doesn't have any deeper impact.

As revealed by the discussions in the technical plan document (@sbarbosadataverse, @janetm, @qqmyers), syncing changing metadata information between the LC Hub and Dataverse is not trivial, but I wonder whether a first step could be to

1. add more LC Project metadata fields to the LC metadata block in Dataverse;
2. populate these fields with values fetched from the related LC Project at initial association; and
3. leave subsequent updating as a manual task to the depositor, preferably together with / verified by a curator.

[transfluxus]

Hi Philipp,

thanks for the suggestions and comments to the document.

To have the metadata of a LC projected as part of the dv metadata.
You can see a version of a metadatablock for that here
https://github.com/RIDAGOP-Toolkit/Local-Contexts-Dataverse-Metadata-block/blob/main/localcontexts_dv_metadatablock.tsv

There are several issues with this.

• This might easily be a lot to type/copy over, making it very impractical to do it manually. I made it part of a toolkit that I developed to make that automatically.
• A metadatablock is (or at least it wasn't) able to capture a full structure of LC project metadata, or at least it wasn't able to visualize them. That is because each Label (in a list of labels) can have a list of translations. This nested composite structure could not be displayed in the dv UI, and that is probably ok, because that kind of structure can easily be very confusing. Including all Labels even without translations, could already look like if there would be an error, because there could be multiple instances of the same Label and possibly the same text on a project, but coming from different communities.
• To have a more minimal approach was, after I present the prototype of metadatablock to the LC people, a preference of theirs.

Would it be sufficient, if the dv metadata block would include a LC project version? Changes would then be traced on the LC hub. I don't know if they are planning this type of feature tho.

[philippconzett]

Thanks, @transfluxus!
I thing anything that adds information about the LC project will help.

Maybe the suggested storage of LC project metadata in Dataverse will be possible in the future SPA architecture? See, e.g, the recent discussion about integration with CEDAR.