Page History

Date: 04 Dec 2020

Attendees: nearly all

Regrets:

Actions from 2020-11-20 Cornell LD4P3 Meeting notes

Jason Kovari will kick off work on functional requirements
- Jason working on pictures of edit workflows to parallel Stanford work, not much new this week
- At the all-hands on Tuesday there was discussion of setting up a Miro board to capture workflows from participating institutions
- Jason has not accomplished anything. will try to be better next week
E. Lynette Rayle to finalize the survey for cataloger user stories for PCC feedback and ranking by working group, check with IRB
- 2020-11-20 - Survey finalized. Slow response from IRB - got an ack but no detail yet, did training and think that IRB won't apply in this case because the purpose of the survey is merely process improvement
Tim Worrall will sort out code in LD4P3 repo and look at adding button to highlight Discogs field
- 2020-12-04 - Distributed with 19 participants in less than 24 hours. Will send another reminder today. Closing mid next week if there are weak responses. DONE
  - Top three: seeing contextual info, filter by class-type, see broader/narrower
  - Bottom three: updating local data if changed in original source; which field triggered a keyword match; if cannot find in local look-up don't want to go to original source and search there (need to dive further into these)
- 2020-10-30 Tim is been working on this. Worked to improve speed by moving code from JavaScript to Rail but that had significant slowdown (~1s). Now doing search in the controller and then doing second call in JavaScript. Image comes back with first call. Thinking about timeout to avoid problems if Discogs response is slow
- 2020-11-20 Tim did demo of the highlight feature to user reps last week. Decision to highlight both the data and label for Discogs fields which Tim has now address. Yesterday Tim pushed code to LD4P3 repo so ready to go. Expect to be able to move to production in January sprint

Agenda

Discovery (WP3)

https://github.com/LD4P/discovery/projects/2 for issues etc.
Draft of a discovery plan: https://docs.google.com/document/d/1zKYW7FQVVNvyd0XjjW0qWznX9PC3jbmOE6Kz_yygPjs/edit?usp=sharing
Strand 1: production piece
- Steps:
  - Discussion with Tracey re. use case and benefit – DONE
  - LTS engagement re. metadata - DONE
  - Production requirements and functionality – Production decision points
  - Demo and discussion with D&A User Reps and dev team – DONE
  - Implementation work
    - 2020-11-06 Didn't manage to get demo for User Reps on Nov 5 due to other pressures. Still making some tweaks to the layout and highlighting
    - Question of using QA vs going directly - will use Discogs directly for now to avoid adding QA
    - Will do demo next Friday for User Reps
    - 2020-11-20 Tracey has provided examples of bib records with 024 $2 discogs for Frances and Tim to test out their code. Tim asked a great question about how much data we can expect in the bib from Discogs if the Discogs id is in the bib. This has prompted me to reach out to Tracey to establish local a policy for deciding what data is essential to include in the MARC record in order for it to be able to stand alone, and what can catalogers get away with not copying and pasting (and let Discogs feature pull in automatically). – Frances updated index to include this as `discogs_display` field, Tim will check this field for the id which will then go straight to discogs call, very simple change2020-11-20 Essentially on-hold with this work until January D&A sprint though not much time before then anyway
Strand 2: research: how to go from knowledge graph to an index
- Research decision points
- Use cases - first review 2020-09-18
  - First goal: DASH! dashboard (full page for entity) that extends on the idea of an embedded knowledge panel, aim to have functional prototype for end of year
