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

Request authority LCDGT (Library of Congress Demographic Group Terms) be supported #26

Open
AdamSchiff opened this issue Oct 10, 2018 · 9 comments

Comments

@AdamSchiff
Copy link

commented Oct 10, 2018

Please only use this issue template for LD4P2 requests for a new data source to be added to QA. If your requesting changes to how a dataset currently available in QA is treated, please use the indexing bug issue template.

For LD4P2 partners and cohorts:

More information about making a request can be found at https://wiki.duraspace.org/display/LD4P2/Request+a+New+Dataset+For+QA

Please perform each task listed below. (Email sf433 @ cornell dot edu with questions):

Please note, all requests for new data sources in QA will be prioritized by the LD4P2 project. Due to time restrictions there is no guarantee that all requests will be added to QA during the lifetime of the LD4P2 grant; regardless of resources it is still useful to know which datasets the community would find useful in such a lookup service.

@AdamSchiff AdamSchiff changed the title LCDGT (Library of Congress Demographic Group Terms) Request authority for LCDGT (Library of Congress Demographic Group Terms) be supported Oct 10, 2018

@AdamSchiff AdamSchiff changed the title Request authority for LCDGT (Library of Congress Demographic Group Terms) be supported Request authority LCDGT (Library of Congress Demographic Group Terms) be supported Oct 10, 2018

@elrayle elrayle added the in progress label Nov 2, 2018

@CECSpecialistI

This comment has been minimized.

Copy link
Contributor

commented Dec 6, 2018

New tab added to spreadsheet: [https://docs.google.com/spreadsheets/d/1rPvEoP9iYNkxJ0eWC8gXe3ci7e6mhW0da59xkGhadi0/edit#gid=612799256]

@elrayle

This comment has been minimized.

Copy link
Member

commented Dec 7, 2018

Links for Testing in Production

This authority can be used now at the following example links...

SEARCH: https://lookup.ld4l.org/authorities/search/linked_data/locdemographics_ld4l_cache?q=workers&maxRecords=4

FETCH: https://lookup.ld4l.org/authorities/fetch/linked_data/locdemographics_ld4l_cache?uri=http%3A%2F%2Fid%2Eloc%2Egov%2Fauthorities%2FdemographicTerms%2Fdg2015060460

Create Accuracy Tests

REFERENCE: Writing-Tests-for-an-Authority

ADD ACCURACY TESTS TO: locdemographics_ld4l_cache_validation.yml

Add Comment in this Issue

Add a comment to this issue when your tests are done. I will add to production site. Then you will be able to run the tests at...

TEST AT: https://lookup.ld4l.org/check_status?utf8=%E2%9C%93&authority=LOCDEMOGRAPHICS_LD4L_CACHE&validation_type=connections

@elrayle

This comment has been minimized.

Copy link
Member

commented Jan 11, 2019

The provided accuracy tests (PR #46) are in production. The results are not immediately what we want.

image

@eichmann and I are exploring the following changes to the indexing based on the spreadsheet information and some general processing discussions in the larger authorities community.

  • ensure the specified search related fields are being searched
    • prefLabel (highest weighting)
    • broader/prefLabel
    • narrower/prefLabel
    • hasVariant/variantLabel
    • hasEarlierEstablishedForm/variantLabel
    • related/prefLabel
  • weight an exact match of the highest weighted field (e.g. prefLabel) higher than a general match
@elrayle

This comment has been minimized.

Copy link
Member

commented Jan 16, 2019

  • owner - @AdamSchiff
  • data in D.A.V.E
  • configured in QA
    • basic term and search configuration
    • subauthority configuration - pending info from @eichmann about whether there are any subauthorities
  • connection tests
    • basic term and search test
      • written
      • on production server
    • subauthority connection tests
      • written
      • on production server
  • accuracy tests
    • written
    • on production server
    • passing - 3 passing, 4 failing - working on tweaking the indexing approach

@elrayle elrayle added this to Next Step in D.A.V.E in Authority Requests Feb 15, 2019

@eichmann

This comment has been minimized.

Copy link
Member

commented Mar 26, 2019

Blending the spreadsheet configuration with @elrayle 's Jan 16 configuration, we now score prefLabel at 10, altlabel at 2 and broader/narrower at 1 for boost values. Let's see what that does to scoring. We're set up to tweak scores (and add additional search items) pretty much at will now.

@zimeon zimeon added this to In Progress in ld4p2-cornell Mar 29, 2019

@sfolsom

This comment has been minimized.

Copy link
Collaborator

commented Jun 5, 2019

Hi @AdamSchiff, I'm updating the spreadsheet that I believe you worked on to adhere to changes we've made to the spreadsheet structure (https://docs.google.com/spreadsheets/d/1rPvEoP9iYNkxJ0eWC8gXe3ci7e6mhW0da59xkGhadi0/edit#gid=612799256), and I've noticed that it looks like there's an expectation that QA would allow the cataloger to look up and link to madsrdf:Collections like http://id.loc.gov/authorities/demographicTerms/collection_LCDGT_Age. Is that the request? It would seem to make more sense to me to look up and link to the skos:Concepts and note what madsrdf:Collections the concept is a member of in the contextual information QA brings back. If the latter I can make changes to the spreadsheet to reflect this. If the former, can you confirm in what scenario you intend to look up and link to madsrdf:Collections? Are you planning to create demonyms outside of LC and want to still linke them to the id.loc.gov collections? If so, we might want to consider adding more context in QA for the madsrdf:Collections.

@AdamSchiff

This comment has been minimized.

Copy link
Author

commented Jun 5, 2019

Hi @sfolsom, I have checked with our metadata specialists here and they agree with you that it would make more sense to look up and link to the skos:Concepts and note what madsrdf:Collections the concept is a member of in the contextual information QA brings back.

Theo Gerontakos wrote: "I think our entry reflects a poorly-formed understanding of QA lookups and of Sinopia – which is understandable, since we created that spreadsheet tab a long time ago.

After a cataloger enters a demographic term, I believe we just wanted the retrieval to include information about the collection to which a given concept might belong. Steven is correct, it makes more sense to look up the skos:Concept and then display a note about the Collection which the Concept is part of. We wouldn’t want to search the collections for the term entered by a cataloger – that wouldn’t make much sense (catalogers will enter terms like “Infants” and “teenagers” but not “age”) – we only wanted Sinopia to display info as part of the display following a lookup, to help catalogers understand the term for which a URI was retrieved."

@sfolsom

This comment has been minimized.

Copy link
Collaborator

commented Jun 17, 2019

Great! Thanks for the feedback.

@sfolsom

This comment has been minimized.

Copy link
Collaborator

commented Jun 19, 2019

Updated the spreadsheet. For lookups with context for SVDE, please implement related LDPath in DAVE and QA: https://docs.google.com/spreadsheets/d/1rPvEoP9iYNkxJ0eWC8gXe3ci7e6mhW0da59xkGhadi0/edit#gid=612799256

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.