MM SIG Parking Lot (Old)
A space to record issues/ideas that the MM SIG intends to examine.
When you add a topic, please include your name and the date added.
- Demo of MARC SRS Search API: UXPROX-2916. This is ranked as R1 for many libraries. It would be great to learn what has been done, what work is scheduled, plans for future development including a demo. (Jennifer E.: June 10, 2021)
- a) duplicative metadata for eBooks: some in the remote KB, which allows for accessing the eBooks in the library’s discovery layer, and some in locally-stored MARC records. Moving forward, do we see that scenario working differently in FOLIO (only use KB metadata perhaps?) and if so, 1) what does that mean in terms of the richness of the metadata and 2) what about current workflows that involve transporting non-bibliographic metadata in those local MARC records, e.g. acquisitions data? (Ann-Marie: 21 Sept 2017): discuss topic: https://discuss.folio.org/t/ebook-metadata-records-in-folio/1286.
-
UXPROD-139Getting issue details...
STATUS
– this might be addressed by the Entities app? (Laura, April 27, 2021)
b) How are ebooks / ebook packages going to be represented in the inventory? libraries have a variety of approaches to managing ebooks - some have individual records for ebooks; some have a 1 record approach (ebook links on print records) AND we can have the same ebook title represented in multiple packages; it sounds as if Packages will be represented in the Codex, but not the inventory. Nov. 15, 2018 update: Packages may now be represented by Container records in Inventory (Lynn W., 9/28/17) discuss topic: https://discuss.folio.org/t/ebook-packages-relationship-to-individual-title-records/1287. - UXPROD-151Getting issue details... STATUS - authority control: how does this fit with FOLIO, with the codex, discovery, local inventory (Ann-Marie: 21 Sept 2017)
- a) metadata for non-textual formats, to ensure FOLIO is taking their needs into account enough. (Ann-Marie: 21 Sept 2017). Inventory Beta Metadata Elements: https://docs.google.com/spreadsheets/d/1RCZyXUA5rK47wZqfFPbiRM0xnw8WnMCcmlttT7B3VlI/edit#gid=952741439
b) Need music cataloging review of Inventory, MarCat, etc. (Laura W, Oct. 15, 2018) - a) referential cataloging: what would this mean for discovery? for local edits to cataloging records? for vendor-supplied cataloging or shelfready services? We need to talk through these types of issues, but maybe not until after v1. (Ann-Marie: 21 Sept 2017) Nov. 15, 2018 update: wait until post Chalmers
b) Discovery comes from where? Inventory? Other apps? What is role of MarcCat? For example, do we need the ability to mark a record as suppressed from public display in MarcCat? (Laura W., Sept 12, 2018) Update, Oct. 15: discovery should be coming, initially, from the Marc Storage "blob." Oct 15: Question for Laura from A-M. Just saw this note. The MARC storage is just MARC data, so it seems like we still have a question of whether there is a way to indicate a record should not be pushed out for discovery - in Inventory? in MARCcat? Seems like Inventory would be the place for it since MARCcat doesn't necessarily know about all the instances in Inventory. Then when whatever service goes to harvest the MARC data for pushing out to Discovery, it maybe 1) starts with Inventory to know what it should be trying to push out to discovery, 2) then grabs MARC storage data for anything that it's supposed to, 3) creates MARC on the fly (but does not store) from the Inventory record for anything that is supposed to go to discovery that does not have underlying MARC. Would be great to discuss at an upcoming MM SIG meeting. - UXPROD-993Getting issue details... STATUS - protecting local edits (inventory records): this is definitely not something I think we should be asking for in v1, but I'd love to be able to protect fields not in a systematic way, but specific fields in specific records – for example, we have added a local genre/form term to some records that help students find materials for a class assignment; most of the records are for print materials but a few are for e-books that we have acquired as part of a package; our current batch-loading processes don't preclude the possibility of this field being stripped out if an updated version of the record is supplied to us; Adding to this on 18 Octo 2017: I'd also like to be able to do something like protect an item record from deletion based on a location code (Laura W, 27 Sept 2017)
Combined format bib records: while you are considering this resources/formats, don't forget folks who have multiple formats on one bib, so there could be 007s etc. on print records where the e-version is also noted on the print version. (Lisa, TAMU, Jan 18 2018)
- Synching holdings and item data with bibliographic data: Some note elements that have been defined for holdings and items (e.g., action note, ownership and custodial history) have historically been maintained in 5xx fields in the bibliographic record. How will the data be managed when it is required at both the bibliographic (5xx entries) and holdings / item level (Inventory data elements)? (Christie, Chicago, July 12, 2018) - UIIN-235Getting issue details... STATUS and - UIIN-253Getting issue details... STATUS
- Order/sequencing of holdings on an instance, and order/sequence of items within a holdings record: should there be a way to control the order (alphabetical, sequential numeric, always show Main first) (Lisa, TAMU, July 19 2018)
-
UXPROD-1635Getting issue details...
STATUS
and
-
UXPROD-1625Getting issue details...
STATUS
Default mapping of MARC to Inventory Records: Behavior after migration "I don't want to take us back to the previous discussion and derail this one, but I'm curious about expected behavior for changing the default mapping for MARC records to inventory records. When we change, do we expect that all of the existing records in inventory would be retroactively updated from the MARC store? What would that do to system performance while it's happening? It might be a non-issue for the developers, I just wanted to bring it up so we can make sure it gets thought through." - Dennis (posted in MM SIG meeting chat on 2/7/2019)
- Multiple (aka Alternate) Graphical Representations FOLIO-wide issues around the display of non-Roman character sets is present. There should be a way to make sure that all Unicode values are validate-able including those stored in the MARCcat or Source data stores. The ability to validate Unicode values in current systems does not exist, so doing so would be an improvement of the current state.
-
UXPROD-1646Getting issue details...
STATUS
Draft proposal - - UXPROD-1647Getting issue details... STATUS
- Right now there are a few UXPROD issues related to in app reports for inventory. It's not clear though that the data for these comes from inventory alone, at least some seem to include MARC data that would be in SRS. More clarity on the reports that will be generated from inventory, SRS, and MARCCat in-app reports vs data warehouse reports would be helpful. (jenn colt, Cornell, 4/25/19)
- Search Results Display issues: Default inventory data for display in search results list. Related to UXPROD-1634. New story required to request ability to configure which inventory are displayed in the results list. (Christie Thomas, UChicago, 7/8/2019)
- Results refinement
- Acquisitions data display in Holdings/Items (UXPROD-1607) – revisit
- Receiving data in Holdings? In Receiving app? (UXPROD-1608)
- Validation of MARC records. See:
-
UIIN-1239Getting issue details...
STATUS
Example on invalid language code in the MARC record, result in that the Instance record does not display, and throw an error message. The problem is related to the language translations that were introduced after Goldenrod, in UIIN-829. If the value received from the MARC record is not one that Inventory recognizes, it throws the error screen when trying to view details.
Should Data Import/Inventory impose more validation and reject data that cannot be understood properly, forcing someone to clean up the underlying source data? That would mean much more pre-validation at its source, whether that is SRS, an external system, a migration file of JSON records, etc. We know that all catalogs have some level of dirty data; how much do we want to force cleanup? - Symbols / words indexing in Inventory, e.g. & and, y, und, et: - UIIN-1260Getting issue details... STATUS
- UI review of Inventory for different types of users/different institutions’ data; including treatment of fields that are not mapped (as opposed to data not recorded, i.e. blank fields) Show & Tell?
Change tracker development (https://folio-org.atlassian.net/browse/UXPROD-782 epic https://folio-org.atlassian.net/browse/UXPROD-910)
- Training sessions, e.g. CQL, SQL, Postman, others? what needs/use cases are each tool best for?
- Music / Maps / Media cataloging review of data elements in Inventory – show & tell?
- Revisit Container Records (depending on roadmap)
- Update and possible demo of Format and print of spine labels. https://folio-org.atlassian.net/browse/UXPROD-1316 In particular, what is the expected user interface and is there a plan to have a dedicated Settings > Inventory > Label printing permission or is it due to be part of existing permissions? It appears to still be planned to be completed for Juniper. Also, and update to ABLE Bindery (https://folio-org.atlassian.net/browse/UXPROD-2800).
- Links and linking fields between Inventory records, e.g. monographic series instance relationships, 773 fields, bound-withs, etc.
A space to record issues/ideas that the MM SIG has examined, but that had been tabled:
loan type: Do we need the element loan type in the Codex' item metadata in order to borrow books? (Felix: 26 Oct 2017) --update Nov 2nd: the element is now listed in the MARC mapping spreadsheet:https://docs.google.com/spreadsheets/d/1kdYx63J0KoqR3-LUHuPAzERgj8WE0OQ08rzuCaJaHWs/edit#gid=901484405Split view of records in FOLIO apps: would be very helpful in future versions to be able to view two different instance records (plus summaries of related holdings and items) at the same time. Some cases where we might want this include serials with title changes (we may also want to move items/holdings between records and edit holdings), holdings/items attached to incorrect record (also would be nice to be able to move from one to the other). Other use cases? (Laura W., 21 Nov 2017)MARCcat issues
(Laura W, Sept. 4, 2018)diacritics in searching – search/browse functions need to work both with and without diacritics enteredkeyboard commands vs mousing & accessibility
MARC exports: What data needs to be accommodated in a MARC export? Use cases include only full bibliographic description with a MARC srs record; MARC srs records + folio inventory instance data (when a MARC srs is not present); MARC holdings; FOLIO holdings and item mapped to local data fields; etc.See - UXPROD-652Getting issue details... STATUS (Epic)Mode of issuance, RDA standards: see Slack conversation (note the multiple side-threads)German libraries will NOT adopt the new RDA Toolkit by Dec 2020, see information from the German National Library:"On December 15, 2020, the current beta toolkit will become the official and authorized version of the RDA standard. The original toolkit remains active and serves as the basis for cataloging in practice."Quote from Laura Daniels via Slack (https://folio-project.slack.com/archives/C20V5L40P/p1605280762218100?thread_ts=1605276325.206200&cid=C20V5L40P):"The PCC (Program for Cooperative Cataloging) libraries will not be adopting the new toolkit until July 2022 at the earliest."Do we also need to consider how this relates to the new RDA Work Entity, Extension Plan?Update: in March? 2021, we decided instead to ask that mode of issuance be made editable at the tenant levelOCLC integration – the ability to export a single directly from OCLC into FOLIO; UChicago, Cornell, and possibly others are working with Index Data on a solution. in process: See - UXPROD-211Getting issue details... STATUSRelinking/transferring holdings and item records See - UXPROD-137Getting issue details... STATUS