Versions Compared

Key

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

...

https://zoom.us/j/337279319 (pw: folio-lsp)

Attendees


David Bottorff 

Ian Ibbotson (Use this one) 

Andy Horbal 

Sebastian Hammer 

Laszlo Jakusovszky 

Elizabeth Chenette 

Mark Canney 

Peter Murray 

Andrea Loigman 

Jana Freytag 

Discussion Items

TimeItemWhoDescriptionGoals/Info/notes
2minAdministrivia

Note taker:  Jana Freytag 



Continue to gather requirements and discussion







Meeting Notes


ScopeNew Notes:

  • DB: Initial scope vs Ultimate Scope - Ultimate scope is full CDL/ILL but initially scope is internal.
  • AL : Stages - start with CDL from our own offsite collections for our own people
    • Then grow out into consortial ILL
  • SS: Very much internal - Stanford Collections, internally - maybe eventually more broadly
  • DB: Do / Don't we need to draw a distinction between ILL and internal
    • Chicago - CDL for course reserves
    • AH: Cornell - What CDL is may depend upon what is delivered
    • Knowing what we are building towards may help institutions plan / decide
  • AL: Draw a distinction between whole collections being sequestered vis item-by-item level 
  • DB: We should not draw the internal scope too narrowly to begin with
  • Some current practice using GoogleDrive links to canvas in course-ware
    • Sequester items for the duration of the course - check items out to proxy account
    • Successful 2-3k items on course reserve loan using this approach
  • DB affirmed the need for this to be generalized - because different institutions will want to have radically different policies - E.G. Paging/Holds on items.
    • Initial scope - not a delivery platform inside folio
    • DB Question: Will this include a delivery platform
  • SS: Question - what mechanism is being used to make items unavailable currently
    • DB - pseudo patron
  • SS: requirement - currently using ILS for charging to the user
    • DB - rather see FOLIO develop something that can handle a better fidelity model of the distinction between sequestering the physical and loaning the digital.
  • A question around the separation between physical and electronic items
    • SS the challenge is that - absolute tie-in between A-physical-item and A-electronic-item - and have 1 item with a mode-of-access property.
    • SH : Aspects of own-to-loan ratios 
      • DB +1 own to loan ratio is key
        • Know that the physical item is sequestered
        • know that the physical item is loaned
    • AL : Asked SS about Stanford Differentiating between physical and digital loans
      • And noted that this is important
      • AL : Usage - do we need more physical or more electronic copies - we need to know when a different mode of access is used.
    • Check out to pseudo patron - then layer some record-keeping on top of that - Symphony doesn't count the bindery/pseudo patron loan as a use. hold module can tell who held an item.
    • Implementation can be brittle if datasets get out of sync
    • AL: Reporting is key - the ability to do data analytics and later on work out who held what
    • SS: Be better if the ILS better understood that a check-out was digital access and the physical was sequestered.
    • SH: Do we need FOLIO to be able to work in both modes - Separate electronic and physical or unified
    • AL: Duration of digital loans - and how intensive is the usage
    • DB: Do we embed the delivery in FOLIO or use something external
    • AL: It almost has to be external - this will have to work outside FOLIO
    • II: Taxonomy of delivery systems - IIIF/google drive type approaches vs Readium
    • DB: There are pressures
    • AL: Different levels of comfort from different general council
    • DB - Current implementation is fine - no direct pressure
  • AH: It might not be urgent "We need this now" - "We can't implement without this"
  • AH: The point at which CDL starts appearing as lines on RFP
  • SH: Should we "Pitch" CDL at WolfCon to see what interest there is in the community

Interoperability

  • SH: NISO project has identified some large categories of things that we should interoperate with - CIRC, DRM, ILL
  • DB: Lets get someone from MM into this call to talk about the modelling aspect of this
  • SS: Sequester of physical item
    • ItemState PO
  • Action:II Follow up to see if someone from MM can come talk to us
  • AL: Go physically fetch
  • All: This is a good slot for meetings

List of requirements:

Requirements should contain (needs more detail):

  • scope
  • interoperability
  • ILS vs other systems
  • where are the boundaries?
  • Statistics and Reporting should be part of this too

...

Report on this document by Sebastian Hammer : NISO Circ model CDL Control flow

Widget Connector
urlhttps://docs.google.com/document/d/12jhFrdmKusgYTe2lwGKeFPB3O9aVO16xqT8KAGRtR9Y/edit

  • Working group for advising libraries on CDL
  • Feedback of the group:
    • Andrea: Does availability for CDL differentiate between already scanned and eligible to be scanned?
    • Answer SH: It will have to - in terms of what you want to make available - a sensible system will have to differentiate
    • Mark: Comment on what state the model is in
    • Answer SH: bases are covered - Further thoughts on best practices are being made
    • Andrea: is there a likleyhood that it will get picked up
    • Answer SH: highly likley get ISO 1866 and NCIP picked up
    • Ian: Which approach seam to be the best encumbering vs tying the loan to a physical item?
    • Answer SH: no concrete answer
    • Ian: Can NCIP be utilized for
    • Andrea in chat: For course reserves - this issue is limiting access to a subset of user associated with a course. - Very good Point

    • Virtual items could rely on similar data model to bound with or analytic records?

    • Answer: Yes, This could be a difficulty for consortia situations (e.g. shared index) as well

    • Use Case: How would a market place be build around CDL?  vs having the physical object
    • Born digital items vs physical objects

______________________________________________________________________________________________

Further requirements and scope see also last meeting