Some instances have thousands of items; when exporting in custom profile that includes bib, holdings and items, exceeds 99,999 character limit - in which case export fails
Workaround: identify record, exclude record and then export that bib separately
Options
Ignore MARC record limit
Pro: all data exported
Con - makes generating MARC record unusable / difficult to use
Truncate data; with or without logging the error
Pro: error in processing of one record does not affect whole export; easiest to implement
Con: no control over which items are exported
Implementation options: export only MARC bib (no holdings & items); log holdings and items removed to allow for separate export with different profile
Export invalid data to a separate file
Pro: clear separation of the records; all data are exported
Con: difficult to implement; requires architectural changes to current implementation to support two files associated with one export
Use Case for exporting item data with the bib & holdings in .mrc: export for discovery layer;
Handling in existing systems:
Chicago: have split serial records into many to limit the number of items/bib
Holy Cross: have bib records that exceed the limit themselves (mainly due to content notes)
5C: items are not extracted... happens via look-up
Can system ignore AND log those records them? Yes – but then cannot export those... unless they have a separate mapping profile with simplified exported record
Log file needed regardless!!!
Approach: if record exceeds limit, will not be included in export but a log will be created indicated excluded records
Option 3 is long-term desired solution (as per a few voices)
Main scope: review UXPROD-2712 and prioritize remains work
Wiki pages under MM-SIG's working groups
30 use cases identified, reviewed and prioritized
Remaining to do:
call number search
exact phrase match: contributors, titles, other full-text fields that are analyzed and pre-processed
count of matching records; count instances when counting holdings or items may be more appropriate (see later "Inventory Results List Updates" agenda item)
Will these enhancements be available in PO search as well? No, only inventory but worth considering for the instance look-up, which is a separate piece of software / plug-in (UIPFI project). Issues at-hand: UI and data source (Inventory storage)
Searching across all properties? Discussed during last meeting to allow for searching all already-indexed properties (this does not include all properties); there are some fields deemed unnecessary for search... and if we build search for all edge cases, may lose sight of 99% of searches. All are welcome to join subgroup meetings to engage in discussion; reach out to Magda if you'd like to attend.
MM/RA/RM working group on UXPROD-491 : going to Filip's original design from 2017
Mockups for hierarchical display in the above linked slidedeck
Considering how to get away from results that always defaults to Instances; also allows for more data points (e.g.: resource type, format, HRID)
Skipping second-pane step and allows to get to item record (i.e.: not having to open Instance... click on holdings and click on item). Outstanding question around whether want this to be full-screen as default? I.e.: do we want the context in the search-and-filter pane? Also : efficient if search and have one result – should open the one result without additional clicking
"Sort by" features - various fields, which persists until changed
Color change (darker) for identifying levels of hierarchy user is in – alongside easy navigation among levels
Can click-to-expand Instance and Holdings in full-screen
Question(s)/Comment(s):
If multiple holdings on an Instance, would show only the holdings being searched? or all? Only those being searched... but need ElasticSearch for that precision
What is timeframe for implementation? Was among top-20 features listed by libraries; talking next week with UI devs to have their say early in process to evaluate complication of integrating level navigator and result list.
Would demand changes in ElasticSearch – would need more data in instance indexing, as one example. Magda will run mockups by ElasticSearch back-end devs for feedback
For later: we have different UI handling for Instance versus holdings and items; when we get ready to shift to this view, will need to consider how tag info needs to be moved around for full screen instance. Invite Ann-Marie when this is discussed by WG
Cross-functional working group is a good model for future work