Speaking the Same Language
Serials Standards and e-Resource
Data Interactions
Diane Hillmann
Cornell University
Standards Evolution
• Normal development trajectory—
where do we fit?
• What current standards are
relevant to our emerging needs?
• What are the real problems we’re
trying to solve?
Development Learning Curve
•
•
•
•
•
Simple ---> Complex
Monographs-----> Serials
Human ----> Machine
One-at-a-time ----> Batch
Single use ----> Re-Use
MARC 21 Holdings
• Represents 20 years of experience with
publications
• Tested approach to encoding and
exchanging data
• Growing installed base of publication
patterns
• Solid infrastructure of sharing and
collaboration
So why hasn’t MARC Holdings
been adopted outside libraries?
• “It’s too complicated--we need
something simpler”
• Too specific to libraries to serve
the needs of others
Is it too complicated?
• Everything in MFHD was developed in
response to real publications (we couldn’t
make all that up—but publishers did!)
• MARC is a communications format—not a
user interface
• Too complicated for who? Not for
machines!
Why not start new with something
simpler?
• “A simpler solution should accommodate
80% of the titles easily”
• The 80-20 rule (Pareto’s Principle): 20% of
the titles will cause 80% of the problems
• Which 80% will a simpler solution handle,
and who will deal with the other 20%?
• Likely answer: expensive humans (and
who pays for them?)
Shared Goals
• Efficient and timely communication of
transactions (updates, changes, new info)
– Emphasis on machine rather than human
communication
• Unambiguous referencing to all levels of
publication (titles, volumes, issues,
articles, etc.)
• Easy re-use of data from other sources
Shared Information
• CONSER records contain:
– Bibliographic description: title, publisher,
dates, related titles, etc. (MARC Bib)
– Enumeration, chronology, captions, prediction
patterns, etc. (MARC Holdings)
• CONSER record is a collaboratively
created and maintained “Publication
History” for serials
– Standardized for sharing, with an existing
support infrastructure
A Step up with “Super Records”
• A possible solution to the FRBR “work”
level for serials
– Gathering:
• Relationships (title changes, versions, etc.)
• Publication History information (what was actually
published)
– Creating
• A basis for better user display
• A template for more efficient re-use of information
on serials
Down to cases
• What library functions can shared “Publication
History” support?
– Interlibrary loan (better matching of user needs to
holdings at the institution and partner institution level)
– Remote storage (easier decision making and access
to multiple physical and digital locations)
– Reference linking (correlated citations from many
sources)
– E-Resources management (less ambiguous user
displays)
The Key is Information Flow
• Determination of where Publication History
content should be:
– Created
– Updated
– Managed
• Determine best methods of:
– Distribution to interested parties
– Notification of changes
A Possible Shared InfoFlow?
• Librarians continue to create and maintain
Publication History
– Using MARC Holdings and CONSER database as
basis for sharing
• Determine best distribution modes for publishers
and vendors
– Direct access via OCLC or other means?
– OAI-PMH for XML transfer to internal databases?
– Other?
Maintaining the InfoFlow
• Shared data but separate responsibilities
– Agreements defining expectations
– Investment in appropriate distribution
pipelines
– Development of a common infrastructure that
supports efficient, machine-based
interoperability
New title publication (Publisher)
Library acquires title
& first issues
Publication Pattern
created & distributed Vendor distributes
updates using
pattern model
Library uses
updates to
maintain
subscription
Library catalogs
Publication history
record captured by vendor
Library posts pattern changes for redistribution
Supporting Citation
MARC 21
SICI
245 $a
OpenURL
jtitle
020 $a
[ISSN]
issn
853/863 $i-k
(Chronology)
date
Enumeration
volume/part/
issue
853/863 $a-c
Conclusion
• The world as we know it favors those
operating furthest to the right on the
Learning Curve, with solutions:
– Complex enough to do the job
– Emphasizing machine interactions as much
as possible
– Re-using information created and maintained
by others when practicable