Imagining Tomorrow’s Future – Today! 2007 EDUCAUSE Evolving Technologies Committee.
Evolving MARC 21 for the future
-
Upload
seth-padilla -
Category
Documents
-
view
34 -
download
0
description
Transcript of Evolving MARC 21 for the future
Evolving MARC 21 for the future
Rebecca GuentherCCS Forum, ALA Annual
July 10, 2009
Overview of presentation
The current MARC environment Successes of MARC Moving to XML RDA and FRBR experimentation Linked data Issues to resolve
Credits
Sally McCallum for some slide content
John Espley for FRBR implementation
Clay Redding for Linked Data content
What is MARC 21?
A syntax defined by an international standard for communications with 2 expressions: Classic MARC (MARC 2709) MARCXML
A data element set defined by content designation and semantics
Institutions do not store “MARC 21”, as it is a communications format
Many data elements are defined by external content rules; a common misperception is that it is tied to AACR2
A set of 5 formats for different purposes: Bibliographic, Authority, Holdings, Classification, Community Information
The current MARC environment
Billions of rich descriptive records in MARC systems
Many national formats have been harmonized with MARC 21
Integrated library systems that support MARC bibliographic, authority and holdings format for different functions
Wide sharing of records for 30+ years OCLC is a major source of records MARC records are being reused (sometimes
converted) and repackaged
MARC successes
Can carry data formulated by different cataloging rules and conventions Multiple descriptive rules, different principles and
models Different subject thesauri Multiple languages and scripts
Cooperation in record exchange has resulted in widespread use and cost savings
Richness of MARC records supports multifaceted retrieval Coded data Parsed data
Problems with MARC
MARC 2709 syntax problems Limitation of available fields, subfields,
indicator values, etc. Redundant data (fixed vs. variable fields) Controlled values embedded in the
standard Ability to link Limits to extensibility Lack of explicit hierarchical levels
Some progress…
MARCXML Definition of $u, $w and $0 for
linking Definition of $2 to specify source of
controlled values Exploration into use of URIs MODS
Streamlining MARC 21 into the future
Take advantage of XML Increasingly use MARC 21 in an XML structure Take advantage of freely available XML tools
Develop simpler (but compatible) alternatives MODS
Allow for interoperability with different XML metadata schemas Assemble coordinated set of tools
Provide continuity with current data Provide flexible transition options
MARCXML
MARCXML uses the MARC data element set in an XML syntax
Lossless roundtrip conversions Simple flexible XML schema, no need to
change when MARC 21 changes Interoperability with different XML schemes by
taking advantage of free XML tools Collaborative use of metadata for access
(e.g.OAI) Continuity with current data and flexible
transition options
Example: http://lccn.loc.gov/2004012412
MARC 21 evolution to XML
More use of MARCXML
Transition to exchange in MARCXML instead of MARC 2709
Take advantage of namespaces to allow for extensions (e.g. technical metadata)
Potential to extend with new attributes or subfield markers
Other related XML schemas: MODS
Eliminates some of the problems with MARC (e.g. lack of tags/subfield codes)
More user-friendly (uses language tags) Repackages redundant data elements into one Can carry hierarchical data Less tied to cataloging rules Highly compatible with MARC but simpler,
although retaining some richness Widely implemented especially for digital
projects Governed by Editorial Committee
Example: http://lccn.loc.gov/2004012412/mods
Other related XML schemas: METS
METS A container/information package Wrapper for MARCXML and MODS descriptions Allows for additional technical and
preservation metadata Enables tracking of actions on the metadata
itself LC is exploring a native XML database for search
and retrieval bringing together records from many internal systems using MODS/MARCXML/METS
Experimentation with RDA, FRBR and RDF
MARC changes to accommodate RDA MODS changes to accommodate RDA FRBR experimentation
VTLS has implemented a FRBR based system using MARC
Other systems are looking at migrating to reflect entity-relationship models
Semantic web experiments Modeling MODS and MADS as RDF Modeling MARC as RDF See Martha Yee’s article in Information Technoclogy
and Libraries (v. 28, no. 2, June 2009)
Example of FRBR implementation of MARC: VTLS
Single database can have FRBR and non-FRBR records
System is “aware” of FRBR record level and changes displays as needed
Display of FRBR records are in tree structure
Local level fields have values of W, E, and M to indicate type of FRBR record
001 and 004 used as linking tags
Experimentation with “Linked data”
Library of Congress Authorities & Vocabularies service: http://id.loc.gov
Allows both human-oriented and programmatic access to LC-promulgated authorities and vocabularies
Actionable URIs associated with concepts First offering is Library of Congress Subject Headings, but
more to come: e.g. Thesaurus of Graphic Materials, ISO 639-2, MARC code lists, etc
Advantages Facilitate development and maintenance process for
vocabularies Expose vocabularies to wider communities Offer bulk downloads
Example:http://id.loc.gov/authorities/sh85049843
Issues to resolve for bibliographic formats
Actionable vs. descriptive Parsed vs. text Controlled/access vs. transcribed Codes vs. words Library vs. non-library traditions My model vs. your model Stability vs. change Basic retrieval vs. scholar retrieval Cost of change
How do we move forward? Continue RDA/FRBR implementation changes Transition to XML for exchange (syntax) Evolve MARC 21 (data element set)
Analyze successes that need to be carried over into a streamlined MARC
Consider MODS features to be incorporated Consider use of MARC 21 for different cataloging
rules, models and traditions, not just RDA Consider cost implications Assure continuity with current data Evolution will take some time and will be in
phases
Comments?
Tell us what you think: [email protected] [email protected]