| Other updates, announcements |
| Minute taker conversation (what to do?) - self identify minute takers
- a pool? Jacquie S, Jennifer E, Jesse L
- There is a new lead PO: Kelly Drake
- from chat: But Kelly will also take on: Bulk/batch edit and also Title level request
- Kelly is still PO for consortia
- Charlotte is still doing Item Status
German Folio Days Feb 24 / 25 2021: https://www.folio-bib.org/?page_id=1189 including a presentation and demo about CBS2Inventory (union catalogue integration for GBV).
|
Mode of Issuance, Other Reference Data: deviating from defaults (such as note types, identifier types, alternative title types) | | RDA elements have been significantly changed: now two options "single unit" or "multiple unit" https://www.rdaregistry.info/termList/PPModeIssue/ Do we want these values to follow RDA? a different vocabulary source/model? Remarks on the implementation of the new RDA Toolkit (by Rita): Question from Felix: The proposed new MARC field 335 Extension Plan seems related to the change of the "mode of issuance" values. Can someone explain if the fields are introduced together and belong together, similar to content, carrier, and media type? (Rita) The element "extension plan" is an attribute of the entity work while "mode of issuance" is an attribute of manifestation. → http://rdaregistry.info/Elements/w/P10365 | Vocabulary encoding scheme → http://www.rdaregistry.info/termList/RDAExtensionPlan/
For DACH so far no decision has been made about implementing the new element. :: NOTES:: OCLC documentation on Leader/07 ("Bib Level") which might be a better source for mode of issuance terminology: https://www.oclc.org/bibformats/en/fixedfield/blvl.html Reference data migration tool at UChicago - where are folks using default ref data in inventory, and when not?
- Also, mode of issuance
- RDA is changing and the questions of how to adopt in FOLIO
- Mode of Issuance
- changing from serial to 'multi-part' unit
- some confusion on how to use this vocabulary in departments and use in FOLIO
- Many national libraries are not adopting RDA 3R for a significant amount of time
- Mode if issuance at the manifestation vs Extension plan at the Work level (general confusion about implementation and training)
- Terms causing confusion for staff and for FOLIO implementation
- from chat (our migration is tripping over this right now too )
- If we deviate from default FOLIO migration, what would the 'fix' be for that?
- Adding new types of reference data is very time consuming for devs (Charlotte)
- Trying to simplify migration for note types (Cornell)
- Changes made, may still be coming back, maybe due to dependencies due to data-import
- For Iris, some defaults for single-record import are being changed (OCLC are hardwired)
- from chat (With flexibility comes complexity )
- for EDIFACT and 'secret button' profiles, will this change something as FOLIO ugrades?
- devs say no, it does not get changed back
- from chat (I would like to be able to change the way the reference data is displayed to staff, but I suppose that means simply changing the reference data itself. Which isn't easy. )
- Should reference data be moved to the Entity App (in proposal mode now)
- from chat (Seems like this would be a good thing to test during migration testing in a couple weeks. Delete a couple values from settings, and edit a couple, migrate to Iris, and see what happens to the settings / And the more libraries that go live, the more crucial this becomes. We can't have libraries having to reset this stuff after every upgrade / With the location setting, we have that Discovery display name field. Maybe we add a field for some of these that allows for a local label to overlay the RDA label value )
- Suggestion to use the RDA URI for external RDA-defined elements as opposed to FOLIO IDs
- RDA wants to use certain terms, but we need the local option for making a local label for that term (allows for local granularity)
- We need specific and technical examples to be shared with devs
|
| Deleting SRS MARC bib records | Ann-Marie Breaux (Deactivated) | impact on Inventory Instance records - update on conversation in data-import subgroup (right now, no delete)
- updates on MARC will update the Instance from SRS
- currently, instances can not be deleted if there is SRS
- from chat (Underlying SRS record is a dependency for deletion of the instance record)
- If the Instance is deleted, the MARC would also be deleted (agreement from group)
- at some point, an action to delete records will be added to an import profile
 Option 1- Comment from chat (So we should time the work: Deletion of SRS MARC bib and Deletion of Instance in the UI )
 - Sometimes, both options are desired
- from chat (I would definitely want to delete instance records sometimes)
- from chat (It seems like in most cases, we're deleting records because we don't want any "hangers on" in the Inventory)
- staff suppressed was suggested (which could be an option to track certain needs)
- from chat (Here too, we check to make sure that there are no associated records. Though sometimes in batch deletes, we get a warning and that record isn't deleted.)
- If the Instance can not be deleted, we will want that to be intentional (not made by the machine, but by a person)
- from chat (that mirrors what we do - a report gets generated, people have to look at it )
- at 5C, completely delete things all the time
- from chat (I think that we should be able to do both - batch and individual)
- from chat (+1 Christie. For batch, I like having a report if there are records that can't be deleted)
- Also related, underlying authority deletion
- Use cases and understandings from staff suppression?
- date updated from staff suppression
- staff suppression means suppression from SOME staff (if nobody can see it, then nobody can see it for marking for deletion)
- from chat (There should be a permission for it already available. )
- from chat (The only reason we are thinking about using it is that *I believe* that it will suppress the results from the search by default and staff will not need to remember to use the filters to determine if a title is suppressed or not. For instance, if we have a lot of short bibs for ILL for instance this can clog up our result list. )
- from chat (we have no use case for staff suppress in the 5C)
- The question still lingers for how to set permissions for seeing staff suppressed records
- Add to list of things to demo by implementers
- from chat (We use suppressed bibs to attach purchase orders for bulk purchases )
- Question about how to distinguish between results and inventory (print and electronic, but other records such as stubby inventory records UChicago) - causes confusion, also noted at Cornell
- There are issues, re: distinguishing between print, e, etc
- from chat (Yes, agreed—we are getting a lot of feedback that people can’t tell what something is. the filters are based on RDA terms, which are not helpful to many users )
- maybe implementing something like a 'red' highlight to mark suppression and for format (Charlotte)
- From chat (We came up with an idea to combine the RDA based filters to create new filters like "eJournal", "eBook" etc. )
- from chat (Staff suppress is scary to me because you have to be deliberate and understand how to use it. If there are only a couple of use cases, then being able to mark the record specifically such as 'marked for deletion' and something that would make it known it is specific to catalogers 'for catalogers only' / 'local use only'. I am sure we could come up with some thing specific that would make it explicit to all users without having to figure out who should see and not see the record. Particular to deletion option 2, staff suppress should be optional and not automatic otherwise there is an assumption schools are using that feature. )
- This definitely needs priority
- ref:
UXPROD-492 - ref:
UXPROD-491
Implement Refined UX-design for Inventory - hierarchical navigation structure (Instance, Holdings, Item) - from chat, from Index data (And here the Result list features: )
- ref:
UXPROD-1634 (index title/title)
UXPROD-2667 (sort on contributor, when more than one contributor is listed)
UXPROD-2668 (Adding instance HRID)
UXPROD-2669 (Adding resource type)
UXPROD-2670 (Adding format)
UXPROD-2671 (Adding edition)
UXPROD-2703 (Adding publication date) - from chat (We did a test of Honeysuckle and found that we have to be very intentional in assigning Permissions )
- from chat, from Ann-Marie (And tags! I know they are not as controlled as some people would like, but it would be interesting to think about assigning a tag to any ILL-stub instance being created, so that they could be found and deleted periodically. )
- elastic-search still needs to be understood and its implications before other experience decisions are made, this affects time scales and priorities
- from chat (I am also a Duke person who is uncomfortable with staff suppress. We already have an environment in which items for our campus in China do not display in the ILS to all staff, and this causes problems for cataloging and troubleshooting. I would not want to create a broader problem through our FOLIO implementation. In fact, I hope we can address our current issue in our implementation.)
- Option 1 and Option 2
- Does not affect MARC authorities at this point
- from chat, Ann-Marie: (We briefly talked about alt-titles vs related titles in the Data Import subgroup this week. Right now the MARC-Instance map does not assign the type of alt-title, and doesn't map any related titles except preceding/succeeding. If we need to modify that default MARC-instance map, we'll need decisions on each 24x field and indicator value. Or if we want to leave it pretty vague for now, that's totally fine too. Then each library adjusts the default map as they see fit.)
|