The SIG conveners announced that the charge for SIGs will be "refreshed". Design, development, documentation, user acceptance testing, discussions with libraries that have implements all need to be included so the charge reflects the realities and SIG members expectations will be clear.
From chat (has there been any discussion of surveying SMEs for their experiences in SIGs? ) answer from chat (not yet)
Forum coming, to understand the future
Putting together a survey, and there may be some drafting and work-shopping the draft before sent
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)
The German speaking community (DACH) has not yet set a date, but implementation will not start before 2022.
"The National Library of Sweden has decided to await work on the new Toolkit. A transistionto the updated RDA requires considerable resources for translation as well as for work with Swedish practice, instructions, training etc. and we have come to the conclusion that we don’t have these resources, at least not in 2020" (Survey conducted by EURIG, see http://www.rda-rsc.org/sites/all/files/RDA%20in%20Europe%20May%202020_0.pdf)
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.
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
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)
no 'free-floating' MARC
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. )
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.)