In a piece of CRUSHINGLY BAD news, Confluence is not smart enough for existing links to persist. Do we want to: a) break all links and move stuff, b) start over clean in the new year?
Implementers Directory (no updates)
TOPICS
Serials: The App (Owen)
Serials: The Situation
How do libraries do serials now?
Biola processes (Chuck/Heather/John)
Current gaps in Biola's Serials work:
No efficient way to do public display of most recent issue received
Binding
Title-level pop up or comment at point of receiving for special handling
Given what is coming, what can libraries do to prepare? Are current processes creating extra work for the future? Is current work redundant?
For others who are processing serials:
Do you think we could be doing something more efficiently?
Are we missing something that we should be doing?
Closing
Any actions or follow through?
Notes
Time
Topic
Notes
5:30
Chit Chat
Weather, nervously awaiting the arrival of Owen Stephens.
7:30
Housekeeping
Outline of upcoming sessions–we actually pushed everything back one week at the end of this meeting, so this is not accurate.
Ongoing agenda items: please be our convener, new wiki space, implementers directory
10:00
Serials!
Owen gives us a recap of his WOLFcon presentation and gives us an update.
14:00
History/Background of the Serials App
Work on the Serials app started with a couple of organizations (Duke and GBV). Duke and GBV funded all of the work that has been completed so far. However, the work was planned with the community, to serve the needs of the whole community–the functionality available is not highly specific to these institutions and will hopefully be useful to all.
Serials in FOLIO can be thought of as anything that has an ongoing order type. That includes subscriptions, standing orders, and other cases where an order that is open over a period of time and receives several different resources through its lifespan. The current orders module had some but not all functionality that libraries need to support print serials processes.
Knowledge Integration (K-Int) were engaged to do this work.
The initial development was guided by Duke and GBV, but in the medium term, Serials functionality will belong to the Acquisitions SIG, though there is some overlap with the Metadata Management SIG.
18:15
Initial Gap Analysis
We look at Owen's initial gap analysis diagram.
The first release has focused on adding support for prediction patterns to FOLIO.
Other areas identified including binding and claiming. These were not selected for the initial release. There is work happening on these aspects of Serials in the community as well.
21:40
Current Work
There will be new "Serial" record that will hold information about the serial, sufficient for users to find and manage the relevant records
Serials records will hold publication pattern information required to automatically generate a list of expected issues for a year (scheduled pieces)
Scheduled pieces will be used to generate receiving pieces
Receiving will be done using the existing receiving application
The Serials module is currently available in Snapshot! You can go look at it yourself!
You can create a Serial record. That record can be linked to a purchase order.
You can create a publication pattern
You can add exceptions (omissions, combinations) to the publication pattern.
There are significant complexities around these patterns specific to how serials publications work. The Serials app was designed to address these compelexities.
28:30
Serials App Demo!
Owen demonstrates the Serials app functionality in Snapshot.
First we go to the Serials app.
We create a new serial record.
In our serial record, we select an order line to link it to.
You can add notes if desired. Then save.
The serials app has searching capabilities.
Owen notes that multiple serials records can go to the same order line. This is both for packages and single journals with separate publication patterns (30:18)
We add a publication pattern. We look at the options for publication patterns. (31:32)
32:23
Questions
Stephanie asks: "can you confirm that the PO would be the larger level like membership or package if there is more than one journal or serial and the PO lines would be the individual titles."
Owen says: "In theory, depending on how you've configured the system, you could have one purchase order, multiple purchase order lines, and each one of those purchase order lines could be for multiple titles or one or more titles."
We also wonder about packages in relation to Serials. Owen says, "If there was a package within the purchase order line, then when you linked in the purchase order line to the serial record, you would get asked which title you wanted to, you were creating the serial record for out of the list of titles that belonged to that purchase order line."
How does the Serials app connect to orders and receiving? (34:49) We look at this in Snapshot.
Does each Serial record relate to one title?
Owen says: "Typically I'd expect there to be a single serial record for a single title, but you might have situations where for a single title you have multiple serial records because you might have one for the supplement and one for the the main issues. The reason that you might end up with two in that situation is because we limit the number of active prediction patterns for a single serial to one. You can have multiple serial prediction patterns defined for a single serial but only one active one at a time." This is to manage the fact that prediction plans change over time, not to accommodate features like supplements.
Could you have said multiple serial records for different locations?
If you would create one order per location, then you would also create multiple serial records: one per order, or however many you needed per order. For example, if you had an order for the law library copy and an order for the main library copy, you would also need to have a serial record for the law library copy and a serial record for the main library copy. If, however, you create a single order line with two copies, then you would only need one serial record in that situation.
38:30
Demo Continues!
We look at publication patterns. This generates a list of dates, which you can preview.
42:55
Coming Next
What's coming next is generating the issues and chronology. We look at the latest work on this, exploring the various options (44:30). There will be options such as seasons and roman numerals. This will also include labeling and templating features. The actual pieces in receiving are also not yet available. Coming functionality is for the Quesnelia release.
51:07
What should libraries do to prepare?
Is there anything that libraries need to be doing in order to take advantage of this coming functionality? Is there anything implementing libraries should keep in mind as they map their data?
Nothing specific. Pay special attention to how you are setting up your acquisitions so that it's clear how Serials should work with regards to multiple locations/libraries, or with packages. The app was designed to support multiple workflows–it should not be driving choices about how a library sets up Acquisitions.
There will be some challenges in the initial implementation with regards to how caption, enumeration, and chronology are populated in Receiving. Different libraries use these fields different ways–consistency may be challenging at first.
1:01:27
Current Gaps at Biola
Biola wonders: what is the public display effect going to be?
Heather notes that this functionality that was demoed will save a lot of time.
We decide to pause and pick up our questions next week.