- records. In some cases, kind of happens the other way around.
- There are a variety of use cases that support different apps, so data needed to be in each othe apps.
- With Serials, increasing the amount of detail.
- Maybe not just as simple as the data should only live in one place, but you should be able to get it from somewhere, because maybe you only want to use one of the apps.
|
|
| Dennis | - ~ :45 - For those using receiving and item records and having information populate in discovery, are these fields in the item record sufficient? (Enumeration, chronology, volume, year, caption)
- Beverly - Accustomed to MARC format, where there is a caption and a value. Ended up putting everything in the volume field (partly because of migration). For bound volumes, all a string in the volume field. Didn't come over well, suppressed all the items for serials titles. For not serials, they do display, but it is much more straightforward because they do not have the other information.
- Julie - In our item records, put everything in the enumeration (distinctive information) - regardless of whether monograph or serial. Part of it had to do with migration and part of it where existing data lived and how it gets picked up for discovery. Unusual case in that not using receiving for serials
- Owen - We know that people have made different decisions about how to use these fields. For medium to longterm, need to consider what the migration path looks like. Will be important part for those who have already implemented.
- Beverly - Wanted to clarify that what I was describing is item records for bound volumes. For issues, came up with a system of editing the
|