2019-09-05 Metadata Management Meeting notes

Peter brought a proposal for a FOLIO project code of conduct. It is in draft form. This is based on Islandora's and Code4Lib code of conducts. They want a code focused on what we want the community to be. Please take a look at the draft and post comments. A small group will be convened and then present the draft to the community. This could be part of the opening session at WOLFCON. Peter is also seeking community support volunteers to deal with reports and articulate reporting guidelines.

We can hire a technical editor (writer). This is the documentation tzar. There will also be a security audit from the same sponsor. They hope to have documentation out as soon as possible, early 2020 for the community to review. This will be commercial grade documentation for users and developers.

Presentation from Tech Council:  https://folio-org.atlassian.net/wiki/x/2xJN

Chalmers is in the midst of their migration, staff training and planning. There will be a future forum hopefully in January. There will be a demo in the next ERM SIG meeting. Dracine will ask about ERM and documentation. Chalmers is a unique implementation given their relationship with their national library, ability to do linked data, no MARC, no finances, etc. Where can we put documentation that people are beginning to create? The FOLIO implementers group has taken on the task of wrangling documentation. This was a chance to test the fulfillment workflow.

FOLIO Bugfest testers: Around 64 people signed up to be testers. Chalmers also wrote a lot for their tests. People could follow those if we have access to it.

Capacity Planning Team will coordinate with institutions where soon after these institutions will decide on go live or not.

ERM: presentation from Chalmers (10 minutes) on Sep 11 in the ERM Sub Group. Meeting times see https://folio-org.atlassian.net/wiki/x/BQBS

Data Import: AM working with designers to finalize more designs. Work on the mapping has been refined with things like the index title or call numbers.

Data Export: The first meeting is today.

Container: This has been wrapped up. The mock-ups are done. This is NOT cap MVP. The group came up with a list of paired down elements to get these implemented first if there was capacity.

For Inventory, there is a capture ALL for functionality and then there are defined permissions for each of the settings pages. This is work for the MVP and implementing the basic CRUD (see UXPROD-1371 above for more details). All records with an underlying MARC SRS bib all have the restriction of being able to edited in MARCcat and not in Inventory; this only applies to fields maintained in MARC. Permissions for all apps have been written over quite some time but will follow the wording of permissions by organizations. Charlotte will be doing an update to align wording. The only blocker is the ability to delete an instance. Further input is needed on deleting records. Deletion can be tricky if there are order records attached or items. We should be able to do this as we can do it now in our systems. We should have deletion in both apps (Inventory/MARCcat). MARCcat isn't necessarily aware of holdings and items. Would you need a check? MARCcat should be aware of the instance record. Ideally MARCcat should do a check for attached records. This can be brought to the MARCcat subgroup. We need to think of this more broadly in terms of any SRS storage to have the same process for deletions. There are many scenarios for why you need to delete records (bad batch loads, duplicates, etc.). If we delete from one place, should we delete from Inventory? We should be able to delete in Inventory. Initiating the deletion in Inventory is a good idea as long as there are the checks and balances for all associated records. With that in mind, for many batch loads, deletion starts with the SRS MARC bib. Chicago is planning on moving administrative data to holdings and item level and get it out of the MARC bib. This may be a policy and/or permissions issue. Batch deletion is critical for Chicago. There's the functionality of "mark for deletion". Data Import does not have permissions set up and there is no deletion set up currently. The permissions have to hook to each other. Are there permissions to access the data import app? There should be an "on/off" setting for Data Import App. This could be a permissions concern if at go-live individual records from OCLC need to be imported. Would it make sense to review permissions across apps in a couple of weeks? Q: Have seen that permissions have different tier options? For all apps, can all the tiers be made coherent? Can the levels be the same across all apps? For example, can we have all as an option? One idea is to move away from using tiers with numbers. Institutions can create sets such as student worker 1, or 2. SRS will talk to the discovery layer. There is the suppress from discovery. Once it is deleted from Inventory, it needs to be deleted from MARCcat; this is the sync. If there are instance records that don't have a SRS record, then a MARC record on the fly created via OAI-PMH.

https://wiki.folio.org/pages/viewpage.action?pageId=78336464

VZG

Stanford

Index Data