Inventory
(UXPROD-785)
|
|
| Status: | Closed |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | R1 2021 | Parent: | Inventory |
| Type: | New Feature | Priority: | P2 |
| Reporter: | Holly Mistlebauer | Assignee: | Charlotte Whitt |
| Resolution: | Done | Votes: | 0 |
| Labels: | Showstopper-Cornell, call_number, cap-mvp, inventory, mandatory, po-mvp, q4-2019-at-risk, round_iii | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issue links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Epic Link: | Inventory | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Front End Estimate: | Large < 10 days | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Front End Estimator: | Holly Mistlebauer | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Front-End Confidence factor: | Low | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Back End Estimate: | XL < 15 days | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Back End Estimator: | Holly Mistlebauer | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Estimation Notes and Assumptions: | Best guess given we haven't defined this yet! | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Development Team: | Prokopovych | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| PO Rank: | 98 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Chalmers (Impl Aut 2019): | R5 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Chicago (MVP Sum 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Cornell (Full Sum 2021): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Duke (Full Sum 2021): | R2 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: 5Colleges (Full Jul 2021): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: FLO (MVP Sum 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: GBV (MVP Sum 2020): | R4 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Grand Valley (Full Sum 2021): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Lehigh (MVP Summer 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: MI State-Lib of MI (Sum 2021): | R2 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: MO State (MVP June 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: St. Michael's College (Sum 2021): | R2 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
Raw LC call number data does not sort well. The purpose of this feature is to generate and store a machine-sortable call number for the purposes of sorting lists such as Loans and Fees/fines. The machine sortable call number will also be available for inclusion in reports (both in-FOLIO and external to FOLIO). The scope of this feature is implementing Library of Congress parsing to all FOLIO call numbers. Call number display and sort in the FOLIO UI is out of scope. Separate feature(s) will also be written as needed to cover type-based parsing (e.g. Dewey parsing for Dewey call numbers etc). Per discussion with the Call number sub-group, the machine sortable call number will be based on the <Effective call number> data element on the item record. We will leverage Tod Olsen's SolrMarc code for generating the machine sortable call number. Call number searching, both with and without punctuation & spacing, is addressed in a separate feature
--------------------------------------- Call Number Sub-group membership:
CB: I drafted a document which covers how call number is working today which may be a good starting point for discussion: https://docs.google.com/document/d/1FMl-_oNR6k-wVDQrZeMT_V9-ZDDaZBzdiipx0OQii9E/edit NOTE (for those who may be looking) Agreed upon format for Call number string = <EffectiveCallNumberPrefix> <EffectiveCallNumber> <EffectiveCallNumberSuffix> <Volume> <Enumeration> <Chronology> <EffectiveCopy> <ItemCopy> (ideally we'd have <EffectiveCopy>, but that hasn't been implemented yet (see
|
| Comments |
| Comment by Charlotte Whitt [ 14/Aug/19 ] |
|
Hi lew235 and Holly Mistlebauer - I have added following features and linked them as blocked on this new Call number umbrella feature:
|
| Comment by Cate Boerema (Inactive) [ 22/Aug/19 ] |
|
This is important, but it was created too late to be delivered in Q3. I am removing that fix version. |
| Comment by David Bottorff [ 22/Aug/19 ] |
|
Cate, the summary document is helpful, especially as I'm joining this conversation somewhat belatedly. I have one question about other item level information, such as enumeration/volume. Is that being handled separately everywhere, presumably? Most screens would need this displayed next to the call number, so should we assume that is already being handled? |
| Comment by Cate Boerema (Inactive) [ 22/Aug/19 ] |
|
Hi David Bottorff. Enumeration, chronology and volume are only present on the item record. I added that to the document along with screenshots of the relevant sections of the two records. I don't think we should consider it already handled. Let's include them in the discussion. I am curious if there was a plan at one point to combine enumeration and volume. The reason I ask is that Tania actually had volume removed from the requests app as part of
|
| Comment by lew235 [ 22/Aug/19 ] |
|
David Bottorff my e-mail message to you bounced – did you get an invitation to our meeting at noon today? |
| Comment by David Bottorff [ 22/Aug/19 ] |
|
I did not. My email is dbottorff@uchicago.edu. Is that noon ET or CT? |
| Comment by David Bottorff [ 22/Aug/19 ] |
|
I can make either. |
| Comment by lew235 [ 22/Aug/19 ] |
|
Just sent you an e-mail David Bottorff |
| Comment by Christie Thomas [ 22/Aug/19 ] |
|
David, I just added you to the slack channel. Regarding the inclusion of enumeration and chronology - I have noticed that there are references to call number that are assuming that whatever is on the spine label will display; the spine label frequently includes the prefix/suffix, enumeration, chronology, copy number, and (at least at Chicago) the shelving location. It would be nice to differentiate when a call number is required for display and when the call number + other data is required for display. |
| Comment by Holly Mistlebauer [ 11/Oct/19 ] |
|
lew235: Has a decision been made? I am asking because my team needs to work on
|
| Comment by lew235 [ 11/Oct/19 ] |
|
Holly Mistlebauer A decision has been made about the "call number block" display, which comprises The only thing I'm not completely certain about in that is the placement of <volume> – I will find that out today if possible. |
| Comment by Holly Mistlebauer [ 14/Oct/19 ] |
|
lew235: Great! Then I can write up the user story for my team to work on. I'm assuming if any of the data doesn't exist you just skip it and include what does. Thanks! |
| Comment by Holly Mistlebauer [ 14/Oct/19 ] |
|
lew235: I can see where to get Call number prefix, Call number, Call number suffix, Copy number and Enumeration from, but where do I find volume and chronology? |
| Comment by lew235 [ 14/Oct/19 ] |
|
Holly Mistlebauer Enumeration, Chronology, and Volume are all part of the Enumeration data accordion in the item record. |
| Comment by Holly Mistlebauer [ 14/Oct/19 ] |
|
lew235: So I guess if it doesn't show up it just doesn't exist. Thanks! |
| Comment by lew235 [ 14/Oct/19 ] |
|
Yes, if there is no data nothing will display. Otherwise we'd end up with odd-looking call number displays! |
| Comment by Holly Mistlebauer [ 14/Oct/19 ] |
|
lew235: What I meant was that the sample record I was using had Enumeration in the Enumeration section but did not have Volume and Chronology listed at all...I thought maybe it was because they were blank... |
| Comment by Holly Mistlebauer [ 14/Oct/19 ] |
|
lew235: One last question, I hope. What is the formatting of the call number field. Is there a space between each part? |
| Comment by lew235 [ 14/Oct/19 ] |
|
Holly Mistlebauer Yes, all elements are separated by spaces. And in your example I think it is the case that Chronology and Volume are not displaying because they are empty. |
| Comment by Holly Mistlebauer [ 14/Oct/19 ] |
|
lew235: Thanks so much! Please let me know as soon as you have confirmed the placement of VOLUME. Thanks much! |
| Comment by lew235 [ 14/Oct/19 ] |
|
I'm making an executive decision, as no one has spoken up, that the order in the call number block should be the as it appears in the Enumeration data accordion: |
| Comment by Holly Mistlebauer [ 15/Oct/19 ] |
|
lew235: Thanks for finalizing this for us! Really appreciate your efforts! |
| Comment by Charlotte Whitt [ 12/Dec/19 ] |
|
Hi lew235 - this feature did not have any fix version. I added Q1 2020. Please correct this if you think it should be differently |
| Comment by Cate Boerema (Inactive) [ 17/Dec/19 ] |
|
lew235 and Charlotte Whitt I am moving this from Analysis complete back to Draft, as there are still open questions as to whether we can start with LoC parsing only or if we need type-based sorting. Type-based sorting definitely expands the scope of this feature. In the call number Slack channel, I proposed that we start with enabling the LoC parser only for MVP and introduce Dewey (and other call number type) parsing afterwards. So far no one has objected on the Slack channel, but I haven't had the chance to review the MM meeting recordings on this topic. What do you think? Can we proceed with LoC and expand later? If so, I think we should restructure this features so it is just about implementing LoC parser and then creating a new UXPROD feature for enabling call number type based parsing. Folks could just rank the new feature to let us know how critical it is for them. |
| Comment by lew235 [ 17/Dec/19 ] |
|
Cate Boerema I think we can proceed with LoC first. MM discussed this more last week (I was absent but I watched the recording) and while the Dewey numbers sort incorrectly it sounds like the libraries most affected by this already have workarounds in place. I think splitting these features so we can rank the additional work separately is a good plan. That way, if there are implementing libraries who need something more than LoC to start with, they can make that need known explicitly. |
| Comment by Charlotte Whitt [ 23/Mar/20 ] |
|
lew235 and Charlotte Whitt are reviewing: Cate Boerema [11:41 AM] on March 11, 2020: 2. DRAFT: Implement Type-Based Parsing for Call Number Sorting by Dewey and LC - This was seen as lower priority than the above feature. I drafted this a few months ago and asked you and Laura to review it and take it out of draft so it could be ranked. It looks like you haven't had the chance to do that yet. But due to the Coronavirus - we have not been able to meet about this/follow up yet. |
| Comment by David Bottorff [ 23/Mar/20 ] |
|
Among other things, I would argue that having the normalized call number string in place is necessary for LDP and various in-app reporting and integration features to work. For example, the in-app report of exporting a list of page requests that need to be pulled is useless if the list can not be properly sorted by call number. Machine sortable call number logic is vital to any number of similar functions. |
| Comment by lew235 [ 22/Jun/20 ] |
|
Sample call numbers, with sort order indicated are here: |
| Comment by Sharon Beltaine [ 20/Oct/20 ] |
|
Cornell Reporting: Also, sometimes we need to identify titles in a given call number range in order to reclassify them. Accreditation reports for Annual Statistics reports include data on materials that have been reclassified by call number range. Critical collection management decisions require the ability to inventory the collection and compile metrics associated with missing items, replacements, tattle-taping and effort expended to maintain the collection. Using normalized call numbers is required to obtain this information. |
| Comment by Holly Mistlebauer [ 17/Dec/20 ] |
|
lew235 and Charlotte Whitt: Hi! This feature was very hot at one point, then seemed to disappear. What is the latest on this? I have taken over Cate's Lead PO role on the Core: Functional team so I am trying to get up to speed on the features assigned to the team. Thanks, Holly |
| Comment by Charlotte Whitt [ 17/Dec/20 ] |
|
Hi Holly Mistlebauer - here the latest Slack chat on this (10/9/2020): Charlotte Whitt:lemon: 4:29 PM Cate Boerema 6:08 PM Laura Daniels (Wright):pride: 6:12 PM |
| Comment by Holly Mistlebauer [ 18/Dec/20 ] |
|
Charlotte Whitt and lew235: So it sounds like everyone agrees that it would be good to get this done, but we no longer have a PO for this with Cate gone. Are all of the user stories done? (The status is 'Analysis Complete', but I just want to make sure.) If the stories are done I'm fine taking them to the Core Functional Team to be pointed. We need to get some estimates so we know what we are dealing with. |
| Comment by Holly Mistlebauer [ 18/Dec/20 ] |
|
Just to be clear, I need a confirmation that the stories are done, then I will take them to the Core Functional Team to be pointed. We have two extra sprints in Iris now, so depending on how much work is involved we may be able to fit this in. I don't want to promise anything until the stories are pointed. |
| Comment by Charlotte Whitt [ 21/Dec/20 ] |
|
Hi lew235 - would you have time this week to go over the stories, together with me and Holly Mistlebauer - just for us to be 100% sure that all spec work is done, and the stories are dev ready. |
| Comment by lew235 [ 04/Jan/21 ] |
|
Charlotte Whitt I'm sorry, just now seeing this. I can make time this week. |
| Comment by Charlotte Whitt [ 04/Jan/21 ] |
|
lew235, no worries. When would work for you? E.g. Wednesday 1/6/2021 at noon EST? |
| Comment by Charlotte Whitt [ 12/Jan/21 ] |
|
Hi Holly Mistlebauer - I have added the R1 2021 release tag to this feature; while Cornell and other libraries are asking when to expect to have this work done. |
| Comment by Holly Mistlebauer [ 13/Jan/21 ] |
|
Charlotte Whitt: Thanks...I just moved added the user stories to Sprint 106... |
| Comment by Holly Mistlebauer [ 17/Feb/21 ] |
|
UPDATE: This feature was not originally planned to be part of the Iris release, but was added when the Iris development cycle was extended by 2 months. I just learned today that the back-end dev working on
|
| Comment by Tod Olson [ 17/Feb/21 ] |
|
For Chicago, it would increase our workaround burden in the short term. We would need to figure out some good-enough temporary solutions for operational needs, it affects real daily work like generating lists for pulling materials from the bookstacks. So we would need to come up with some workarounds for a couple months. We would definitely feel pressure to fast-track moving to Juniper. |
| Comment by Joanne Leary [ 18/Feb/21 ] |
|
I agree with Tod. In terms of circulation, operations that depend on paging items from the stacks (to fulfill requests, for course reserve and document delivery scanning, for curbside checkout) would be immediately impacted. My reporting work would likewise be heavily affected. Nearly every report I do is put into call number order. Right now I am creating lists of candidate volumes to be transferred to our Annex Library, and the project has to operate on a fairly strict time schedule; this would be slowed down significantly if call numbers could not be sorted correctly. I'm not sure how this affects tech services operations, but my guess is that it would make workflows more difficult. |
| Comment by Sharon Beltaine [ 18/Feb/21 ] |
|
Cornell Reporting: |
| Comment by Holly Mistlebauer [ 18/Feb/21 ] |
|
Hi all! Thanks for the input. I want to list specific issues this will cause. I have summarized the case for this feature below. Please let me know what else should be added or if I have made any errors. Thanks.
|
| Comment by Holly Mistlebauer [ 18/Feb/21 ] |
|
Also... What is the workaround? I need to explain why it is cumbersome.
Thanks! |
| Comment by Holly Mistlebauer [ 18/Feb/21 ] |
|
Joanne Leary , Tod Olson , Sharon Beltaine : To prepare myself for the questions I will get, I need to ask you some more questions.
|
| Comment by Holly Mistlebauer [ 18/Feb/21 ] |
|
UPDATE: EPAM has confirmed that the dev working on
|
| Comment by Holly Mistlebauer [ 19/Feb/21 ] |
|
Background: This feature wasn't identified in the Capacity Plan as being part of the Iris release, but when the release date was extended I was able to add it. This feature was chosen to be added to Iris because Cornell labelled it as a 'showstopper', and we are all trying to complete everything that is a 'showstopper' for a July implementer. I knew it would be very tight, but I didn't know that 1.0 BE FTE would be out the last week of the sprint. This leaves us with only 1.5 BE FTE for next week. Also, our available 2.5 BE FTEs were all new in December. The Capacity Planning Team, PC Exec and OLE Board are all aware of our situation, and are working to get more BE devs, but in the meantime we are doing the best we can with what we have.
|
| Comment by David Bottorff [ 19/Feb/21 ] |
|
Holly, I think there might be one mistake in your descriptions, in that I think the display call number that already exists WILL match the call number on the label (as long as they are the effective call number string), but won't appear in the ORDER that the books are physically shelved. For Chicago, at least, this is definitely an issue of scale/volume of work, both in terms of the number of paging requests we process daily as well as the volume of material being transferred, shifted, etc. on an ongoing basis. Tod Olson could certainly explain our possible workaround better than I could. Manually sorting the lists would be onerous to the point of implausibility. We would likely have to build some kind of process (such as an SQL query) that would create local machine sortable versions of call numbers. This might involve relying entirely on LDP (which has data-freshness issues) or exporting lists and then importing them into a secondary tool. Either way, this would involve both initial investment to develop and ongoing investment to maintain the technical workaround, as well as likely increases to daily processing time. |
| Comment by Tod Olson [ 19/Feb/21 ] |
|
With
Where the LDP data is not fresh enough, we would probably need to export lists and manipulate them externally. If the sort key is exposed in the exported data, we're probably okay sorting on that column using some tool outside of FOLIO. If the sort key is not available in the exported list, then we would need to add sort keys somehow, perhaps by joining with data in LDP, or perhaps by creating a filter to read the exported file and add a sort key. |
| Comment by Sharon Beltaine [ 19/Feb/21 ] |
|
Holly – Your summary of what is needed for Call Number sorting for FOLIO reporting is good. I agree with David Bottorff's additional comments on the issue of order. The impact of not having this feature on Cornell is basically the same as Chicago's. We are evaluating possible workarounds in the Reporting SIG. Good to know we might have MODINVSTOR-381. |
| Comment by Holly Mistlebauer [ 22/Feb/21 ] |
|
UPDATE: The Capacity Planning Team has given us an additional week to work on this feature. Our freeze date will be March 5 rather than February 26. Also, EBSCO has graciously approved overtime pay for the BE dev from EPAM, and the dev has agreed to work overtime on this. This is the good news. The bad news is that Marc Johnson identified yet another back-end task for this feature while reviewing the dev's code for
The schedule is tight, but we will all do the best we can. Please let me know if you have any questions or concerns. Thanks! |
| Comment by Sharon Beltaine [ 22/Feb/21 ] |
|
With MODINVSTOR-381 complete, we have the normalized call number/sort key in the item data. We are now in a position to test this functionality to make sure it works for reporting. |