| | Dennis | - 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.
- Dennis: We rely on the effective call # to make sure the information make it to the discover layer.
- 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? - Laura Daniels 8:27 AM
by "changed" I mean edited by a user
- 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?
- Filtering is also a consideration in receiving.
- 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??- scolglaz 8:37 AM
Esp. where we have a mix of FOLIO native and migrated Items. Sorting in Inventory of Items is very important for Serial and Periodical work and overall always also from Access/Circulation … so having a mixture of data fields in place or how they are used can be very problematic
- 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?
- Dennis: Currently data flow from receiving to inventory is a one way trip. There is a feature for implementing messaging the other way.
- 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?- Joanna Cerro (Cornell) 8:46 AM
Caption I suppose.
- 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- (several people agreed with this)
- 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.
|