PC update | | Minutes |
Other updates/announcements | | BugFest is live. Please do jump-in. Ann-Marie asked for more testers around data import template issues; BugFest channel has request. |
MARC records that exceed maximum length – desired export behavior? | @Magda Zacharska | PPT in meeting recording 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 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
|
Inventory Search Improvements (ElasticSearch) updates | @Magda Zacharska | 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)
Supported Search Types: https://github.com/folio-org/mod-search#supported-search-types Question(s): 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.
|
Bound-with back-end work updates | @Charlotte Whitt |  UXPROD-1241: BE: Analytical records; bound with - part 2: link multiple bibs to the same itemClosedPreview
UXPROD-2855: FE: Display Bound with in the UI (Instance, holdings, item)ClosedPreview UXPROD-3080: Edit - first iteration. Analytical records; bound with - part 2: link multiple bibs to the same itemClosedPreview Slidedeck Not discussed - hold for next meeting |
Inventory Results List Updates | @Charlotte Whitt | UXPROD-491: Result list. Long term solution. Implement Refined UX-design for Inventory - hierarchical navigation structure (Instance, Holdings, Item)DraftPreview Working group - documents on the FOLIO wiki Slidedeck 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
|