Date: 

Attendees: Greg, Huda, Jason, Lynette, Simeon, Steven, Tim

Regrets: 

Action from 2020-07-10 Cornell LD4P3 Meeting notes

Agenda

  • LD4 Conference highlights (in addition to those noted last week)
    • Lots of work in the Slack channels, which has worked well. Zoom chat and Slack channels have been good
    • Talks from Nigeria and other countries that tend to be harder for participation in-person has been good
    • We talk about BF a lot – but others talk about LRM and other ontologies.
    • Interesting to see what people are doing
    • Discovery track is all next week, starting at 1pm
    • Jason gave a FOLIO EM-WG talk pre-recorded last week
    • People are in different places in the journey of implementation; funding, training, etc.
    • Steven's workshop: lots of people understood RDF but not linked data until this workshop.
    • Hilary and Christine and Michelle sent report to PIs with stats on attendance - 1300 or so registrants. 
  • LD4P2 wrap up
    • Discovery: Much documentation completed.  Still to do: Indexing Processes (started/in progress).  Committing to doing demo intro/closing today to be done with it (Using wham! autosuggest video Tim sent earlier).
      • slides linked above include use cases, questions we wanted to address and info on indexing. Huda Khanwill be adding more. Demo video has some walk thru of indexing. 
      • intro and closing for technical demo will be done today (Huda commits to this)
  • LD4P3 planning questions (kickoff)(proposal)
    • WP2 - A key element of this work package is a sustainable solution that others can deploy. Questions of budget for deployment. Need to get all code into LD4P repository. What would a good end-product look like both for our maintenance and for others to use
      • ACTION - Lynette/Greg to work on documentation of issues and ideas
        • DONE - Initial pass on the document at... Cache Containerization Plan
          • First step is documenting existing process
          • Second step: proof of concept with small authority, which will get us thru process of determining which containers will be used from Docker hub. May need some configuration to operate as we need. Will give opportunity to create containers we need for our web app. 
            • Long conversation with folks at Stanford re: their experience with containerization. Containers are usually kept really small. we would need to determine where files that represent index exist... and then they take standard Lucene container and copy over the QA-specific files. Open questions around what kind of orchestration will be used (Greg has started identifying). Downside: Stanford was adamant that doing containerization is really hard.
          • Third: explore potential for moving logic in code to other configurations to avoid branching in the code
          • Fourth: apply containerization process to several authorities known to be slightly different.
          • Fifth: create for all authorities
          • Last: sustainability plan (incl. where will all authorities live; can we spread across multiple institutions; can we move to architecture with fall-over)
      • Comment/Questions
        • Was dave involved in discussion? doc sent to Dave and was discussed off-line earlier and he was on-board then. Good start to how to work thru this.
        • Justin and Jeremy have offered to be resources re: containerization. Once Lynette gets feedback from Dave, she'll be sending the plan to Jeremy & Justin
        • Dave was in process of reindexing LOC... 8 days in, the building's network went down so this is likely 2 weeks away from bring in production at this point
      • ACTION - Simeon to organize meeting of Lynette/Greg/Steven/Dave/Simeon
        • NOT DONE YET – Should now be focused on the draft document
    • WP3 - Which parts of LD4P2 should we take forward? What is a good candidate for production? Are there new areas of user research?
      • ACTION - Huda to create google doc for brainstorming ideas, reflections on past work and process (Not sure if we need a separate document from the meeting notes below but will create if need be later.  Did create a set of slides recapping the past and breaking down LD4P3 grant discovery section) – DONE (sort-of / well-enough)
      • ACTION - Huda to set up discussion with Tim and Greg. DONE (Met with both to discuss logistics, servers, code deployment.  Final workflows/details will depend on what we plan to do but good to know what Greg has already set up and how it works)
      • ACTION - Huda to set up meeting with Tim/Steven/Jason and maybe Astrid or others interested from Stanford
        • Meeting notes.  Met with DOG crew the sequel, and Jessie separately. 
          • Strands: (1) Focusing on taking LD4P2 work close to production all the way to production-ready. (2) Work that requires more user research/design/prototyping:
            • Browsing exploration (building off renewed interest in virtual browse, browse in the time of COVID)
            • Dashboard (an entity focus in Blacklight); Wisc. brought this idea up in Disc Affinity Group meeting about indexing. Jesse also interested in this from an indexing POV.
          • Contributing back to Blacklight community: From conversation with Jessie, considering where the "seams" of the work are.  Ways to think about institution-specific work which also explores which aspects can be included in the core Blacklight code. 
          • Questions: prioritization (as noted below). Still need to consider actual development work/COVID effects on priorities.
          • Huda: Talked about how the grant isn't requiring or focusing on creating a discovery layer on top of BIBFRAME/Sinopia (don't wish to redo Blacklight to run off linked data instead of MARC), but wondering if that data can be used as another linked data source (i.e. integrated/used to get data for display or indexing based on use case) which does not require rewriting how Blacklight operates. (Steven may have alluded to this in the call number browse discussion: being able to bring in related items). 
      • ACTION: look at Blacklight and Cornell meeting notes to better understand what people liked... and what is near-to production.
      • Question of whether we favor production over all else, ability to contribute back to Blacklight and competition between generic vs. specific to Cornell needs
        • Difference in process/workflow between the two.
        • Jesse pointed out that when Stanford does work, they often think about ways that the core code can be updated to do what you want in the local environment.. so one may be able to merge the two efforts
        • From Simeon's POV: don't need to decide at this point. 2 year grant and we need to develop efforts that can be deployed and we want to work closely with Blacklight. Key goal is to develop production-ready services regardless of whether we contribute back. We neither control what is put into production at Cornell nor can we control what is put into the Blacklight core code. We should demonstrate what is useful
        • Would be quicker to go to Cornell production and could be more of a demonstration for a final report than a generic gem that may or may not be accepted by the Blacklight community 
        • There would be a lot of coding changes for a generic blacklight instance for something like Discogs
        • If there is any chance of an LD4P4, that would depend on what we've done in the first year. Final report is less important to future than the interim/first-year report
        • Our library is more receptive to improved electronic access than it has ever before been. If we can show something that provides improved online experience, we might have better reception than even the last time, which was positive
        • As we work thru our local implementation, we should be noting how to generalize for a future gem
        • Huda and Astrid continue to collaborate on the UX side
  • What are 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
    • Jason Kovari : will start organizing thoughts around this and will speak more next week
    • PCC just made a call around wikidata pilot projects where institution defines project but has some support from PCC... with expectation around bringing learning outcomes back to that group
    • Simeon would like to be involved as possible but his schedule should not be a blocker for the meetings
    • Huda might lurk
    • Vision for the future will be a around FOLIO so we may wish to engage CUL-IT staff involved with FOLIO at some stage
  • Misc. Topics
    • PCC Profiles Group
      • Steven Folsom  agreed to be on group... and charge is thru September. Reaching out to Nancy and Paloma to see if they wanted to propose to SWIB
    • OCLC Linked Data / Entities Advisory Group
      • might play into the LTS conversation; are we concerned with vandalism in more open systems so want to go to more closed wikibase systems (e.g.)? Sense is that this is using Wikibase to make a model for libraries
      • Two requests in API: 1. get me entity (returns a few fields) 2. get me JSON-LD for this entity. Trying to create service where someone can ask for an entity. Believe that get API will be expanded to include more API calls
      • Huda signed up for testing
      • How are we collaborating with them? Purely thru QA?
      • Would be good to be able search on entity backbone
      • OCLC is participating in the API Best Practices Working Group
      • Way they seed the database is using different vocabs. they are starting from entities that have references to other source data (e.g.: entity1 in Source1 has URI to entityA in SourceA)
      • Alignment across entity sources did not come up explicitly in the survey
  • SWIB 2020 - Deadline extended to July 27 
    • Huda has abstract in (that Simeon commented); discussion last week around a QA topic. Lynette plans to put something together
    • See PCC Profiles Group above


Next Meeting(s), anyone out?: All here next week

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.