...
Item | Presenter | Notes | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Announcements |
| |||||||||||||||||
008 dropdowns work |
Dependent on record type and bibliographic level in LDR - dropdowns in 008 change accordingly and validation rules are applied. Mandatory character positions are in red, optional in gray. If you have an invalid value in an 008 field and you try to save the record, this will prompt an error message and you will have to fix the invalid character position which will be noticeable by a red box surrounding the character position. We can still import records that have invalid 008’s. If we perform batch updates on records with invalid 008’s via data import (i.e. overlaying an existing record), this should also work. In these cases, how will we know that the 008 is invalid? Data import has very minimal validation rules so the error message will only come up while editing via quickMARC. Story related to handling bad 008s imported -
Feedback: It is difficult for some people to see the red outline on the invalid 008 units. Being able to differentiate between no data in a character position versus it being intentionally blank (in the UI they both show up as backslash which differs from how this would display in the raw mark). Blank should be blank, not a backslash. From chat: Christie, with regards to your question: Am I understanding correctly that you sometimes use / to indicate "empty position" and sometimes to say "not coded"? Correct. You can have a |, \, or ' ' (an empty space). Issue where some records have too many bytes on the 008 fields in their records - you can now edit records that have errors in 008 which would include this scenario. Templates would be helpful to solve many of our concerns. | |||||||||||||||||
Tenant level MARC validation rules requirements | Requirements overview document Feel free to add comments to Khalilah’s slide deck. For Ramsons release. Give you the ablility to define validation rules for bib and authority records. Ramsons--via API, future release will provide a UI for defining these validation rules. System field rules (e.g. LDR, 245) a tenant cannot override (at least for the initial release). Standard field rules (e.g. 520) - you can define if it is required, you can define indicator codes and subfield codes. Local fields (e.g. 019) - you can define anything you want. Validation error messages will show inline. Questions (people can respond directly in slide deck - see slide 12; respond by June 6th): How to handle: Cataloger adds MARC bib field 227 and library/tenant has not defined a validation rule. User hits Save button. Would your library prefer to continue to use the current MARC validation rules? If so, why? What requirement has not be covered in this slide deck that you feel is critical to be implemented for Ramsons release? | |||||||||||||||||
PC updates | 2024-05-30 Product Council Agenda and Meeting Notes The Quesnelia Release is still targeted for end of this week. Today the PC discussed how to effectively draw out action items from the document “Things that could be better in FOLIO”. PC is using this spreadsheet as an example. The spreadsheet will be reviewed at the meeting in two weeks. | |||||||||||||||||
BELA (Bulk Edit and Lists App) | Jennifer Eustis | For Ramsons, more work will be done on bulk editing instance notes. For the Bulk Edit Queries, the working group would like to prioritize work on the Electronic Access and in particular being able to query all of the fields (URL Relationship, URI, Link text, Materials Specified, Public Note). | ||||||||||||||||
Data Import Working Group | Jennifer Eustis | The next meeting is June 12. On June 12, the working group is going to discuss open issues added to the Data Import Topic Tracker that have yet to be discussed, 2024-6-12 Data Import Subgroup meeting . | Data Import Working Group | Jennifer Eustis | The next meeting is June 12 . | |||||||||||||
quickMARC Subgroup update | Raegan Wiechert | quickMARC meetings will be cancelled for the month of May. |
...