Add Direct Lookups for LC Names about qa_server HOT 9 OPEN

An update!: I was struggling for a while yesterday trying to track down why I couldn't get a new search endpoint working in the linked_data/loc_direct config. I've confirmed that it's not just complete incompetence on my side because I was able to get #374 (homosaurus_direct) configured locally fairly quickly. And after further digging, I found this note in the ld4p/linked_data_authorities documentation: "NOTE: At this writing, Library of Congress does not support a query API of id.loc.gov which returns a serialization of linked data. As such, the direct configuration only supports fetching an individual term. The cache configurations support both term fetch and search query."

I also see that there are still no linked data search serialization formats available listed in LOC's docs: https://id.loc.gov/techcenter/serializations.html (Or at least, the internet says that none of these are linked data formats?)

If it's not a requirement to work with linked data to return results, I believe we can theoretically extend the qa gem's non-linked data endpoint to return more of what we need (uri, id, and label). Current example with no uri: https://qa-server-service.library.cornell.edu/authorities/search/loc/names?q=Cornell,%20Ezra. I think we'll have to tinker with our deploy setup though if we go this route, since it won't just be a config file change - will find out more from Greg on Monday hopefully.

I'll also add though, that search endpoints from LOC seem to only return a very limited subset of metadata about each result. Example using search endpoint: https://id.loc.gov/search/?q=Cornell,%20Ezra&format=atom and using suggest endpoint: https://id.loc.gov/authorities/names/suggest?q=Cornell,%20Ezra. So not sure (yet?) how we'd get the extended set of data as listed in the google spreadsheet linked above, unless we used multiple API calls.

from qa_server.

from qa_server.

Switching gears to direct term retrieval:

There are currently 2 qa endpoints for fetching individual terms directly from loc:

1. Using the non-linked data code from the qa gem: https://lookup.ld4l.org/authorities/show/loc/names/n97066641
   • appears to return the full json from loc, no parsing: https://id.loc.gov/authorities/names/n97066641.json
2. Using the linked data configs: https://lookup.ld4l.org/authorities/show/linked_data/loc_direct/names/n97066641
   • parses the same loc json as above and only returns the qa-supported subset of ld values (id, label, altlabel, sameas, narrower, broader)

Are either of these endpoints useful as is? Benefit of the former: it already has all the possible data we can get back from loc. But if we need these results in a different format (e.g. to match the format returned by the latter ld endpoint), we'll need to override more qa gem code. Benefit of the latter: the results format matches all the other qa linked data results. But if we want to return more fields, we'll need to figure out how to add support for additional predicates than the current 6.

from qa_server.

The QA gem for search seems to be doing a decent/minimal job, e.g. https://lookup-int.ld4l.org/authorities/search/loc/subjects?q=History--

I wonder if we can get the other 4 predicates to show. Even if we can't, I think this is enough for now.

from qa_server.

Follow-up from conversation this morning: do we want separate authorities for each of these loc tickets, or can these all just be subauthorities of the loc authority lookup?

For example, if these are all just subauthorities of the loc authority lookup, the lookup urls would all come in a format that look something like:

For this ticket:

• /authorities/search/loc/names?q=
• /authorities/search/loc/names_PersonalName?q=
• /authorities/search/loc/names_FamilyName?q=
• /authorities/search/loc/names_Geographic?q=
• /authorities/search/loc/names_CorporateName?q=
• /authorities/search/loc/names_ConferenceName?q=

For Ticket #369: /authorities/search/loc/subjects?q=
For Ticket #363: /authorities/search/loc/bookformat?q=
etc.

Alternatively, if we needed to create separate authorities for each ticket, we might have urls that looks like:

• /authorities/search/loc_names?q=
• /authorities/search/loc_names/personalName?q=
• /authorities/search/loc_subjects?q=
• etc.

from qa_server.

Subauthorities is enough, no need to create separate lookups for different types of names. We'll need a separate lookup for each LOC related issue in the project (e.g. #369), but the type filters listed in the issue can be subauthorities.

from qa_server.

That said, I should probably test one in Sinopia before you attempt the others.

from qa_server.

@sfolsom This is ready for you to test on lookup-int! Direct lookup results use the id.loc.gov api (same results as what you'd find here: https://id.loc.gov/search/?q=cs:http://id.loc.gov/authorities/names). Each result has an id, label, and uri parsed from: https://id.loc.gov/search/?q=cs:http://id.loc.gov/authorities/names&format=json

Please let me know if you'd like any changes!

New/extended loc names lookup endpoint examples:

• Names (all): https://lookup-int.ld4l.org/authorities/search/loc/names?q=Cornell,%20Ezra
• Names Geographic: https://lookup-int.ld4l.org/authorities/search/loc/names_Geographic?q=Wallingford,%20Conn
• Names Conference: https://lookup-int.ld4l.org/authorities/search/loc/names_ConferenceName?q=Simp%C3%B3sio%20de%20Hist%C3%B3ria%20Mar%C3%ADtima
• Names Family: https://lookup-int.ld4l.org/authorities/search/loc/names_FamilyName?q=mebane
• Names Organization: https://lookup-int.ld4l.org/authorities/search/loc/names_CorporateName?q=consolidated%20lobster
  • Is "organization" same as "corporate"?
• Names Person: https://lookup-int.ld4l.org/authorities/search/loc/names_PersonalName?q=Cornell,%20Ezra

from qa_server.

These look good! Yes, organization is the same as corporate.

from qa_server.