Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Date: 

Attendees:  Jason, Greg, Lynette, Huda, Steven, Simeon, Tim (from 9:30am)

Regrets: 

Actions from 2020-12-04 Cornell LD4P3 Meeting notes

  • Jason Kovari will continue functional requirements efforts, starting with workflow diagramming
    • Organizing cohort effort around this is on-hold until January; Jason has not yet made progress beyond: https://miro.com/app/board/o9J_lfXUUj8=/ ; will pick up work either before Break or immediately following
    • 2020-12-11 Not ready to discuss yet. Not planning to organize cohort around workflows until January, Stanford is on break after today
  • E. Lynette Rayle to finalize the survey for cataloger user stories for PCC feedback and ranking by working group, check with IRB
    • 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-12-11 results now with 63 respondents
      • Top 5: context, filtering by class, broader and narrower, knowing an entity doesn't exist, edit plus adding URI
      • Discussion in meeting of the "knowing an entity doesn't exist" use case - sense that catalogers understand the problem of not being sure where something has been found or not, they broaden search to get a list and then carefully read through it. Perhaps a key thing here is relevancy
      • Sense is that with 63 responses we have useful information to move ahead with. Will close survey midday today
      • ACTION - Lynette will write this up and present to working group on Monday

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-20 Essentially on-hold with this work until 12-11 Discogs is now in the official schedule for 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-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
      • 2020-12-11
        • Moved information into the index for broader/narrower URIs, as well as wikidata URI.   This helped clean up the code/which pieces were waiting for information, and now the broader/narrower components will show up on the timeline.  If the subject being displayed has no temporal info of its own, the timeline is shifted to focus on one of the broader/narrower subjects. 
        • Calls to the production subject browse (for now) and the LD4P2 subject index that included call number facets allow for display of "works about" with number and a link to the call number browse.
        • The map and timeline have been moved to the same section, with a single panel on the right.  Design discussions around how to perhaps improve that/collapse, etc.
        • Had a quick chat with Tim and Astrid yesterday: Notes, Astrid's design ideas
        • In progress: Learning about how to query eCommons.  Reached out to various D&A folks and have references to review.  Need either simple keyword search or subject field search.  Looking like probably DSpace API
          • eCommons may be co-indexed with DCP for bento box - not sure?
          • eCommons would be nice to add if quick/easy but not worth sinking large amounts of time into at this stage
        • Next steps:
          • Highlighting the map based on which timeline article has been selected
          • Moving over the search results
          • Tim will start looking at Agent/Authors page for dashboard when ESMIS sprint finished
          • Some work to move indexes between VMs, in order to vacate/shutdown LD4P2 machine and have everything on LD4P3 cluster
        • Discussion
          • Steven notes past D&A discussions where there was interest in having access to bento results when one is in the catalog, the tabbed interface that Astrid mocked up is an interesting way to approach this

Linked-Data Authority Support (WP2)

  • Qa Sinopia Collaboration – Support and evolve QA+cache instance for use with QA
    • 2020-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
    • 2020-12-11 Lynette has done work on some QA bugs and on the QA servers, OCLC changed processing of queries which means encoding was necessary. Have updated "check status" option to allow comparison which brings up a side-by-side comparison. Have also added a facility to mark tests as "pending" so that rspec regression tests can flags tests that sopt working or that start working. Have created new project board to highlight issues. Steven will look at this board to help Dave with any extra information
  •  Cache Containerization Plan - Develop a sustainable solution that others can deploy
    • 2020-12-04 : nothing this week11 Ball is in Greg's court. Will release new version before the QA Sinopia meeting next Wednesday. Hope to have containerized DB up and running and push JSON config.
  • Search API Best Practices for Authoritative Data working group 
    • 2020-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.11 See notes above. Next meeting on Monday, will categorize levels of user story today to show path from cataloger stories to provider stories. Technically this will be the last meeting of the WG. Will need to think about what is next in the New Year

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

...

  • OCLC Linked Data / Entities Advisory Group
  • PCC - Sinopia Profiles Working group collaboration
    • 2020-12-04: remove from the agenda. when update, Steven will bring to the group. Now discussion is focused on who will own the work11 Discussion of what group(s) will take this forward
  • PCC Task Group on Non-RDA Entities
    • 2020-11-20 The PCC non-RDA report was finalized and submitted to POCO earlier this week. It will be discussed at a future meeting.
    • 2020-12-04: on PoCo agenda for 1/14; more after that
  • Steven consulted with Kevin Ford on how publication frequency is modeled in BF. This could lead to an added node... classic RDF math, with a layer of abstraction in order to provision for frequencies that change over time and/or need to be qualified with exceptions to the rule. Steven has reached out to LTS folks to see how we query the data in MARC to understand what useful queries would look like (there are 2 places for this data with some variants in our MARC data, not always up-to-date, shows as Frequency field in Blacklight (perhaps from 310 rather than 321, or 008))
    • 2020-12-04: came up on Sinopia QA meeting – around Sinopia design principles (lookups happening using QA) but have entertained within-ontology property and class look-ups. Raises question of whether QA should afford ontology term look-ups. QA allows method of small set of look-ups - trivial to create. Can remove from agenda for next meeting.
  • Default branch name - WAIT until we can use github tools January 2021
    • Samvera community meeting this month.
  • Discogs & 024s. Steven led 024 conversation among music catalogers
    • how do we completely break the connection to Discogs? to ensure that a record in Blacklight with the wrong match to Discogs... and does not have a representation in Discogs...
      • can check whether we have solved this issue for other external sources (e.g.: book covers, etc.). prioritizing 024 above the search... and also look for local field if there is a nodiscogs flag. We can wait to discuss this until the post-implementation assessment
      • issue: dynamic database so a no match today may be a match tomorrow
    • will code look for 024 before doing search? code has not yet been updated...Steven gave update at CMS meeting this week, will follow up with Tracey, Beth and group in order to support flag that says "don't search discogs", else 024, else dynamic search

Upcoming meetings

  • https://kula.journals.publicknowledgeproject.org/index.php/kula/announcement/view/1 .  Call for Proposals - Special Issue: "The Metadata Issue: Metadata as Knowledge".  Due January 31, 2021 (abstract 300-500 words).  Includes "The use of linked open data to facilitate the interaction between metadata and bodies of knowledge" and "Cultural heritage organization (libraries, archives, galleries, and museums) and academic projects that contribute to or leverage open knowledge platforms such as Wikidata"

...