2019-9-5 Resource Access Meeting Notes
- Andrea Loigman
- Elizabeth Chenette
- Cate Boerema (Deactivated)
Date
Attendees
Discussion Items
| Time | Item | Who | Description | Goals |
|---|---|---|---|---|
| 5 min | Housekeeping | Andrea Loigman |
| |
| 20min | Call numbers | Cate Boerema (Deactivated) | RA views of call number components | Determine requirements for call number: block including prefix, enum, etc only or do we also need separate fields for each. Long term vs. MVP |
| 10min | Performance requirements | Schwill, Carsten | Check-in performance requirements | Determination of performance requirements related to CIRC-430 and UICHKIN-112 |
| 25min | Claim returned | In-app report for claimed return | Determine requirements for claim returned in-app report: fields, location. |
Meeting Outcomes
Functional Area | Product Owner | Planned Release (if known) | Decision Reached | Comments |
|---|---|---|---|---|
| Misc (Call Number) | Q4 | Reviewed elements of the call number notes here: https://docs.google.com/document/d/1FMl-_oNR6k-wVDQrZeMT_V9-ZDDaZBzdiipx0OQii9E/edit#
| ||
Notes
Carsten Schwill: Performance requirements related to CIRC-430 and UICHKIN-112
https://folio-org.atlassian.net/browse/CIRC-430
https://folio-org.atlassian.net/browse/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
https://docs.google.com/document/d/1FMl-_oNR6k-wVDQrZeMT_V9-ZDDaZBzdiipx0OQii9E/edit#
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
Fee/fine
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