Meeting ID: 954 7939 2806 Passcode: 965674 One tap mobile +13126266799,,95479392806#,,,,,,0#,,965674# US (Chicago) +19292056099,,95479392806#,,,,,,0#,,965674# US (New York)
Dial by your location +1 312 626 6799 US (Chicago) +1 929 205 6099 US (New York) +1 301 715 8592 US (Germantown) +1 346 248 7799 US (Houston) +1 669 900 6833 US (San Jose) +1 253 215 8782 US (Tacoma) 877 853 5257 US Toll-free 888 475 4499 US Toll-free Meeting ID: 954 7939 2806 Passcode: 965674 Find your local number: https://lyrasis.zoom.us/u/ahUXQvjfH
This should be pretty easy to do, but do we want to do it? Mine are organized in priority order in our instance, but I only have a handful.
We passed this one last meeting, so yes! It seems like a good idea.
This seems like a good way to make data cleanup easier--in addition to imports, most of the errors my students make is related to mis-categorizing subjects and agents.
Recommend: pass (similar to #3) Add ability to create MARC record from accession record to retain accession record details (provenance) and avoid duplicate work
Recommend: pass (similar to #2) Question: Are there any other accession export options that would be helpful?
This was approved for implementation at a minor priority one year ago, with the agreement that the priority should be increased once SAA Council approved the new required element. This has now happened, so I recommend increasing this to critical.
We reviewed this ticket in October and decided that it needed a specification. This has now been written. The customization aspects are clearly scoped and make sense, but I’m not convinced there’s a reason to change the default order. I recommend passing as a major priority, possibly with the changes to the default order removed.
This ticket wants to make have agents and subjects inherit upwards, so that an agent linked at an archival object record would appear in the resource record. I strongly oppose this idea, as it would result in bloated and unhelpful collection level records and promote poor metadata practice.
This ticket is looking to have different options for controlled value lists for individual repositories. While it is important for controlled values to be shared among all repositories, having the ability to customize by repository which values actually appear in drop downs seems useful.
Dan will investigate (critical issue)
Pass - major
Close - Will not do - too repository specific
Pass - other supression work needs to be accomplished beforehand