Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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

Status
colourGreen
titleVerified

Status
colourRed
titleHigh

  • Publication frequency
    • Annual, semi-annual, quarterly and monthly.
  • 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
All of the listed patterns can be accommodated by work release with or before Quesnelia.

Status
colourGreen
titleVerified

Status
colourYellow
titleMedium

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


Status
colourGreen
titleVerified

Status
colourYellow
titleMedium

  • 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).
Allowing multiple serial records per receiving title. This will allow you to have multiple patterns generating pieces per receiving records

Status
colourGreen
titleVerified

Status
colourYellow
titleMedium

CombinationsOS add detail of what will be supported

Status
colourRed
titleNotcovered

Status
colourBlueYellow
titleLowMedium

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.


Status
colourGreen
titleVerified

Status
colourYellow
titleMedium

  • 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


Status
colourGrey
titleOrder req

Status
colourYellow
titleMedium

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.

Status
colourGreen
titleVerified

Status
colourRed
titleHigh

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:

  • 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

Status
colourRed
titleNotcovered

Status
colourGrey
titleTBD

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


Status
colourGrey
titleOrder req

Status
colourRed
titleHigh

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

Status
colourGrey
titleOrder req

Status
colourRed
titleHigh

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

Status
colourGreen
titleVerified

Status
colourRed
titleHigh

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


Status
colourRed
titleNotcovered
 

Status
colourGrey
titleTBD

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


Status
colourGrey
titleOrder req

Status
colourYellow
titleMedium

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


Status
colourGrey
titleOrder req

Status
colourYellow
titleMedium

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


Status
colourGrey
titleOrder req

Status
colourYellow
titleMedium

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


Status
colourRed
titleNotcovered

Status
colourGrey
titleTBD

Migration of Patterns from Voyager to FOLIO.

  • The number probably is close to 3400. 



Status
colourGreen
titleVerified

Status
colourBlue
titleLow

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



Status
colourGreen
titleVerified

Status
colourBlue
titleLow

Enumeration supporting non-arabic numbering



Status
colourRed
titleNotcovered

Status
colourGrey
titleTBD

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 v. 185, no. 19 (2023 Oct. 2/15)  - indicating that it covers the 2 week period between 2nd October and 15th October.

As it stands we'd be able to generate a label like v. 185, no. 19 (2023 Oct. 2)  but adding the 'end date' (in this case /15) may not be in our first release - although we don't see this as a big step and it's not going to be that hard to add it, it's going to be lower priority for us. I've created a story to cover this scenario 

Jira Legacy
serverSystem Jira
serverId01505d01-b853-3c2e-90f1-ee9b165564fc
keyMODSER-11

...

QuestionStatusResolutionRemarks
What is your ideal regarding how data would be populated in the Piece record for use in check-in etc. 

Status
colourGreen
titleClosed


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? 

Status
colourGreen
titleClosed


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?

Status
colourGreen
titleClosed


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")

Status
colourGreen
titleClosed


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?

Status
colourGreen
titleClosed



In the Voyager data what do the numeric values in the CHRON1 - CHRON4 fields translate to?

Status
colourGreen
titleClosed


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.

...