2022-07-14 Metadata Management Meeting notes

Owned by Heather MacFarlane (Deactivated)
Last updated: Jul 14, 2022 by Charlotte Whitt
15 min read

Date

Charlotte Whitt

Recordings

Recordings of meetings can be found in the Metadata_Management_SIG > Recordings folder on AWS from 2022 onwards: https://recordings.openlibraryfoundation.org/folio/metadata-management-sig/

Discussion items

Notetaker
Alissa Hafele
Announcements

Charlotte Whitt Laura E Daniels 

Revisit UI/UX for Instance Mark for deleting. We presented the two ways to do Mark of instance deletion - either in the Edit form or in an Action menu, at the meeting on 30/6. We have since learned that it will be much easier. 

  • We think it will be easier to do in Action menu, but unclear just yet. Should be able to move forward and more info to come to MM SIG.
PC update


Meeting notes: https://folio-org.atlassian.net/wiki/x/JIlK

  • Bugfest starting next week. Only 35% cases claimed. Please go in and claim sooner rather than later. More test cases than normal. 
Release Notes/Changes

Jenn Colt Laura E Daniels 

MM SIG Release Note & Other Highlights

  • HF#2 was released, working on #3
  • Another plug for bugfest so we don't have to have hotfixes!


Khalilah Gambrell 

1.) Browse by series expectations (Nolana)

  • Title data > Series statements
    • Marc mapping includes all except some control numbers - 4xx?, 8xx, all various subfields, all into one instance field.
      • Jacquie - Would like to see 490 when no 830 exists or just 830. Wouldn't want to see $w.
        • Reminder - can remove fields/subfields from default mapping if desired.
        • Only the 8xxs in the default MARC-Instance mapping
    • Is it acceptable for browse list to include all of the info in the Instance Series statement field?
      • Browse list is using the Instance series statement regardless of source.
      • Currently Inventory doesn't know if authorized.
      • What are the reasons staff are browsing by series?
        • Find all works that have series title in data
        • Find missing volumes
        • Spell checking
        • If classed together - wanting to check that they have been done consistently
      • Sounds like current information included in browse is useful for the above use cases.
        • Per chat: ISSN also needed.
        • If all is included, mapping could be used to remove information from Instance display.
        • For records that are not source MARC, how will you control browse info display?
      • Khalilah will proceed with building some more mock-ups and have group review.
        • Will need to figure out volume and sorting.

2.) Browse by genre/form handling (Orchid)

  • Previously discussed - Interest in being able to identify genre/form in instance which would make browse easier
  • Want to discuss at WolfCon - Discovery and FOLIO
  • SIG and Felix Hemme should discuss
  • Need to be sure to discuss in context of future with discovery based on Inventory model (not marc).
    • Anne-Marie: One concern I have is similar to what Jacquie is saying, but sort of opposite. I'm all for reconsidering and making things more granular if necessary, but each adjustment - especially to make things more granular - has substantial work, not only for development, but also for converting a library's existing Instance data to reflect the schema change
  • MM SIG will discuss and work will move out to Orchid/Poppy depending on what is decided by group

3.) Proposed quickMARC UI changes

How to show field is now controlled by Authority record?

  • Context
    • Hard to support in single text box, so current mock-up shows subfields pulled out as editable.
    • Feedback given around ability to tab across these subfields.
    • Is this a good way to convey what is editable and what is not? Show all subfields be in separate boxes to be consistent?
  • Mock-up: All subfields in separate boxes. Option B
    • Will support tabbing through AND indicate what is controlled and what is not.
    • Could slow down staff entry? Fields with many subfields?
      • Will break into boxes once saved. You can add subfields in initial box (e.g. copy entire series of subfields and paste) and then once saved it will be broken up.
    • What about copying entire string to create new field?
      • Still needs to be figured out to allow for this.
    • Is tabbing across all seen as needed? In particular in light of other features that are needed?
    • Option could be to only apply to Controlled fields. Option A
      • Alot of consensus around this
      • Will still need to copy and paste entire field
  • Option C
    • Nice to be able to tell at a glance
    • Would not want to get surprise error messages

