There are some issues with querying NAMES in lookups from ID.
Investigating the set up of how QA is using NAMES from ID.LOC.GOV, we realized it's querying ID directly, not the cache. So, when querying the name, Kaufman, Peter Iver, for the Work (On Agamben, Arendt, Christianity and the dark arts of civilization): https://trellis.sinopia.io/repository/chicago/c23d0dd1-d804-43c0-8027-6c107c28cf57 I found that this name was not coming back directly even though the correct form was verified in authoities.loc.gov before hand and was tried with and without a space after Iver . Experimentation showed us that ID has a similar issue. The '
left-anchored' approach to names in the NAF does not return the same efficient results in ID. I also noted this when querying University of Chicago. Library in ID (and in Sinopia) but ONLY returns from a reference, "Regenstein library" from ID. ID is simply not structured the same way as the 'left-anchored' order of the NAF - which leads to much inefficiencies
I am aware that this is largely an ID issue - but this is super connected to our ongoing cataloging work in Sinopia and its iterations over time`.
@sfolsom @michelleif My thoughts, since it is a direct query, it is an ID issue and should be conveyed to the owners of id.loc.gov...but obviously, SF would know better than me, thanks
Oh boy. I'm going to need help with understanding this.
What QA api path is being used? Based on a quick look here - https://lookup.ld4l.org/authority_list - the entries related to LOCNAMES all appear to use the LD4 cache. Said another way: they do not appear to hit ID directly.
All searching of LCNAF and other LC authorities are done against the cache. There is a way to use QA to directly search id.loc.gov, but I'm pretty sure that Sinopia does not surface that. I'll have to double check.
I looked through the configs for Sinopia and it only surfaces access to LCNAF through the cache. There are some small controlled vocabularies that do query id.loc.gov directly. But that does not include name searches.
@jyssy I'm wondering what makes you think that names are being search directly from id.loc.gov. Maybe I am not understanding what you are seeing.
@elrayle @kefo Thanks for your examination. we have noted identical results in type of responses that don't seem to reflect a left-anchored search. For instance, when one searches the University of Chicago. Library, results are nothing. The variant name actually returns the correct result. Nobody could foresee that type of result. This is the case with ID and with QA. My first question followed this example with no results based on the heading in the form it is in the file and at the linkeddata service (ID). Also,I thought that was so because when we were having the meeting, someone was looking at those config files while we were in the meeting and told me it looked like a direct query. no stress (maybe there was confusion as to what was cache and what was direct - during the meeting). Not sure. I don't think the issue is one-sided here - but I could be wrong. Do we need to turn all the focus back to QA? @sfolsom Want me to help with something - since it looks like this issue is swinging back around? what do you think? thanks
@jyssy what template are you using? Using https://sinopia.io/editor/CornellSinatra45:Work, when I search both "University of Chicago. Library" and "Kaufman, Peter Iver" (without quotes) I get the expected results.
@sfolsom I get the same results in id.loc.gov (I think it is this similarity in results that maybe confused what we thought is cache and what is direct query.
@jyssy commented on Mon Apr 06 2020
There are some issues with querying NAMES in lookups from ID.
Investigating the set up of how QA is using NAMES from ID.LOC.GOV, we realized it's querying ID directly, not the cache. So, when querying the name, Kaufman, Peter Iver, for the Work (On Agamben, Arendt, Christianity and the dark arts of civilization): https://trellis.sinopia.io/repository/chicago/c23d0dd1-d804-43c0-8027-6c107c28cf57 I found that this name was not coming back directly even though the correct form was verified in authoities.loc.gov before hand and was tried with and without a space after Iver . Experimentation showed us that ID has a similar issue. The ' left-anchored' approach to names in the NAF does not return the same efficient results in ID. I also noted this when querying University of Chicago. Library in ID (and in Sinopia) but ONLY returns from a reference, "Regenstein library" from ID. ID is simply not structured the same way as the 'left-anchored' order of the NAF - which leads to much inefficiencies
I am aware that this is largely an ID issue - but this is super connected to our ongoing cataloging work in Sinopia and its iterations over time`.
thank you
jesse lambertson lambertson@uchicago.edu
@michelleif commented on Wed Apr 29 2020
@jyssy @sfolsom is this something QA can fix? or is this feedback to be conveyed to owners of id.loc.gov?
@jyssy commented on Wed Apr 29 2020
@sfolsom @michelleif My thoughts, since it is a direct query, it is an ID issue and should be conveyed to the owners of id.loc.gov...but obviously, SF would know better than me, thanks
@sfolsom commented on Wed Apr 29 2020
cc: @elrayle @kefo.
@kefo commented on Wed Apr 29 2020
Oh boy. I'm going to need help with understanding this.
What QA api path is being used? Based on a quick look here - https://lookup.ld4l.org/authority_list - the entries related to LOCNAMES all appear to use the LD4 cache. Said another way: they do not appear to hit ID directly.
Hitting ID's suggest service directly, the results are left anchored: http://id.loc.gov/authorities/names/suggest/?q=Kaufman,%20Peter%20Iv
@elrayle commented on Wed Apr 29 2020
All searching of LCNAF and other LC authorities are done against the cache. There is a way to use QA to directly search id.loc.gov, but I'm pretty sure that Sinopia does not surface that. I'll have to double check.
@elrayle commented on Wed Apr 29 2020
I looked through the configs for Sinopia and it only surfaces access to LCNAF through the cache. There are some small controlled vocabularies that do query id.loc.gov directly. But that does not include name searches.
@jyssy I'm wondering what makes you think that names are being search directly from id.loc.gov. Maybe I am not understanding what you are seeing.
@jyssy commented on Wed Apr 29 2020
@elrayle @kefo Thanks for your examination. we have noted identical results in type of responses that don't seem to reflect a left-anchored search. For instance, when one searches the University of Chicago. Library, results are nothing. The variant name actually returns the correct result. Nobody could foresee that type of result. This is the case with ID and with QA. My first question followed this example with no results based on the heading in the form it is in the file and at the linkeddata service (ID). Also,I thought that was so because when we were having the meeting, someone was looking at those config files while we were in the meeting and told me it looked like a direct query. no stress (maybe there was confusion as to what was cache and what was direct - during the meeting). Not sure. I don't think the issue is one-sided here - but I could be wrong. Do we need to turn all the focus back to QA? @sfolsom Want me to help with something - since it looks like this issue is swinging back around? what do you think? thanks
@sfolsom commented on Mon May 04 2020
@jyssy what template are you using? Using https://sinopia.io/editor/CornellSinatra45:Work, when I search both "University of Chicago. Library" and "Kaufman, Peter Iver" (without quotes) I get the expected results.
@jyssy commented on Mon May 04 2020
Thank you @sfolsom With the name, the results are working it seems now (in Production, UChicago Work [un-nested]
But the corporate body is not:
What do you think?
@jyssy commented on Mon May 04 2020
@sfolsom I get the same results in id.loc.gov (I think it is this similarity in results that maybe confused what we thought is cache and what is direct query.