1 / 26

Evergreen Serials: Making it Work For You

Evergreen Serials: Making it Work For You. Dan Wells, Hekman Library (Calvin College). Or…. Bang! Bang! Dan Wells’ Serial Hammer Came Down Upon Their Heads. MFHD. Pronounced " Muffhead “ Stands for M arc F ormat for H oldings D ata A standard primarily for exchanging holdings data

fritz
Download Presentation

Evergreen Serials: Making it Work For You

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Evergreen Serials: Making it Work For You Dan Wells, Hekman Library (Calvin College)

  2. Or…

  3. Bang! Bang! Dan Wells’Serial Hammer Came DownUpon Their Heads

  4. MFHD • Pronounced "Muffhead“ • Stands for Marc Format for Holdings Data • A standard primarily for exchanging holdings data • Not technically limited to serials • Basis of EG serials support due to interchangeability • Of data • Of code

  5. MFHD(cont.) • Serial MFHD basics • Adding a record

  6. MFHD(cont.) • Serial MFHD basics (cont.) • Controlled holdings statement – Field 853 + field 863 • Free-text holdings statement – Field 866

  7. MFHD(cont.) • Serial MFHD basics (cont.) • Corresponding groups for indexes and supplements

  8. EG Serials Through a MFHD Lens • Caption and Pattern = MFHD field 853 • ‘Pattern Code’ = “JSONified” MARC data["2","0","8","1","a","v.","b","no.","u","3","v","r“…

  9. EG Serials Through a MFHD Lens (cont.) • Issuance = simple, uncompressed MFHD field 863 • ‘Label’ is just a label • ‘Holding Code’ = JSONified MARC data • Summaries • Generated Contents = collection of compressed 863s (or 864s or 865s) formatted for display • Textual Contents = simplest form of 866 (or 867 or 868)

  10. Building the Display • An abstraction of an abstraction of an abstraction • Actual serial -> MFHD standard -> EG serials tables -> Serial Virtual Record (SVR) (next)

  11. Building the Display (cont.) Serial Virtual Record Database Tables MFHD

  12. Building the Display (cont.) • Each step is an attempt to normalize and organize the data to better suit our needs • SVR in particular allows: • Simplified logic in display code (e.g. TPAC) • More flexibility to make backend changes without affecting display • Drawback: Bugs can happen at any layer • Data? • MFHD code? • Summary code? • Display code?

  13. Building the Display (cont.) • MFHD vs. MFHD • MFHD data can come from two sources • Serial Record Entry (SRE) - the original, stored as MARCXML • “Code” fields in serial controls • Who wins? ‘Summary Method’ decides! • Add to record entry • Use record entry only • Do not use record entry • Merge with record entry IssuanceMFHD IssuanceMFHD SREMFHD IssuanceMFHD IssuanceMFHD

  14. Building the Display (cont.) • More “Merge” details: • Similar to “Add” • Merging is triggered if ‘Pattern Code’ of Caption and Pattern exactly matches last 853 in Serial Record Entry data • End effect: no false break in generated summary statement

  15. Use Cases • 1. You can’t make any sense of this, and just want to type in some holdings information for display • Create MFHD record • Populate as needed

  16. Use Cases (cont.) • 2. You wish to predict and receive issues, but you want to keep doing your holdings display manually • Setup serial control to receive issues (create subscription/distribution/caption and patterns, etc.) • Create or import a MFHD record with the holdings data you want to display • Link the record to the corresponding distribution • Set ‘Summary Method’ to “Use record entry only”

  17. Use Cases (cont.) • 3. Normal issues need predicting and receiving, but indexes and supplements will be handled manually in MFHD • Setup serial control for normal issues only • Create MFHD record with fields for indexes and supplements (e.g. 868 and 867) • Link MFHD record to matching distribution • Set ‘Summary Method’ to “Add...” (or “Merge...”)

  18. Use Cases (cont.) • 4. You want to predict and receive issues, but you don’t need any holdings information to display (e.g. backup copies for binding) • Setup serial control to receive issues • Make sure your “Receive Unit Template” assigns a non-”OPAC visible” location (or sets “OPAC visible” flag to false) • Create an “empty” (i.e. no holdings) MFHD record • Link MFHD record to matching distribution • Set “Summary Method” to “Use record entry only”

  19. Building the Display (Again) • Use case #5: You have a large number of copies (units) per issuance, the copies circulate, and you don’t need any manual control of holdings display • Solution: Enable option named “OPAC: Use fully compressed serials holdings”

  20. Building the Display (Again) (cont.) • Positives: • Correlates and integrates units (aka items) with unit contents • Provides easy to navigate hierarchy • Drawbacks: • Does not consider Serial Record Entries or their contents • Sidesteps Serial Virtual Records entirely • Challenge: Successful integration of yet another data source in an already crowded logic chain

  21. Changes in 2.4 • Set Serial Item statuses in Serial Control • Useful only for reporting at this point

  22. Changes in 2.4 (cont.) • Alternate Serial Control is now embedded in Serial Control (in place of Subscription editor)

  23. Changes in 2.4 (cont.) • Alternate Serial Control is now embedded in Serial Control (cont.) • Encourages us to acknowledge and deal with small differences • Provides a possible direction for interface consolidation • Comes with some immediate benefits • Serial Control gets a path to routing lists • Alternate Serial Control gets: • ‘Summary Method’ dropdown • Distribution note support

  24. Changes in 2.FUTURE • Not necessarily 2.NEXT • MFHD will continue to be undercarriage, but increasingly hidden • Links to acquisitions, particularly claiming, is high priority • Better and more prevalent display of unit contents is long overdue

  25. Always Reforming • In a 2009 email to a serials developer, I said:“… As things stand, I am under a very tight deadline. Basically I need to have a reasonably functional prediction and claiming interface in place by a week from Friday. …” • His entire response:“Dude. Good luck with that.” • In retrospect, that luck has carried us a long way, and I also look forward to future bouts of starry-eyed enthusiasm from both myself and anyone else who joins the cause

  26. Questions?

More Related