Serials Publication Patterns

• Publication frequency
  • Annual, semi-annual, quarterly and monthly.
    • Monthly except the July issue is combined
    • For annual you might have enum and chronology or just one or the other (Lots of variation)
    • In general, we use the frequencies found here https://www.oclc.org/bibformats/en/fixedfield/freq.html
• This is the table from Voyager:
  • FREQUENCY_CODE    FREQUENCY_DESC    FREQ_INCREMENT    FREQ_CALC_TYPE
  • a    Annual    1    y
  • b    Bimonthly    2    m
  • c    Semiweekly    3    d
  • d    Daily    1    d
  • e    Biweekly    14    d
  • f    Semiannual    6    m
  • g    Biennial    2    y
  • h    Triennial    3    y
  • i    Three times a week    2    d
  • j    Three times a month    10    d
  • m    Monthly    1    m
  • q    Quarterly    3    m
  • s    Semimonthly    14    d
  • t    Three times a year    4    m
  • w   Weekly    7    d
  • z    Other (Would use for a decennial or quadrennial)
• we have ~120 Complex patterns, and 3400+ Regular patterns

Omissions (and especially any titles where the pattern defines both omissions and combinations together)

• • • There are of course supplemental issues as well.
    • Sometimes the last issue of the year is a compendium of all other issues. In this case it is generally cataloged alongside the other issues. However, these require a seperate pattern as they could be annual or quarterly etc.

OS add detail of what will be supported

• Many of the supplements will have their own patterns. They could be an annual etc. but voyager allows us to have more than one component (Multiple patterns).

Ommission AND combinations

• More common for Newspapers and other things that we don't actually check-in. It does happen but it is less common.
  
  • Much more common in foreign periodicals where all of a sudden they combine three issues together, for example.
  • These are generally deviations from the pattern rather than actually consistent behavior within the defined pattern.

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.

• Enumeration rules (the way that issues are labelled with volume issue or other systems of numbering)
  • It varies but we prefer to use what is on the piece. If it says año on the piece we try to use that because that is likely how the patron will be requesting it.
  • They manage roughly 3500 patterns and of those only ~100 go to a third level. This is not because they don't have things that might require it but it becomes too labor-intensive to manage and that is because they have not implemented the MARC 21 standard. Even with that after a while, it just becomes too difficult to predict.

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

It may be important to understand how the orders for these are constructed, but generally the serials module first release will support prediction for:

• Multiple serials records and thus multiple patterns for a single Purchase Order Line / Receiving Title
• The ability for a single serials records publication pattern to generating multiple receiving pieces for a single Purchase Order Line / Receiving Title for each predicted piece - for situations where the pattern is the same but there are multiple locations or formats being received

Holding records should be fully updatable in regard to issue receipt, ability to collapse / expand. 

Does this actually include the ability to "Merge" items?

• Easier to see that you have volume 1 - 50 for a previous year. 
• You only care about individual issues in the current year and/or if a given volume is incomplete
• User is able to add individual issues to an existing pattern

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

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?

• Don't usually check in newspapers but Eg. you could have a newspaper daily that combines more than one daily into a single issue.
• Generally, the things we can and can't do involve combining a regular combination of issues. 
• When something regularly skips a specific week or day

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

Seen as the responsibility of Receiving

OS to put in details on permissions in serials

TBD

see also Generate claim information to share with vendor

https://miro.com/app/board/uXjVPTZgeB4=/?share_link_id=640643927693

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.

• The number probably is close to 3400. 

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

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. 

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.