-
Notifications
You must be signed in to change notification settings - Fork 6
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
Add Local Lookup for RDA Terms #385
Comments
If I create a yml file for one as a proof of concept that we can test, perhaps we can script the translation of RDF descriptions of these terms to the yml file that QA needs. |
Confirmed again that there's no API. |
@sfolsom You mentioned: "The ids in the yml will need to be the URI for the term, and the term in the yml should be the preferred term in English.", but it looks like we can include separate id and uri fields for each term. For something like: http://www.rdaregistry.info/termList/AspectRatio, I can create a yml with the following:
Would that work? Otherwise, using a uri for id seems to break individual term fetching as is (e.g. /authorities/show/local/rda_aspect_ratio_designation/1001 vs /authorities/show/local/rda_aspect_ratio_designation/http://rdaregistry.info/termList/AspectRatio/1001). |
Also, do we want to include all terms in the local lists, including deprecated terms? Example of vocab with deprecated and published terms: https://www.rdaregistry.info/termList/RDATerms/ |
Good questions! I think we shouldn't bother with a fetch test for these (which is really just a test that the API is up and running) since these are "hard coded" into the lookup service with the yml file and not connecting to an external service. If the id: value is the URI is the same as the cities pick list, I think that would be ok. I think for now we can/should include the deprecated terms so that catalogers who are familiar with a term can see that it's deprecated, and should use something else. |
Sounds good - will change it so that id and uri are the same:
Fwiw, there seem to be 3 different endpoints for connecting to local controlled vocabulary:
So a benefit of the individual term fetching endpoint for local controlled vocabulary is that we could theoretically add additional information for each term that wouldn't show up in search. We could also set that "active" boolean field to false for deprecated terms - terms with No changes suggested, just some context I found when digging around that I thought could be useful! |
Ready for testing on lookup-int! There should be 48 new local lookup endpoints, each local subauth in the endpoint urls is the name of the vocab but in lowercase snakecase. For example. the endpoints for RDA Video format is:
RDA Aspect Ratio Designation:
Etc. Please let me know if you'd like any changes/if you notice anything strange! |
I've started taking a look at these, and the search results look good. (I'm still going to go through each of the 48, but one thing I've noticed so far is that there's no |
I noticed the missing uri also wasn't showing up for https://lookup.ld4l.org/authorities/search/local/publisher_cities_select_list?q=London either, so wasn't sure if that was just expected behavior. Oddly, uri and id are showing up in the json in my local environment though – I'll poke around to try to figure out what the difference is. |
I just looked at the cities lookup in Sinopia, and it's not adding the URI to records when I try to link to them. Want me make a separate issue to add "uri": to that lookup? |
The upgraded qa gem has been deployed to lookup-int, and I've confirmed that the uri fields are now displaying in the json response, e.g. https://lookup-int.ld4l.org/authorities/search/local/rda_aspect_ratio_designation?q=screen. But if Sinopia is still sad about the updated response, please let me know! |
Samvara QA code has a sample yml file to add a controlled list locally to a QA instance: https://github.com/samvera/questioning_authority/blob/main/config/authorities/states.yml
RDA Registry doesn't seem to have a search API that we can use to create a direct lookup, so we need to add a file for each of the RDA Reference value vocabularies found here: https://www.rdaregistry.info/termList/. The ids in the yml will need to be the URI for the term, and the term in the yml should be the preferred term in English.
I'm not sure if our instance is set up for these types of lookups, so we'll have to do some testing.
The text was updated successfully, but these errors were encountered: