Inventory
(UXPROD-785)
|
|
| Status: | Closed |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None | Parent: | Inventory |
| Type: | New Feature | Priority: | P3 |
| Reporter: | Charlotte Whitt | Assignee: | Charlotte Whitt |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | call_number, cap-mvp, inventory, metadatamanagement, po-mvp | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issue links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Epic Link: | Inventory | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Analysis Estimator: | Charlotte Whitt | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Back End Estimate: | Large < 10 days | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Back End Estimator: | Jakub Skoczen | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Estimation Notes and Assumptions: | Outstanding questions:
* Implemented as a search index or as a persisted field containing the normalized version of the call number? * Hard-code normalization rules or configurable? |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Development Team: | Core: Platform | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| PO Rank: | 125 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| PO Ranking Note: | CW: Aligned PO rank with Calculated Total rank | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Chalmers (Impl Aut 2019): | R2 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Chicago (MVP Sum 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Cornell (Full Sum 2021): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Duke (Full Sum 2021): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: 5Colleges (Full Jul 2021): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: FLO (MVP Sum 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: GBV (MVP Sum 2020): | R2 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: hbz (TBD): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Hungary (MVP End 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Lehigh (MVP Summer 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: MO State (MVP June 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: TAMU (MVP Jan 2021): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: U of AL (MVP Oct 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
This feature capture the work planned for the Core platform team The elements Call number, and Call number type are implemented in the Holdings and Item records as of Q4 2018. Use cases: Several libraries have expressed a requirement on being able to search by normalized call number - besides search on call number as an exact string, we'd also need search where we handle removing of misc. qualifiers, and more. Documentation:
Some more complex examples from GBV libraries *before *normalization (added by Felix Hemme):
|
| Comments |
| Comment by Charlotte Whitt [ 12/Dec/19 ] |
|
Cate Boerema Holly Mistlebauer - I have given this new feature for Search on Call number - work assigned to the Core Platform team the label ` {cap-mvp-split} ... but not sure that really works, while this work is split out of
With these changes the situation is:
Please change the labeling if you want the labels to different than what I have done! CC: Jakub Skoczen |
| Comment by Cate Boerema (Inactive) [ 12/Dec/19 ] |
|
Thanks Charlotte Whitt. In this case I think it's fine to assign this feature "cap-mvp" as, from a functional perspective, it's no different than the original feature
|
| Comment by Charlotte Whitt [ 12/Dec/19 ] |
|
Thanks Cate Boerema |
| Comment by Cate Boerema (Inactive) [ 17/Dec/19 ] |
|
Hi Charlotte Whitt. The other feature for call number search is marked Analysis complete. If that one is ready to go, this one should be, as well, right? |
| Comment by Charlotte Whitt [ 17/Dec/19 ] |
|
That's correct. Updated the status, Cate Boerema |
| Comment by Jakub Skoczen [ 10/Feb/20 ] |
|
This is what I wrote on the "functional" side of this ticket: One solution could be: 1. add a new normalisation function in RMB called stripPunctuation. This function would remove all punctuation and whitespace from a given field before creating an index, e.g a callNumber like "a/b/c 123-3" would result in "abc1233". When enabled for a field, this function would also apply during search.
2. Have the UI expand the search into an OR expression across three fields: callNumberPrefix, callNumber, callNumberSuffix like so: given a search for "a bc d" the UI would generate a query callNumberPrefix=a AND callNumber=bc AND callNumberSuffix=d OR callNumberPrefix=a AND callNumber="bc d" OR callNumber="a bc" and callNumberSuffix=d OR callNumber="a bc d" Ugliness of the solution noted. Ideas for something less ugly welcome |
| Comment by frances.webb@cornell.edu [ 10/Feb/20 ] |
|
On point 1) Call number normalization for search needs to be a little more careful than removing all punctuation. While most punctuation should be removed, punctuation can provide an important break between elements of a call number and removing it entirely can concatenate values that should be separate. I've found it generally a stronger solution to replace punctuation with spaces, and then normalize any consecutive spaces to single spaces. So "a/b/c 123-3" would become "a b c 123 3". I also find it useful to add spaces between alphabetic and numeric components of a call number, so "HD30.213 .A37 2010" would become "hd 30 213 a 37 2010". It would be great if someone more familiar with the GBV call numbers can confirm that these guidelines make sense for those, since they're structured very differently from the US LoC call numbers. On point 2) If you're storing the call number in normalized forms for searching (which is probably unavoidable in the end), the necessary components can be concatenated into those fields. I'd recommend two stored search fields, one with callNumberPrefix + callNumber + callNumberSuffix, and one with callNumber + callNumberSuffix. In my experience, all call number searching must be begins-with/left-anchored, and indexing both with and without the prefix allows the begins-with match to optionally include the prefix. Then your search looks like callNumberNormalized like "a bc d%" OR callNumberNormalizedWithPrefix like "a bc d%". I'm not sure whether the CQL would need to acknowledge that the search is left-anchored when the left-anchored nature of call number search isn't optional. If not, it could be very simple. |
| Comment by Jakub Skoczen [ 10/Feb/20 ] |
|
frances.webb@cornell.edu you must consider both 1. and 2. as the complete solution, 1. is only the "supporting" portion on the DB side. 2. includes a query that make prefix and suffix "optional" in the user input. |
| Comment by frances.webb@cornell.edu [ 10/Feb/20 ] |
|
Yes, that's how I read it. Well, in my comments in part 2 I did include some thoughts about database indexing, so those could have fit in part 1 instead. But that doesn't change the options for solution. |
| Comment by Ann-Marie Breaux (Inactive) [ 12/Feb/20 ] |
|
Hi frances.webb@cornell.edu and Jakub Skoczen I'm definitely not a developer! I like Frances' idea of a single space replacing any punctuation or spaces, instead of smushing everything together with no punctuation or spaces. It seems like removing decimal points and closing up the space in the LC classification numeric (not the one preceding the Cutter) number or in Dewey numbers would be especially problematic. |
| Comment by Jakub Skoczen [ 25/Feb/20 ] |
|
Charlotte Whitt I have converted this into a "2nd phase" feature blocked on additional normalisation functionality, see
As we discussed, for the first phase, only lightweight normalization is going to be applied (lowercasing) and this does not require new functionality in the Platform, see
|
| Comment by Brooks Travis [ 07/Jul/20 ] |
|
Charlotte Whitt Sorry to be obtuse, but what does this ticket being closed as "won't do" mean for normalized call number searching in FOLIO? |
| Comment by Charlotte Whitt [ 24/Jul/20 ] |
|
Hi Brooks Travis - sorry for not seeing this until now. This feature was closed due to the Core Functional took over all the planed work for implementation of search on call number. Original we thought we had to split the work between the Core platform and the Core functional team, but that was not necessary. Please notice that you can try out using the search on normalized call numbers in the Bugfest-Goldenrod environment, and the functionality will be rolled out, and available for all sandbox environments, with the Goldenrod release. Here screen dumps from Bugfest-Goldenrod: Search in the Holdings segment, using the search option Call number, normalised. Also search on the effective item call number being normalized is also possible with the Goldenrod release. |