Question: Will fields only be locked down if library has that Authority record in FOLIO also? YES, BUT if no automated linking enabled than the fields will be editable.

      • Some institutions plan to use the manual process and not rely on Automation. Is this written so that it can be used in the Entity Management app at some point?
      • Khalilah: Development must take into account Entity Management App. However it is developed, needs to consider catalog enrichment, linked data, entity management. Requirement is written as such.

Timeline for Authority linking:

        • Nolana - Manual link capability, lock-down will be considered re: Data Import. Will not block updates, will report out. 
        • Orchid - Automated linking.

Additional Updates from quickMARC group

  • Make it easier to know selected field that is deleted
  • Support deleting multiple fields with one action
  • Able to tab from one subfield to another

Second iteration for Keyboard Shortcuts?

  • Requires more of Khalilah's time or a PO.
  • Complex across different keyboards. No pattern to rely on.
  • Could it be a tenant localization? Or could tenants create their own shortcuts?
  • Need to determine a path forward. Possibly at WolfCon.
    • Charlotte: We can use the need for a PO for Key board short cuts as an example at the PO session at WOLFcon, where we try to recruit new POs.

Slide deck - 







Chat:

17:37:22 From kgambrell to Everyone : Morning Glory Bugfest details - https://folio-org.atlassian.net/wiki/pages/viewpage.action?spaceKey=FTC&title=Bug+Fest+R2+2022+Morning+Glory
17:43:26 From Alessandro to Everyone : Older records have "440" with no corresponding "8xx" field.
17:44:18 From Laura Daniels to Everyone : yes -- we might have 490 only, we might have 440 only, we might have 490/830 (or 800, 810, or 811) and all contain series information
17:44:27 From Jacquie Samples -- Duke to Everyone : That is true Alessandro, but the 440 is now obsolete.
17:46:03 From Jacquie Samples -- Duke to Everyone : So, like the 490, I would only want to see the 440 when there isn't isn't a corresponding 830.  Of course, that shouldn't happen, if there is a 440 the 830 shouldn't also be encoded for the same series.  :)
17:47:53 From Laura Daniels to Everyone : exactly, instance records don't know anything about MARC subfields
17:48:13 From Jacquie Samples -- Duke to Everyone : Can we also choose what is included in the Browse index?  Or will that be baked in regardless on how we've mapped data?
17:48:43 From Jacquie Samples -- Duke to Everyone : Or, rather, what is displayed after a Browse search?
17:49:12 From Natascha Owens (she/her) to Everyone : I believe at UChicago we have mapped the $3 which appears at the beginning of the string and that would pose a problem when browsing (but I would have to double check on that)
17:49:34 From Ann-Marie Breaux to Everyone : Khalilah was right - only the 8xxs in the default MARC-Instance mapping:
17:49:52 From Laura Daniels to Everyone : aha, we must have customized our mapping at Cornell to include the 490s
17:49:54 From Ann-Marie Breaux to Everyone : 800$abcdefghjklmnopqrstuvwx35
17:50:05 From Ann-Marie Breaux to Everyone : 810$abcdefghklmnoprstuvwx35
17:50:17 From Ann-Marie Breaux to Everyone : 811$acdefghjklnpqstuvwx35
17:50:24 From Ann-Marie Breaux to Everyone : 830$adfghklmnoprstvwx35
17:50:50 From Laura Daniels to Everyone : Jacquie, that sounds like a use case where you'd be querying your MARC data, not browsing instance data
17:50:58 From Sara Colglazier  to Everyone : +1 just Authorized .... but the 490s are not authorized
17:51:33 From Laura Daniels to Everyone : If you don't map your 490s to your instances that takes care of them not appearing in a browse list
17:51:47 From Ann-Marie Breaux to Everyone : That's a good point, Laura
17:51:53 From Jacquie Samples -- Duke to Everyone : I would want to browse the Inventory data, though, Laura.
17:51:53 From Sara Colglazier  to Everyone : Esp. for Cat Seps
17:52:08 From Lynne Fors to Everyone : +1 Sara
17:52:24 From jeanette kalchik to Everyone : We have sometimes used it to spell check
17:52:33 From Jenn Colt to Everyone : sorry for dumb- how can you tell it is authorized?
17:52:44 From Jacquie Samples -- Duke to Everyone : But in these days, we'd want to map Some 490s, depending on the indicator values, so there has to be a nuanced mapping, I suppose.
17:52:52 From Laura Daniels to Everyone : you can only tell in the MARC (or by looking in the authority file)
17:52:57 From Ann-Marie Breaux to Everyone : In the Instance, right now, you can't tell if it's authorized
17:53:01 From Laura Daniels to Everyone : (not dumb, Jenn)
17:53:08 From Jackie Magagnosc to Everyone : If I was working on a series title that is classed together, wanting to check that they have been done consistently
17:53:34 From f-piscitelli to Everyone : Also to sewe how the series statement has been formed over time--it may have varied.
17:53:42 From Jacquie Samples -- Duke to Everyone : @Jenn, authorized series titles are coded in the MARC 8XX fields now, but were in a 440 OR 830 in the past.
17:53:51 From f-piscitelli to Everyone : see, nor sewe!
17:53:52 From Jenn Colt to Everyone : got it, thank you
17:54:12 From Ryan Tamares (he/him) to Everyone : +1 Jackie
17:54:18 From Ann-Marie Breaux to Everyone : If you want to map all 490s to Instances, adjust the default map. If you want to map some 490s, probably best to do some data cleanup to add 8xx's before migrating, and leave the 4xxs out of the default map
17:55:46 From Ryan Tamares (he/him) to Everyone : Not only what Jackie said, but I want to be able to see treatment of the ISSN for those series that have them
17:56:01 From Jacquie Samples -- Duke to Everyone : Ann-Marie, the 490s I am references are not bad data, so there is no clean up to do.  It is a case where there isn't an authorized access point for a variety of reasons.
17:56:27 From Jacquie Samples -- Duke to Everyone : +1 Ryan, the ISSN is needed in the browse results, I think.
17:56:40 From Ann-Marie Breaux to Everyone : Ah - good to know, Jackie - so you would have to figure out a workaround
17:56:42 From Dennis Christman to Everyone : can the mapping be updated to map 490s with 1st indicator 0 and not when 1st indicator is 1?
17:57:05 From Ann-Marie Breaux to Everyone : Sorry, Jacquie! not Jackie
17:57:13 From Jacquie Samples -- Duke to Everyone : That would be ideal, Dennis.  No problem Ann-Marie.
17:57:43 From Laura Daniels to Everyone : Dennis -- mapping can be customized to do that even if it's not the default
17:58:04 From Ann-Marie Breaux to Everyone : Dennis, you can definitely do that in your tenant's map. Not sure if it's worth it to change the default map
17:58:34 From Lloyd Chittenden to Everyone : If the result list includes 4xx and 8xx, the result should display the MARC tag so we can see which is which.
17:58:48 From Dennis Christman to Everyone : Thanks Laura, I think if it can handle that level of logic, then it should work. Anne-Marie, I'm just checking on capabilities of what the mapping can handle, I haven't actually touched that part myself
17:59:03 From Laura Daniels to Everyone : it can definitely handle that level of logic
17:59:04 From Ann-Marie Breaux to Everyone : Anything in Inventory will not show MARC values - The instance and Inventory do not speak MARC
17:59:48 From Laura Daniels to Everyone : (Ann-Marie I am happy to see someone other than me anthropomorphizes Inventory!)
18:02:08 From Jacquie Samples -- Duke to Everyone : It would be best to change Inventory so that it does separate Form/Genre data from Subject data.
18:02:08 From Laura Daniels to Everyone : This is another case where local changes to mapping could be useful -- we *could* choose to map MARC 655 fields to, for example, "Nature of contents"
18:02:09 From Ann-Marie Breaux to Everyone : We put the 655s into Instance subjects because there was not a more specific Instance field to put them in
18:02:54 From Jacquie Samples -- Duke to Everyone : Yes, it was discussed quite a bit at the time, but it didn't happen.
18:02:55 From Ryan Tamares (he/him) to Everyone : +1 Jacquie, Laura
18:02:56 From Ann-Marie Breaux to Everyone : The tricky thing with Nature of content is that it's a list controlled in the settings
18:03:00 From Laura Daniels to Everyone : @Jacquie -- this is exactly the sort of thing I want us to discuss when we talk about Discovery and FOLIO at WolfCon
18:03:23 From Laura Daniels to Everyone : there are elements we don't have in the instance data model that we might decide we need
18:03:31 From Jacquie Samples -- Duke to Everyone : Super!!  I will be attending virtually, but am looking forward to the discussion.  :)
18:05:29 From Laura Daniels to Everyone : Jacquie, what you are saying is exactly why I proposed this topic!
18:06:03 From Jacquie Samples -- Duke to Everyone : I know we have "hive mind" Laura!!  so good to still be on the same page.
18:06:13 From Laura Daniels to Everyone : 🐝
18:07:33 From Ann-Marie Breaux to Everyone : One concern I have is similar to what Jacquie is saying, but sort of opposite. I'm all for reconsidering and making things more granular if necessary, but each adjustment - especially to make things more granular - has substantial work, not only for development, but also for converting a library's existing Instance data to reflect the schema change
18:09:00 From Jenn Colt to Everyone : Which release is the authority lock down planned for?
18:09:04 From Charlotte Whitt to Everyone : Very early in the FOLIO project, here Harry and Vince talked about the Inventory Instance could not have more than 25 data elements
18:09:11 From Jacquie Samples -- Duke to Everyone : I am aware that it is more work, but sadly, if we don't undertake it, our patrons will not be served in the best possible way, Ann-Marie.
18:09:57 From Lloyd Chittenden to Everyone : Seems to me it will only become more work later on.
18:10:03 From Laura Daniels to Everyone : We might have some data elements that are more granular than we need. But I think it's best for us to start with our needs / use cases as we always have.
18:11:07 From f-piscitelli to Everyone : About mapping 655 to Nature of contents--some formats--printed music and maps, for example--have more granular fixed fields to deal with specific kinds of content. SO any proposal to do this will need input from people who deal with those formats.
18:11:40 From Laura Daniels to Everyone : Felicia, I was proposing that as a local decision, not a default mapping.
18:12:13 From f-piscitelli to Everyone : Thanks, Laura. Point taken.
18:13:05 From Laura Daniels to Everyone : we made some custom note fields for music records, though we also find our music catalogers look at the MARC data first anyway 🙂
18:13:27 From f-piscitelli to Everyone : Also, I did not intend all caps. I'm making too many typs!
18:15:09 From Jacquie Samples -- Duke to Everyone : The Option to implement "automatic" in Orchid, right?  Not that is has to be implemented at an institution?
18:15:15 From Ann-Marie Breaux to Everyone : What about fields that have lots of subfields? I'm thinking some of the music composer/uniform titles that may have 10 or 12 subfields in the 7xx
18:17:07 From Natascha Owens (she/her) to Everyone : I already voiced my concerns about having separate boxes for each subfield at the smaller QuickMARC meeting.  I'm not sure how important it is for people to be able to tab between subfields versus other workflows.  I personally am afraid it will become a bit of a nuisance for my own editing habits.
18:17:52 From Jacquie Samples -- Duke to Everyone : Hmm, that does sound bad when there are many subfields.  I was thinking of editing, not creating new records, too.
18:19:40 From Jessica Janecki to Everyone : +1 Natascha
18:20:52 From Charlotte Whitt to Everyone : + 1 Natascha
18:21:15 From Jessica Janecki to Everyone : I don't want "Ease of tabbing" to trump development work on other design issues (especially design issues that places already in production may be experiencing)
18:22:13 From Jacquie Samples -- Duke to Everyone : +1 Jessica, maybe +1,000
18:23:37 From Linda Turney to Everyone : I like the way OCLC in connexion displays linked authority records.  Maybe review how it is done in connexion?
18:23:53 From Jacquie Samples -- Duke to Everyone : That is a good idea, too, Linda.
18:24:03 From Laura Daniels to Everyone : Connexion makes us uncontrol a field to, for example, add or change the $e
18:24:14 From Laura Daniels to Everyone : so it's not quite ideal, though the display is nice
18:24:18 From Jacquie Samples -- Duke to Everyone : True!
18:25:11 From Laura Daniels to Everyone : (a side note, but in OCLC the linkage is apparently actually not based on the identifier, which makes my head want to explode)
18:25:46 From Jacquie Samples -- Duke to Everyone : Laura, that is definitely a mind-blower.
18:26:01 From Lynne Fors to Everyone : 🤯
18:28:57 From Ann-Marie Breaux to Everyone : And to circle back to Jenn's question about import - in Nolana, once users can manually link fields to an authority record, I think it'll be important to do extensive testing of update imports, to ensure that it is/isn't considering the fact that a field is controlled/linked to an authority record.
18:29:45 From Ryan Tamares (he/him) to Everyone : so theoretically, in the future a link could be made to non-MARC-based vocabularies? that's what I'm getting from this explanation
18:30:36 From Laura Daniels to Everyone : that's part of the vision, Ryan: https://folio-org.atlassian.net/wiki/display/MM/Entity+Management+Working+Group
18:30:58 From Ann-Marie Breaux to Everyone : Right now, FOLIO can support MARC Authority records. In the future, the intent is that FOLIO should be able to work with non-MARC authorities within the Entity Management app
18:31:01 From Ryan Tamares (he/him) to Everyone : Thx Laura!
18:31:04 From Laura Daniels to Everyone : there will be an Entity Management discussion at WolfCon (shameless plug for WolfCon)
18:31:43 From Bob Scheier (Holy Cross) to Everyone : Maybe there could a way to toggle display/edit from segmented to free-form editing.
18:32:04 From Jessica Janecki to Everyone : After thinking about this, I don't need separate boxes for unlinked headings.
18:32:47 From Ryan Tamares (he/him) to Everyone : This discussion reminds me of editing in the original OCLC DOS CatMe vs. Connexion
18:32:56 From jeanette kalchik to Everyone : Unsure if I missed it, but if a field gets automatically linked to a record and you later find out it is the wrong person, can you unlink them to edit or would you need to delete the 100 field and add a new?
18:33:12 From Jenn Colt to Everyone : +1 jeanette, was just wondering too
18:33:35 From Jessica Janecki to Everyone : The situation with linked fields looks good as you have demonstrated it (ie, I like being able to see that they are controlled and un-editable)
18:33:36 From Laura Daniels to Everyone : you can unlink
18:34:14 From Jessica Janecki to Everyone : The box situation for unlinked fields would be an impediment to copying/pasting and would require further development to improve.
18:34:31 From Ryan Tamares (he/him) to Everyone : Being able to unlink, make a quick edit, then relink to correct authority would be ideal rather than having to manually re-enter if that's all that's needed
18:34:35 From Lloyd Chittenden to Everyone : It would be fine to have separate boxes only for controlled fields. Tabbing is not that important.
18:34:40 From Natascha Owens (she/her) to Everyone : If we are only using separate boxes for controlled fields that seems reasonable
18:34:40 From Linda Turney to Everyone : +1
18:34:52 From Jessica Janecki to Everyone : Yes, we do still need to be able to copy/paste whole fields or multiple fields within FOLIO
18:34:54 From Lynne Fors to Everyone : +1 to linked fields only
18:35:21 From Jacquie Samples -- Duke to Everyone : In my view, being able to Tab is most useful when writing macros with a third-party tool.
18:35:41 From Alessandro to Everyone : "we do still need to be able to copy/paste whole fields or multiple fields within FOLIO" ... Is this referring to macros?
18:36:04 From Jessica Janecki to Everyone : @Jacquie, since we have the delimiter symbol, macros to add info can just be text strings.
18:36:16 From Laura Daniels to Everyone : copy/paste is manual editing, not necessarily macro-related
18:36:39 From Jacquie Samples -- Duke to Everyone : Getting to the correct portion of the record to add fields can more reliably done with the macros. Just pasting is not what I meant.
18:37:31 From Jessica Janecki to Everyone : Option A
18:37:31 From Ryan Tamares (he/him) to Everyone : +1 Ann-Marie on error message
18:37:42 From Amanda Ros (she/her) to Everyone : agree
18:37:56 From Jacquie Samples -- Duke to Everyone : I vote A.
18:37:59 From Ryan Tamares (he/him) to Everyone : +1 Option A
18:38:03 From Amanda Ros (she/her) to Everyone : A
18:38:29 From Natascha Owens (she/her) to Everyone : Yay...Option A!
18:38:36 From Lloyd Chittenden to Everyone : A, but still need a way to copy the entire field, or various parts of the field.
18:39:51 From Jacquie Samples -- Duke to Everyone : Can we add a hotkey or something to copy whole field?  We have that functionality now … in our ancient system.
18:40:25 From Lynne Fors to Everyone : @Jacquie, does that copy the indicators as well?
18:40:50 From Jenn Colt to Everyone : One thing it might be is that they disappear so you have to be careful where you click when you do the next one
18:40:52 From Jacquie Samples -- Duke to Everyone : Yes, it literally copies the entire MARC field.
18:41:23 From Lynne Fors to Everyone : That is awesome and would be super useful.
18:41:53 From Jessica Janecki to Everyone : AND< you currently can't delete multiple fields FAST.
18:42:01 From Jessica Janecki to Everyone : It's not even a quick click click click
18:42:12 From Jenn Colt to Everyone : a "delete selected" with checkboxes sounds easier maybe
18:42:13 From Jackie Magagnosc to Everyone : Undo and/or saving without closing would be so helpful
18:42:45 From Amanda Ros (she/her) to Everyone : +1 Jenn
18:42:54 From Lynne Fors to Everyone : turning deleted fields into a strike-through before the fields disappear permanently after save is an idea
18:43:22 From Jackie Magagnosc to Everyone : I would Jenn's option in so many places in FOLIO.
18:43:54 From Jessica Janecki to Everyone : YES, we desperately need short cut keys
18:45:04 From Laura Daniels to Everyone : I like the shortcuts to collapse/expand all accordions
18:45:24 From Jessica Janecki to Everyone : As long as you have a short cut, then we can remap our keyboards/mice if needed.
18:46:47 From Ann-Marie Breaux to Everyone : Similar to dollar sign for subfield marker - OK on some keyboards, not others. And not good for Ke$ha
18:47:28 From Charlotte Whitt to Everyone : We can use the need for a PO for Key board short cuts as an example at the PO session at WOLFcon, where we try to recruit new POs
18:47:40 From Ann-Marie Breaux to Everyone : Hmm - similar to the other tenant localizations - for time, numbers, dates, currency
18:47:52 From Laura Daniels to Everyone : +1 Charlotte!
18:48:14 From Jessica Janecki to Everyone : @Ann-Marie in a perfect world we would choose a different subfield delimiter symbol.
18:48:45 From Ann-Marie Breaux to Everyone : In a perfect world, it would be configurable. There is no one subfield delimiter symbol that can be used worldwide
18:49:11 From Jacquie Samples -- Duke to Everyone : @Ann-Marie, good point!
18:49:53 From Jessica Janecki to Everyone : Laura, don't miss your flight!
18:49:57 From Ann-Marie Breaux to Everyone : Good conversation today!