- DASH! (Displaying Authorities Seamlessly Here)
  - Dashboard design meeting kickoff notes - will also try to understand what our data will support or connections to other data sources
  - https://docs.google.com/document/d/1PgQi3xobsPhr9DUHU_YGeimL1OjNiiTdkiNWb36r3Gg/edit
  - 2020-11-13
    - https://jamboard.google.com/d/1VHkygzzY-NWpwWEpZ9PqFjrnfPMADfTgjh8gFRi2MoE/viewer?f=5
  - 2020-11-20
    - Huda working on prototype, think that we can test as a team the first week of December (though SWIB next week)
    - Huda will work on IRB paperwork for user testing even though we think we will be exempt again
    - Tim will have time after the ESMIS sprint, work with Huda but focus on person entities
  - 2020-12-04
    - Period-O info and with subject heading components/subfields - some of which have URIs and some are cannot be mapped. For temporal subfields that are not years (e.g.: 20th century), will/may hard code. Some subject subheadings that are Geographic do not have URIs; for a subject without temporal information but with narrower terms with temporal information, working to put those on the timeline
    - Can solve the multiple AJAX requests by building an index that mitigates the extent of calls; worry that may become super-large index but not a concern at the moment. wants to put as much work on client side but slow that way... plus there could be useful information to search. leaning toward more index-heavy for information we require
    - Next step: decide how much more should go into index; moving around information on page to raise catalog results and also allowing for a "see more" button

Linked-Data Authority Support (WP2)

Qa Sinopia Collaboration – Support and evolve QA+cache instance for use with QA
- 2020-11-20 Lynette will check in with Dave about getting the new indexing scheme out in production. Still a few outliers in the accuracy tests to check on with Dave and Steven. Stanford team aren't working on Sinopia right now 12-04 Working on creating issues for all remaining work on new indexing approach. Started in Uber issue (Issue #383). Addressed 2 issues in QA
- 2020-12-04 Dave's indexing accuracy for tests: Dave thinks it is better across the board; Lynette building comparison into UI, currently manual process. Some conversations around this are happening in Slack – moving that documentation into Issues to allow for post-fact review. Performance is consistently better – issues is ensuring that accuracy is consistently better... and assessing why if not. Analysis up to this point was primarily for LoC... now doing analysis for all authorities. Users tend to ask more of QA than they ask of other tools that already exist (e.g.: when search id.loc or OCLC, there is a lot of paging.. but in user requests for QA, expectation is that desired result is within first few). OCLC also has weight that accounts for frequency of use
Cache Containerization Plan - Develop a sustainable solution that others can deploy
- 2020-11-20 Lynette will pick this up again next week, Greg also in12-04 : nothing this week
Search API Best Practices for Authoritative Data working group
- 2020-11-20 Lynette working on user stories - grouping by different levels and working out how they tie to cataloger stories (as opposed to developer)12-04 Met this week; had one provider user story that took the whole time: "I want to provide human readable primary label"; some do not have preflabel and do not want to assign one – and this is challenging since the label is all tied up into language. could spin another working group on language... as language complicates many of the user stories (e.g.: do you tag language, do you provide based on browser settings for users, how do you query for particular languages, etc.). One solution seen: instead of semantically defining a preflabel, will have all labels treated equally using rdfs:label but use schema:label for preferred (i.e.: a distinct property that can be queried but does not specify preference). Want to aim to a solution that is language agnostic/symmetric ... have to work for situation where we do not know preference of users. Working group is nearing end of charter. Looking at user study as public facing document and then look to recharter for other work not yet done.

Developing Cornell's functional requirements in order to move toward linked data

C.f. Stanford functional requirements document: https://docs.google.com/document/d/18H6zYGwKuCg3SZqm9Q_cxkZThcdmBjknE6HdtQ-RRzk/edit#heading=h.4fu64x8jzm6e
What does success look like? And then how do we get there?
2020-12-04: discuss next week

Page tree

Versions Compared

Old Version 2

New Version 3

Key

Actions from 2020-11-20 Cornell LD4P3 Meeting notes

Agenda

Discovery (WP3)

Linked-Data Authority Support (WP2)

Developing Cornell's functional requirements in order to move toward linked data

Other Topics

Upcoming meetings

Upcoming meetings

Next Meeting(s), anyone out?: