2019-9-5 Resource Access Meeting Notes



Discussion Items

5 minHousekeepingAndrea Loigman
20minCall numbersCate Boerema (Deactivated)RA views of call number componentsDetermine requirements for call number: block including prefix, enum, etc only or do we also need separate fields for each. Long term vs. MVP
10minPerformance requirementsSchwill, CarstenCheck-in performance requirementsDetermination of performance requirements related to CIRC-430  and UICHKIN-112 
25minClaim returnedIn-app report for claimed returnDetermine requirements for claim returned in-app report: fields, location.

Meeting Outcomes

Functional Area

Product Owner

Planned Release (if known)

Decision Reached


Misc (Call Number)Q4

Reviewed elements of the call number notes here: https://docs.google.com/document/d/1FMl-_oNR6k-wVDQrZeMT_V9-ZDDaZBzdiipx0OQii9E/edit#

  • General guidelines we can use when considering what is needed on the many various RA pages and functions (see above in this doc for list):
    • FOLIO list pages (e.g. Loans and Fee/Fines)
      • A consistent “call number block” which concatenates the various fields would be ideal on FOLIO list and record pages because:
        • Consistency is good
        • Saves real estate
        • Many records will not have anything specified for various components so the real estate would really be wasted
        • Components of this block are:
          • Call number prefix - using existing logic
          • Call number - using existing logic
          • Call number suffix - using existing logic
          • Copy number - using existing logic
          • Volume 
          • Enumeration
          • Chronology
        • The order display and separators, if applicable, still needs to be defined
      • Sorting for list pages has been defined by the call number subgroup and will leverage the machine-sortable call number followed by alphanumeric sorting of other elements (paraphrasing here - need to consult the subgroup’s notes for actual logic)
    • FOLIO record detail pages (e.g. Requests)
      • A consistent “call number block” which concatenates the various fields would be ideal on FOLIO detail records for the same reasons as above 
      • That said, if it saves us time to just display separate fields on the record detail screens (because we already have separate elements, for example), we can do that for MVP.
    • FOLIO CSV Exports (e.g. Requests CSV or Hold shelf clearance report CSV)
      • CSV exports need to have each element as a separate column
      • CSV exports need to have the machine-sortable call number as a separate column
    • LDP Reports
      • Should be the same as CSV exports, but need to confirm with Reporting SIG folks
  • Next steps:
    • Discuss requirements with developers and get their take on what, if any, data should be stored vs calculated on the fly
    • Discuss whether we can develop components that can be reused in multiple places


Carsten Schwill: Performance requirements related to CIRC-430  and UICHKIN-112



Carsten Schwill: Performance requirement – you should be able to scan 3 items per second using a scanner at the desk.

German SIG members and libraries confirmed they need scanning speed of 3 items per second because they use RFID tags and scan multiple items at once.

We use RFID antennas, but the client software puts the barcodes into the LDS client like someone was typing it, so we picture FOLIO client open, RFID scanner will insert numbers in FOLIO client. Needs it to happen quickly – 250 microseconds per item.

It’s not uncommon to have 10 items on the desk. If you had scanning rate of 2 seconds per item, you would wait 20 seconds for the system which is very long.

Cate Boerema: We have just been talking about this. I’m thinking this will be less than 2 seconds from input to finished. Many ATI calls underneath. We have some problems with it now. Items that have requests on them are taking longer than 2 seconds. Wants to double check. Goal from a user perspective was 2 seconds.

David Bottorff: Check in time from when you scan until system process is done takes 2 seconds--would be painfully slow. We need less than a second.

For check in and check out, 2 seconds is too slow.

Carsten: Total = Circ and UI together (current check in time needed equals 3 items per second)

Cate: High priority bug that’s being investigated. Some items may be taking more than 2 seconds now with the bug.

Cate will report back to us on the updates of this.

Cate Boerema: Call number component


A call number subgroup was formed, Cate submitted questions to that group. Trying to figure out what we should display for call number on the various circulation screens. Then we can talk about whether any or all of this info should be stored.

Both on holding and item:

  • Copy number
  • Call number type
  • Call number prefix
  • Call number
  • Call number suffix

Item level only:

  • Enumeration
  • Chronology
  • Volume

What other data elements are missing?

Folio only has Enumeration, Chronology and volume as options for years.

Business logic developed for patron notice tokens as part of CIRC-353:

  • If values defined on holdings record and not on item record, then holdings record values are used.
  • If values defined on item record and not on holdings record, then the item record values are used.
  • If values defined on holdings record and on the item record, then item record values are used.

Seems like patron notices probably has everything we need.

Question is about these others--Request details, Request queue with manual reorder capabilities, Request CSV, Hold shelf clearance report, Loans, Loan details, fee/fine details, Fees/fine history, charge new fee/fine, check in, check out, inventory, acquisitions

Request details just has the call number displaying, not prefix or suffix. It is using the logic.

Has a place for enumeration and copy, nothing for volume

What do we need to see here? Do we need prefix and suffix, what about location? Shelving location is actually here.

Call number is an address. We need the full address here.

