Problem
Serials module will define a custom label for each pieces that could be quite complex. Many levels of enumeration etc...and the field that was intended to be used for this purpose is not carried over to Inventory.
Additional feilds in the piece and item records can not accommodate all possible data from serial label. Item record also cannot accommodate this detail.
Item record doesn't appear to have an equivalent field for 'label"
label data must be made available to discover system.
Serials module allows the user to describe the material the library is expecting. To build a custom label based on that detail. That label is a piece in the receiving application.
Owen Stephens 8:08 AM
The detail in this context is essentially different aspects of enumeration and chronology. The MARC standard allows 6 levels of enumeration and two alternative enumerations and chronologies. Although we aren’t implementing the MARC standard directly for Serials in Folio, we are supporting an equivalent level of enumeration and chronology
Dennis: Our intention was to initially to add that label to the caption field in the piece record. However it is not created over into the item record when the item record is created in the receiving app. Item record has similar data points, but not ideally used for that purpose.
Owen Stephens 8:10 AM
Typically we expect there to be 2 levels of enumeration (e.g. volume & issue) and one chronology (a date) - but we know there are examples that are more complex. This label data does need to end up needs to end up in receiving. Likewise in inventory, when they look at the book that has the label, they should see the same data. There is more data there than can be captured in receiving or in inventory.
Laura Daniels 8:11 AM
is it also true that there is not necessarily a one to one correspondence between piece and item?
Owen Stephens 8:11 AM
So the type of “label” we are talking about might look like: “Volume 1 Issue 1, Monday 1st January 2024”
scolglaz 8:11 AM
@Owen what about for Chron: season rather than actual date, so like Year + Season (represented by a standardized number or some such)
scolglaz 8:14 AM
Or, I suppose, not just number, but like word, like Spring, etc
Dennis: We have been evaluating how to get all of the information downstream. Need a description of the thing being generated. The patterns are generating piece records. There are a lot of possibilities, working on something for the Q release.
Owen Stephens 8:16 AM
Yes exactly -we call this “textual enumeration” which is slightly different, but you’ll be able to use predefined lists of values (and you’ll be able to add and edit lists as you want) such as “Spring, Summer, Fall, Winter” or “Printemps, Eté, L’autumn, Hiver” etc
Dennis: being future focused, be more appropriate to add this data to the caption feild.
From there, add a field to the enumeration data accordion. Add a single field for the data and have that feild be considered by the effective call number. It is then available in MARC format, and get the data all the way to the discovery program .
Proposed short term solution:
Populate caption field in peice record with label from serials app
add a 'label' field to the item schema in the enumeration accordion and populate it with value fro piece caption field on create or edit of piece record
Include item "Label" value in "effective call number"
Value can be exported via MARC as item - effective call number.
Value can be exported via edge-rtac as Item - effective call number?
Owen Stephens 8:17 AM
We also support ordinal numbering and roman numerals out of the box
Julie: If there is an effective call in the item record, does it get combined with the call # for the full title, or does it replace it?
Dennis: I would imagine different platforms will do different things with that data.
Laura: Right now, the effective call # is an item element, if there is a call # in the item, it ignores what is in the holdings. If there is no call number in the item, then it using the holdings call number.
Jennifer Eustis 8:22 AM
In many of our records, we have this information in enumeration, volume and/or chronology fields already. What will happen if all of these fields and the label field has data? Do you know how having information in the label field will affect print labeling for instance or being able to sort in discovery?
Jen Bolmarcich (Five Colleges/Hampshire) 8:23 AM
The item effective call number also appends the item record copy number/enum/chron/vol
Joe Reimers (EBSCO) 8:24 AM
@Jennifer Eustis I don't see that this will have any impact on label printing; the primary concern is transmitting this information to Discovery
Jennifer Eustis 8:24 AM
In our EDS discovery, if there is information in enumeration and volume, only the enumeration data displays. Will something similar happen if there is information in the label field? For instance, if there is information in the label, enumeration, and volume, then only the label displays
Johanna Radding (she/her) 8:24 AM
And if there is data in chronology it, edge rtac displays that in our discovery layer because item data does not come from the MARC but from RTAC and it ignores anything in the volume field and does not display that. So a Label field would also need to be able to be displayed in the RTAC instead of Chron?
Jen Bolmarcich (Five Colleges/Hampshire) 8:23 AM
The item effective call number also appends the item record copy number/enum/chron/vol
Dennis: I think adding a field is the more responsible thing to do since it wont disturb existing workflows.
scolglaz 8:26 AM
But then going forward we would have info in different places: for new things in Label, and for old things in the other fields--how will that work
Joanna Cerro (Cornell) 8:26 AM
On the discovery level, is it anticipated that multiple issues will appear on several lines? The nice thing about manually adding issues to holdings in the Receiving history is that we can consolidate issues on a single line (ex. v.1, no.1-3 (2024 Jan.-Mar.).
Laura Daniels 8:26 AM
Related to Jennifer's questions above, though, would this allow the item enum/chron/volume data to be out of sync with the caption label, e.g., if one is changed but the other is not?
scolglaz 8:27 AM
What about migrated Items that have NO pieces?
Laura Daniels 8:30 AM
what goes in enum/chron/volume fields is library defined
scolglaz 8:31 AM
And other institutions like 5C libraries have used Enum, Chron, AND Volume fields in Items … and we have migrated Millions of Items … so how will this mix of info in different fields that create Effective Call Numbers … how will we get this into the new Label field now
scolglaz 8:32 AM
OR if no enum or chron info then volume is pulled for eff call number
Considerations:
1- will this significantly limit filtering options in discover in the short term?
2 - Will this impact the use of existing fields?
3 - How can we make it possible to migrate data from this solution to the mre desirable long term solution?
Owen Stephens 8:34 AM
I think the long term solution discussion needs to include what data migration strategies will be needed
Owen Stephens 8:35 AM
Given what I’ve heard from libraries about how they are using the various fields in Inventory and receiving right now, there is no situation where some libraries don’t need to do data migration - because there is no single standard way in which these fields are currently used
scolglaz 8:36 AM
And how will this effect sorting Items in Inventory??
Laura: Is it possible to update information in one place and not the other, and now we have different information in different places? We then have to figure out which one is correct?
Jennifer Eustis 8:41 AM
I find it confusing to have 2 different field names. Does anyone know what year, capture is for?
scolglaz 8:41 AM
Whatever it is called should be the same in both places
Julie: Data in one field in one app being transmitted to another field in another app, just make sure the field is the same name in both apps. It would be really helpful to know which fields are going to be transmitted to receiving in inventory.
Lisa Smith, Mich State 8:43 AM
Piece label?
Laura Daniels 8:43 AM
"Caption" has a different meaning in the MARC holdings format
Laura Daniels 8:44 AM
https://www.loc.gov/marc/holdings/hd853855.html
Owen Stephens 8:44 AM
I’ve had this feedback about the use of the term Caption
Beverly Geckle 8:44 AM
This is what I was thinking about also. A caption field would not have the actual value. Caption field would have v. for volume but not the actual volume number
scolglaz 8:44 AM
+1 to Julie about what gets transmitted and what not
Yan Yu 8:44 AM
Why Issue 1 (January 2024) is under Caption, Not issue 1 under Neum. and January 2024 under Chron.?
Joanna Cerro (Cornell) 8:44 AM
Label to me implies something that will be printed out
Owen Stephens 8:45 AM
What would you call the information printed on the serial issue?
scolglaz 8:45 AM
Comment shows in Holdings!! I use it!
Owen Stephens 8:46 AM
The challenge here is it splits the labelling of the issue into 2 parts - which means you can’t store a single string as printed on the actual physical issue
The feedback we’ve had around serials strongly suggests the need for a single readable label, as well as the more granular issue number/date information
scolglaz 8:48 AM
But it impacts more than just this workflow at that moment in time, but then also how the Items function in Inventory for the long term, in relation to one another, as well as re: whatever Discover layer is in play etc
Dennis: In the serials application you have a more complex than just enumeration chron vol.... So how in the long term should we be approaching making this data available...
Owen Stephens 8:48 AM
I believe in Aleph they use “Description” to hold this string
Dennis: Can we all agree to use the word 'description' instead of 'caption'?
Laura: I appreciate that you are taking the time to think about naming. However, in Inventory and with cataloging 'description' would be confusing to use it instead of 'caption'.
scolglaz 8:52 AM
Item Descriotion
Lisa Smith, Mich State 8:52 AM
Piece details?
Joe Reimers (EBSCO) 8:53 AM
Display summary?
Scott Stangroom 8:53 AM
Description is used in FOLIO invoices, possibly also elsewhere? Rather not use that word
Julie Stauffer’s iPad 8:53 AM
I liked “piece label” which was suggested earlier
Owen Stephens 8:54 AM
Piece label would seem slightly at odds with using the same terminology in the different apps. Once the thing is received it’s an Item not a Piece?
scolglaz 8:54 AM
But if we want it to be named the same in both places, then maybe Piece is not so good but better would be Item
Laura Daniels 8:55 AM
<sarcasm> RDA would call it: item piece identifier label of caption </sarcasm>
Julie Stauffer’s iPad 8:55 AM
OK - but not all serial pieces become items
Lisa Smith, Mich State 8:55 AM
Issue label?
scolglaz 8:55 AM
And then the label would also work for migrated things. Issue is a problem because not all serials have issues
Owen Stephens 8:56 AM
In Voyager they use “Issue identification” (at least on the Serials side)
Here is a link to the document https://miro.com/app/board/uXjVN_C3DbA=/?share_link_id=377343440966
Dennis: My takeaway, No one has an issue with our short term solution. Adding an additional field to inventory might be a reasonable way to manage this in the short term. In future meetings we will define how we plan to get from here to where we ultimately want to be with this data.
