260 likes | 399 Views
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
E N D
Evergreen Serials: Making it Work For You Dan Wells, Hekman Library (Calvin College)
Bang! Bang! Dan Wells’Serial Hammer Came DownUpon Their Heads
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
MFHD(cont.) • Serial MFHD basics • Adding a record
MFHD(cont.) • Serial MFHD basics (cont.) • Controlled holdings statement – Field 853 + field 863 • Free-text holdings statement – Field 866
MFHD(cont.) • Serial MFHD basics (cont.) • Corresponding groups for indexes and supplements
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“…
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)
Building the Display • An abstraction of an abstraction of an abstraction • Actual serial -> MFHD standard -> EG serials tables -> Serial Virtual Record (SVR) (next)
Building the Display (cont.) Serial Virtual Record Database Tables MFHD
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?
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
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
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
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”
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...”)
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”
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”
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
Changes in 2.4 • Set Serial Item statuses in Serial Control • Useful only for reporting at this point
Changes in 2.4 (cont.) • Alternate Serial Control is now embedded in Serial Control (in place of Subscription editor)
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
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
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