We should assume we always need the complete call number.

Single item various call number fields not separated (call number block) could be used.

May get more tricky when you’re looking at multiple items and might be sorting.

Anytime a call number is displaying by itself on a screen, we want to see a call number block with all the elements. YES

The concatenated fields: Prefix, Call Number, suffix, volume, chronology, enumeration: together as one; Show all if they are present.

Concern in the subgroup, situation with a list (if it’s concatenated, it won’t sort?):

Metadata management group wants to see the human readable concatenated call number block, but they want to sort based on machine sortable call number field only, ignoring everything else; followed by alphanumerically based on any suffixes, volume info, etc., always ignoring the call number prefix.

This call number column would be here, and you would see prefix, but sort would be by actual call number order with Machine sortable call number, followed by anything that follows the call number, and ignoring any prefixes.

For export to CSV for reports, all call number fields need to be separate columns.

e.g., Oversized material prefix f, shelved in a different location, in reports, Chicago has to be able to exclude Oversize collection.

Want to be able to divide up printouts by prefix

Export to CSV for reports the Machine Sortable Call number needs to be a separate field as well

On the screen, using machine readable call number to sort, don’t need to see it.

If you are exporting, you need that separate field to manipulate the data and sort it

Machine sortable call number for MVP just talking about a machine sortable call number

Rely on alphanumeric

Are there other needs we are not accounting for?

Is there a strong use case for being able to separate things out by call number prefix on the screen itself? Without exporting?

Most of the time there isn’t a prefix or a suffix. Very large number of mostly blank columns

If we already have screens designed that have a separate column for volume or enumeration. Don’t redesign.

If we don’t have it, then here’s the call number block, and here’s how to display it.

If there are 782 volumes in a set, you need to have the volume, copy, and enumeration data on the screen.

Would you want all of that -- Prefix, suffix, call number--concatenated into one column?

Subgroup suggestion is to concatenate volume, enumeration, and copy at the end of the call number block and allow for alphanumeric sort on that without separate columns.

Call number Data is separate in export.

Export contains more info than the screen displays.

In a block, then when you export to CSV could you split it then? Yes it would be a display concatenation.

Display concatenation versus how it is stored and exported.

This exists in other places where the export contains more info than the screen.

Displaying all info from all the fields that we’ve designated as call number in a block in a multi item list but is exportable as all component parts including the sortable number. CRITICAL

For an individual screen we just need the block to keep from overcrowding the display screens.

MVP displaying all info from call number fields (call number block) concatenated in a single column, and on export making those separate for how people want to sort.

Request screen still needs prefix, suffix, chronology, and volume.

How would this look? Subgroup (call number) meets again next Friday.

Sortable call numbers—thanks to Todd Olsen at Chicago-- David went over the logic with him. Todd then went away and did it and it works.

Should bring this to the reporting SIG for actual reporting rather than only CSV

Have learned a lot about reporting with effective location, which is calculated on the fly. Need to store effective location on the item record.

Pieces of the call number that use logic to decide what to use--holding versus item--will need to be stored on the item record.

Reporting SIG if storing call number block, it still needs to be stored separately (not concatenating), store the effective call number prefix. One thing to store. And store the effective call number proper. Then store the machine sortable call number.  Each element stored separately.

Concerned about leaving data out of an LDP for reporting in particular; effective one would be meaningful. Seeing something different at holding level and item level would be valuable in a reporting environment. Need to know which one is the effective.

Reporting needs to be in this conversation. Schedule this for the Reporting subgroup.

Summarize the requirements and review subgroup suggestions, have developers take a look and then propose what’s stored versus what’s displayed.

Call number block logic would be leveraged across these pages.

If suffix is blank in item, then it uses what’s populated in the holding.

If you want to display nothing, no that’s not important?

Too complicated for MVP? When would you need to do that? All the Metadata mgmt. people said nope.

We could come back later and implement that.

Fee/fine details


Cate to Holly: Please add the other fee/fine that is needed here.

If there are other places where call number is displaying or should be displaying please add it to the document.

Emma Boettcher:  In-app claimed return report

Determine requirements for claim returned in-app report: fields, location.

What is this report used for? Stack search? Other things?

What do you use a list of claimed returned items for? Sent to other locations for stack searching.

Current columns for this report:

  • Borrower
  • Borrower barcode
  • Borrower ID
  • Due date
  • Loan date
  • Loan policy
  • Loan policy id
  • Loan ID
  • Fee/fine
  • Item title
  • Material type
  • Item status—claim returned
  • Barcode
  • Call number (we would like this the same as the other reports we were talking about earlier)
  • Contributors
  • Location (effective location, with other location options added as we go on)
  • Instance ID
  • Holdings ID
  • Item ID

Possibly add: (in priority order)

  • Date of claim returned (need to have)
  • Size, pagination (pulled from bib record MARC 300 subfields) –nice to have
  • Alternate titles, transliterated, original (pulled from the bib record) –nice to have
  • Patron expiration date? – nice to have
  • Patron group? – nice to have
  • Flagging a proxy – nice to have
  • Borrower email address -- nice to have