We've currently got a list of around 3500 prediction patterns they supplied after our first meeting, but it's lacking the serial title - While I can work with that it would be great to have the serial titles as well. I have the pattern ID but could you provide a list of serial titles and associated pattern IDs? It will help clarify what we're dealing with.
...
Requirement | Status | Priority | Use cases | Comments from Serials Team | ||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
| All of the listed patterns can be accommodated by work release with or before Quesnelia. | |||||||||||||||||||||||||
|
| Omissions (and especially any titles where the pattern defines both omissions and combinations together)
| OS add detail of what will be supported | |||||||||||||||||||||||||
|
|
| Allowing multiple serial records per receiving title. This will allow you to have multiple patterns generating pieces per receiving records | |||||||||||||||||||||||||
|
| Combinations | OS add detail of what will be supported | |||||||||||||||||||||||||
|
| Ommission AND combinations
| By manually removing the piece you could ultimately workaround this functionality in the short term. Situations where there is a deviation from the pattern (such as "all of a sudden they combine three issues together") aren't covered by the publication patterns (as they are not known or expected at the point where issues are predicted) but would rather be resolved by editing the receiving pieces on receipt - adding details to combined pieces and deleting any pieces that will not be received because of omission or combination. | |||||||||||||||||||||||||
|
|
| Ability to add multiple levels of enumeration (at least 2 levels will be supported initially, and likely to be more) We also expect to support multiple sets of enumeration for situations where there are different ways in which the pieces of a single serial are enumerated (e.g. a single serial might issue both continuous numbering and volume/issue numbering with a repeating issue pattern such as 1-12 etc.) OS to add details on the labelling for "If it says año on the piece we try to use that because that is likely how the patron will be requesting it." requirement | |||||||||||||||||||||||||
|
| The Library receives thousands of items via Approval Plan that need to be received and paid for before bib records can be created. Generic POs called Expedited Processing Records (EPR POs - "Bag of Books", "Sack of Serials") citing specific vendors or regions and format of material are created and reused throughout the fiscal year to use in receiving and invoicing these items. These PO line items need to remain available for invoicing on a continuing basis and may need to be used with multiple vendors. | Not in scope for current Serials work. | |||||||||||||||||||||||||
|
| Check-in needs to happen for regular serials as wells as for supplements, indexes, fascicles, other sub-parts (especially Law), and many formats, including print, online, microfilm, pdf… | It may be important to understand how the orders for these are constructed, but generally the serials module first release will support prediction for:
| |||||||||||||||||||||||||
|
| Holding records should be fully updatable in regard to issue receipt, ability to collapse / expand. Does this actually include the ability to "Merge" items?
When checking in a weekly and the previous year is complete you and the patron likely don't need to see the individual issues of the previous year. So you'd like it to default as "collapsed" | No work planned in the Serials module for this in the first release. Once an issue has been received it will interact with inventory as currently supported - there should be nothing different/special about receiving pieces created via the serials module. It is not impossible that work could be done in Serials to manipulate holdings in Inventory, although also not clear this is the most appropriate approach. However it will not be part of an initial release Serials team will need to ensure we allow the user to specify all the relevant fields for populating the receiving piece | |||||||||||||||||||||||||
|
| Check-in history necessary for legal audit purposes needs to be associated with the PO and should be able to be reported on. | Seen as the responsibility of Receiving | |||||||||||||||||||||||||
|
| Check in history must be retained year over year and should be associated with the bib or holdings record, as well as the PO and vendor records (important for Duplicate Materials Exchange Program) as appropriate, especially when there are multiple POs for a given title with different acq source workflows (see 2.6.1.4) | Seen as the responsibility of Receiving | |||||||||||||||||||||||||
|
| The Library may receive multiple copies of a serial, via exchange, via subscription, via membership, via Transfer, via CO, or other non-purchase methods, etc.; staff need a way to associate the check in with the correct PO. | While a serials record and pattern do not require a Purchase Order Line / Receiving Title to exist to predict pieces, our understanding is that a Purchase Order Line / Receiving Title are required in order to create a receiving piece. The result of this is, from our perspective, as long as a Purchase Order Line / Receiving Title exists for the serial, it will be possible to associate check-in with the correct PO, as each receiving piece relates to a Purchase Order Line / Receiving Title | |||||||||||||||||||||||||
|
| The Library needs full implementation of MARC Holdings Standards to support publication patterns in all vernaculars. One title can have several types of supplemental materials, each with different frequencies. Is it that they want to be able to export in MARC to another system? Is it that they want to be able to import in MARC from another system? Currently can not import patterns into voyager. Believe there was a program some years ago that was used to import patterns from Harvard into OCLC and a lot of the concer libraries began updating those patterns. These are 890s and 891s on the MARC records. The vision was to be able to import these to be able to create patterns more efficiently but this doesn't seem that this project is to active anymore. Is it that there are specific things that can be captured in MARC that you want to be able to do?
This might be a useful reference https://www.loc.gov/aba/pcc/conser/conserhold/guidelines6.html | This needs some further clarification as to what "full implementation of MARC Holdings Standards to support publication patterns in all vernaculars" means. During the development of the Serials module publication pattern functionality the development team have extensively referred to the MARC 21 Format for Holdings Data documentation, specifically https://www.loc.gov/marc/holdings/hd853855.html Furthermore the designs until recently have assumed that it should be possible to migrate data from the Aleph LMS 853/853X fields into the Serials module data format. Since Duke have now decided not to implement Folio this requirement is no longer at the top of the development teams priority list but decisions made before this change very much inform the current implementation. However, the approach taken by the development team is that the publication patterns in Folio should ultimately be able to cover all the possibilities that can be expressed in the MARC 21 Format for Holdings Data 853 field but not to be a direct representation of that data. This has resulted in a design that in some areas can go further that the MARC Format for Holdings data, while falling short in some other areas in the first release (notably support for omissions and combinations in a single publication pattern). Our expectation is that eventually it will be possible to translate any MARC 21 Format for Holdings Data 853 field data into the Folio Serial publication pattern format (although it is not clear this will be available in the first release) but not necessarily vice versa - this would need further analysis and discussion. Finally in the initial release there is unlikely to be a strong integration between Serials and Inventory (if any - the major focus is integration between Serials and Orders/Receiving) which means that data loaded into Inventory (such as holdings records) is unlikely to be used by Serials in the first release | |||||||||||||||||||||||||
|
| Check in should be limited by role and permissions so that only authorized staff in the division associated with the purchase can check in a given serial (order site location and custodial location staff). | Seen as the responsibility of Receiving OS to put in details on permissions in serials | |||||||||||||||||||||||||
|
| This functionality is needed for claiming. Production of reports is needed for check-in, serial claims, missing/damaged issues, predicative issues, inactivity. Reports should be customizable to include parameters for types of PO, specific vendors, location, types of material, etc. | TBD see also Generate claim information to share with vendor https://miro.com/app/board/uXjVPTZgeB4=/?share_link_id=640643927693 | |||||||||||||||||||||||||
|
| Claiming functionality needs to be robust and associated with predictive publication patterns. This would apply to purchase, and non-purchase workflows (including Transfer, CO - need to be able to turn off considering CO workflow receipt times -, CIP) | TBD see also Generate claim information to share with vendor https://miro.com/app/board/uXjVPTZgeB4=/?share_link_id=640643927693 | |||||||||||||||||||||||||
|
| Migration of Patterns from Voyager to FOLIO.
| ||||||||||||||||||||||||||
|
| Labeling language selection for caption generation of serial. Allowing user to select a language for display of the individual elements of the caption. For a limited range of languages. CRS is only using english Other groups use the closest available script or numeric as they work with everything | ||||||||||||||||||||||||||
|
| Enumeration supporting non-arabic numbering | ||||||||||||||||||||||||||
|
| Adding end date to label. Eg. Aviation week & space technology. ISSN 0005-2175 is published every two weeks, but the issues are labelled with 2 dates for the start/end of the period covered by the publication. So e.g. the publication on Monday 2nd October 2023 is labelled | As it stands we'd be able to generate a label like |
...
Question | Status | Resolution | Remarks | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
What is your ideal regarding how data would be populated in the Piece record for use in check-in etc. |
| We do not see a benefit to capturing this in a single field. Breaking it apart into enumeration and chronology will allow more searching and filtering options. | |||||||||
How would you expect Vol 1 Issue 2 etc to display internally and in discovery? |
| For example the first issue may not have enumeration and we will need to improvise it. Some will have enum but no Chronology. Also some time the Enum appears on cover and Chron inside etc. Possible that the only enumeration is the year as there is no Chron. Could be quarterly as well. | |||||||||
How would you search or filter with this data during common workflows? |
| Generally, users are searching for the "Parent" record. Ie. they are searching for the Title or the purchase order. Pieces are sorted by enumeration or chronology. Generally, browsing is associated with verification that all issues are accounted for. | |||||||||
Can you supply some more detail on what you qualify as "complex patterns" (You ref "~120 Complex patterns") |
| For Law it is the levels of enumeration that put them in this category. 3 or more is generally the cutoff. Also has to do with the limitations of Voyager. Things are put in this category when they require something voyager can not do because it does not support MARC 21 Holdings format | |||||||||
In the Voyager data each level of enumeration (2-6) has a field like "LVL_NUM_CONT". What does this field indicate? |
| ||||||||||
In the Voyager data what do the numeric values in the CHRON1 - CHRON4 fields translate to? |
| These values do map to year, month, day, season etc. and they will share a key as an additional tab in the spreadsheet. Map not just as 1 = year, but also based on language e.g. 2 = months (English) 17 = months (German) etc. |
...