Inventory (UXPROD-785)

[UXPROD-2185] Inventory. Search call number (Core platform, normalized 2nd phase) Created: 10/Dec/19  Updated: 01/Feb/22  Resolved: 23/Mar/20

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: PNG File Skärmavbild 2019-12-04 kl. 14.46.11.png     PNG File Skärmavbild 2019-12-04 kl. 14.48.42.png     PNG File Skärmavbild 2020-07-24 kl. 12.27.09.png    
Issue links:
Blocks
is blocked by MODINVSTOR-446 add indexes for call number searching... Closed
is blocked by UXPROD-1626 Store Effective Call Number Prefix, C... Closed
is blocked by RMB-566 add "stripWSPunct" and "normalizeWS" ... Draft
Defines
is defined by MODINVSTOR-445 Search. Holdings. Search option for C... Closed
is defined by MODINVSTOR-485 BE: Search. Holdings. Search option f... Closed
is defined by UIIN-857 Normalize Call numbers for Call numbe... Closed
is defined by UIIN-858 Search. Holdings. Search option for C... Closed
is defined by UIIN-983 Search. Holdings. Search option for C... Closed
is defined by UIIN-721 Holdings record. Implement new elemen... Closed
is defined by UIIN-722 Item record. Implement new element: n... Closed
Gantt End to Start
has to be done before UXPROD-1714 FOLIO wide search by call number for ... Open
Relates
relates to UIIN-985 Search. Holdings and Item segments. S... Closed
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:
Multiple times daily catalogers and other library staff need to search by call number; system needs to search normalized version, not exact text string

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):

  • 8 G.B.439 :6
  • JUR:R III:54:(1):Schm:1850
  • 94 NF 14/1:3792-3835
  • 1990/146 4°
  • 426/083 4° SH 34
  • Z 557: 54.1961/62,7-12
  • Y 43839 (2017/18)


 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 UXPROD-1655 Closed cap-mvp. The latter feature is now dedicated solemnly the work by the Core Functional team.

With these changes the situation is: UXPROD-2185 Closed cap-mvp-split is blocking UXPROD-1655 Closed cap-mvp

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 UXPROD-1655 Closed The only reason we created a separate UXPROD was because the work needed to be split across teams.

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. RMB-566 Draft

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 RMB-566 Draft and MODINVSTOR-446 Closed .

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 MODINVSTOR-444 Closed .

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.
Search on: hq281K73 2009 - which finds the title with call number: HQ281 .K73 2009
https://bugfest-goldenrod.folio.ebsco.com/inventory?qindex=callNumberNormalized&query=hq281K73%202009&segment=holdings&sort=title

Also search on the effective item call number being normalized is also possible with the Goldenrod release.

Generated at Fri Feb 09 00:21:51 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.