Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Controlled vocab terms standardize the protocol on stored uris #1342

Open
CGillen opened this issue Oct 22, 2020 · 6 comments · Fixed by #3056 · May be fixed by #3196
Open

Controlled vocab terms standardize the protocol on stored uris #1342

CGillen opened this issue Oct 22, 2020 · 6 comments · Fixed by #3056 · May be fixed by #3196
Assignees
Labels
Enhancement Features Issues related to building and enhancing features Metadata Issues related to metadata configuration, application, and representation Ready for Development The issue has passed review from teams and is ready to be worked on

Comments

@CGillen
Copy link
Contributor

CGillen commented Oct 22, 2020

Descriptive summary

Controlled vocab terms should be permissive in what they accept and rigorous with what they store. Before a fetch, controlled vocab terms should accept either http:// or https:// in uris, but when they receive the response it should be stored back in a standard protocol.

This is to help with bulk editing later, when you have thousands of values in a column and trying to sort on that column sorts on protocol first.

@wickr I assume this should be configurable at the vocabulary level? So we can force all the uris from an individual authority to be the same.

Expected behavior

URIs can come in as either http:// or https:// from the work form and bulk edit workflows, and the fetch request will gracefully handle communicating with the authority.

URIs are stored back in fedora and solr as either http:// or https://, configurable by the authority/vocab, regardless of input, request, or response.

Related work

Accessibility Concerns

@CGillen CGillen added Metadata Issues related to metadata configuration, application, and representation Review Needed Needs review by team lead of associated team labels labels Oct 22, 2020
@CGillen
Copy link
Contributor Author

CGillen commented Oct 22, 2020

Assigned @wickr to review and make sure I didn't miss or misunderstand anything. Then tag with ready for work and features

@KevinJonesMeta KevinJonesMeta added Features Issues related to building and enhancing features Ready for Development The issue has passed review from teams and is ready to be worked on and removed Review Needed Needs review by team lead of associated team labels labels Nov 21, 2023
@wickr
Copy link
Member

wickr commented Nov 21, 2023

Ensure that this works for typeahead label lookup in the form as well.

@wickr
Copy link
Member

wickr commented Oct 17, 2024

QA Fail.
Mostly works. I saved 2 URIs (one http, one https) for several properties, and the one that failed was Creator, with LCNAF and an http URI. The label was found in typeahead and looked ok on the form. But it saved as http. The label doesn't fetch, but it does for the https one.

Test work: https://staging.oregondigital.org/concern/images/cv43nw84m?locale=en#data_sources

Test URIs for Creator:
Oregon - http://id.loc.gov/authorities/names/n79021953
Oregon State University. Library - https://id.loc.gov/authorities/names/n00020490

@wickr wickr reopened this Oct 19, 2024
@lamtu1 lamtu1 self-assigned this Oct 21, 2024
@lamtu1
Copy link
Contributor

lamtu1 commented Oct 21, 2024

@wickr Can I have you check out the test work you did again? I figure out that the cacheing was the issue the label was not displaying for the those weird uris link you given me so I try manually delete the statements off from cache but it didn't work. So I have to go in and delete the entire cache and resave it and it works on staging.

So I am currently trying to resave all works on staging so it can update it cacheing but the issue should be fix now hopefully and was wondering if you could do another test on it? Thank you!

@wickr
Copy link
Member

wickr commented Nov 8, 2024

Still QA Fail

@lamtu1
The original test work looks good.

But I made another one, and added some different URIs. Some work, some don't.
https://staging.oregondigital.org/concern/images/0z708w45r?locale=en#data_sources

The new URIs for Artist work. They both seem to save as https

But I was able to save one for Photographer as http. At first, in the form, the label fetched. So it was saved. But on display, it's not showing. And then when trying to edit again, the form says unable to fetch label.

image

I then added 2 more URIs in Subject. Both looked ok in the form, label fetched there. But when I saved, both URIs only saved as http and neither label fetched.

Test URIs for Photographer:
McMullen Portrait Gallery - https://opaquenamespace.org/ns/creator/McMullenPortraitGallery
Hofsteater Photograph Gallery - http://opaquenamespace.org/ns/creator/HofsteaterPhotographGallery

Test URIs for Artist:
Gogh, Vincent van - https://vocab.getty.edu/ulan/500115588
Monet, Claude - http://vocab.getty.edu/ulan/500019484

Test URIs for Subject
Alder Theater (Portland, Oregon) - http://opaquenamespace.org/ns/subject/AlderTheaterPortlandOregon
Columbia River Highway, Oregon - https://opaquenamespace.org/ns/subject/ColumbiaRiverHighwayOregon

@lamtu1
Copy link
Contributor

lamtu1 commented Nov 8, 2024

There's a needed discussion about the bigger picture on this and other parts as well regarding of fetching and backend Bulkrax that link to this ticket during next work cycle.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement Features Issues related to building and enhancing features Metadata Issues related to metadata configuration, application, and representation Ready for Development The issue has passed review from teams and is ready to be worked on
Projects
5 participants