The history of the MARC standard
After MARC ± what
then?
Leif Andresen
The author
Leif Andresen is Library Advisory Officer, Danish National
Library Authority, Copenhagen and Chair of the Danish
Standards Technical Committee for Information and
Documentation, Denmark.
Keywords
Databases, Online cataloguing, Libraries, Denmark
Abstract
The article discusses the future of the MARC formats and
outlines how future cataloguing practice and bibliographic
records might look. Background and basic functionality of the
MARC formats are outlined, and it is pointed out that MARC
is manifest in several different formats. This is illustrated
through a comparison between the MARC21 format and the
Danish MARC format ``danMARC2''. It is argued that present
cataloguing codes and MARC formats are based primarily on
the Paris principles and that ``functional requirements for
bibliographic records'' (FRBR) would serve as a more solid
and user-oriented platform for future development of
cataloguing codes and formats. Furthermore, it is argued that
MARC is a library-specific format, which results in neither
exchange with library external sectors nor inclusion of other
texts being facilitated. XML could serve as the technical
platform for a model for future registrations, consisting of
some core data and different supplements of data necessary
for different sectors and purposes.
Electronic access
The Emerald Research Register for this journal is available at
www.emeraldinsight.com/researchregister
The current issue and full text archive of this journal is
available at
www.emeraldinsight.com/0737-8831.htm
Library Hi Tech
Volume 22 . Number 1 . 2004 . pp. 40-51
# Emerald Group Publishing Limited . ISSN 0737-8831
DOI 10.1108/07378830410524486
40
The MARC format was developed to exchange
bibliographic registrations. For the first few
years the format was used to produce catalogue
cards. The MARC format was designed and
implemented many years before online
catalogues and electronic publishing of
bibliographic records were introduced.
ISO 2709 (ISO, 1996) provides the
framework for MARC, and this is visible in the
MARC formats' use of three-character field
codes, the use of indicators, and the use of
sub-field codes. This kind of database structure
is suitable for a sequential dataflow (which is
exactly for what ISO 2709 was developed) in
order to handle data on magnetic tapes. ISO
2709 and MARC formats can be used for data
types other than bibliographic data. The format
has not found much support in non-library
environments, but there are many examples of
library software being applied in contexts other
than libraries. From the author's previous
employment as a consultant for suppliers of
library systems, mention can be made of
alternative use of library software as a tool for
case management and registration of
equipment, building materials, and hardware
components in a telecommunications company.
There are (at least) three current
schools/divisions of the MARC formats:
(1) USMARC ± which became MARC21;
(2) BNBMARC ± which became UKMARC;
and
(3) UNIMARC.
There are certain similarities between
UKMARC and USMARC, while the Danish
format danMARC2 (KatalogdataraÊdet, 1998)
has been developed from the original
BNBMARC. Some years ago it was discussed
whether IMARC should replace USMARC,
CANMARC and UKMARC but, due to
differences in the three existing formats,
including the question of multi-volume works
and USMARC's use of ISBD-characters as part
of the record, IMARC did not replace any of
the other formats.
Received 1 September 2003
Revised 9 October 2003
Accepted 7 November 2003
 After MARC ± what then?
Leif Andresen
USMARC and UKMARC are based on the
MARC format developed by the Library of
Congress in the 1960s. The purpose of that
format was to exploit the new computer
technology for the distribution of catalogue
data. A number of basic characteristics,
therefore, are common to both formats: the
main field groups, according to their overall
functions, are frequently the same. The
descriptive title and originator entries are, in
USMARC and UKMARC, placed in fields
210-24X, and notes are placed in fields
500-599. UNIMARC (IFLA, 1994), on the
other hand, has a different division into main
groups, and title information is not placed in
field 245, but in field 200.
Although MARC21 is often described as an
international standard, it is only used in a
limited number of countries. UNIMARC,
which was created within IFLA, is in fact closer
to an international standard. UNIMARC (first
published in 1977) was meant to be an
international exchange format between national
bibliographic institutions. According to the
preface to the latest edition (IFLA, 1994), it
was designed as a model for the development of
new machine-readable formats. UNIMARC
has been applied in several south and eastern
European countries as well as some Third
World countries.
This section has explained why MARC is not
equal to MARC21. In the following section, a
more detailed description of the differences
between MARC21 and danMARC2 will be
provided.
Differences between danMARC2 and
MARC21
danMARC2 was developed in Denmark in the
1990s. This was done in order to create a
common format for all sectors and to modernise
the registration of library materials, since online
catalogues (electronic publishing of
bibliographic records) have obviously replaced
the card catalogues. danMARC2 is in many
ways a more modern format than MARC21.
The format is in various ways adapted to the
technological development as it appeared in the
middle of the 1990s. In order to be able to
handle types of material other than printed
41
Library Hi Tech
Volume 22 . Number 1 . 2004 . 40-51
materials, all MARC formats have undergone a
considerable development. Today not only
books but also continuing resources, computer
files, maps, music, sound recordings, visual
material, and mixed materials are handled by
MARC formats.
MARC21 appears more appropriate than
danMARC2 when applied to cartographic
materials and document collections. On the
other hand, danMARC2 seems more
appropriate for the registration of music and
sound recordings. Fields, which apparently
correspond in the two formats, are often used
for data elements defined for different purposes
in the two formats.
Cataloguing rules and formats
The Danish format ``danMARC'' and the
Danish cataloguing rules were revised at the
same time, which meant that the many
interdependent issues could be dealt with in the
right context. For instance, all examples in the
cataloguing rules are presented, as they should
be formatted in danMARC2. The revision
meant moving away from AACR2. The most
substantial change was the abolition of main
and added entry elements, which were replaced
by access points and a voluntary location
element. This difference is not very important
when searching on controlled forms of data,
since these can be isolated from non-controlled
forms in search indexes. Since the choice of
main entries and location elements is based on
different principles, however, presentation as
well as location will differ according to the set of
rules employed.
Format structure
In MARC21 as well as danMARC2 each field
contains at least one and often more sub-fields.
Each field code is followed by two indicators,
which can contain various informations on
treatment or interpretation of data. MARC21
does not have indicators and sub-fields in
control fields 001-008. In MARC21, indicators
are widely used for different purposes, e.g. for
generating text as ``former title'' and to indicate
how many characters should be ignored when
alphabetising in the first sub-field. In
danMARC2 indicators are only used in a very
limited number of fields: relations of periodica
 After MARC ± what then?
Leif Andresen
in field 860-879, and fields defined for local
purposes.
In the descriptive fields in danMARC2, the
division of fields into sub-fields follows ISBD's
division into elements. This facilitates the
generation of separating characters in displays
and printouts in ISBD and other formats.
MARC21's descriptive fields are not specified
in as many sub-fields as in danMARC2, and the
sub-fields are not repeatable to the same extent
as in danMARC2. MARC21 also requires
typographical separating characters to be keyed
in, as in those cases where separating character
and a sub-field code coincide.
In a number of fields, MARC21 uses an
alphabetising indicator to state how many
characters should be ignored when
alphabetising in the first sub-field. In
danMARC2, the alphabetising indicator is
replaced by an alphabetising symbol ``¨'', which
is placed where the alphabetising in a given
sub-field is supposed to start. This is a more
flexible indication of alphabetisation, since the
alphabetisation is not tied solely to the first
sub-field in a field.
Examples
MARC21:
245 03 *a Le Bureau = La Oficina = Das BuÈro
246 10 *a Oficina
246 10 *a BuÈro
danMARC2:
245 00 *a Le ¨Bureau *p La ¨Oficina *p Das
¨BuÈro
Sub-field p (*p)[1] and alphabetising symbol
(¨) facilitate direct indexing. An equals sign
before parallel titles must be keyed-in in
MARC21:
MARC21:
245 10 *a He who hunted birds in his father's
village : *b the dimensions of a Haida myth /*c
Gary Snyder ; preface by Nathaniel Tarn ; edited
by Donald Allen
danMARC2:
245 00 *a He who hunted birds in his father's
village *c the dimensions of a Haida myth *e Gary
Snyder *f preface by Nathaniel Tarn *f edited by
Donald Allen
MARC21 does not allow for differentiation
between primary authors (sub-field *e) and
42
Library Hi Tech
Volume 22 . Number 1 . 2004 . 40-51
secondary authors (sub-field *f). Colon before
sub-title and slash before authors has to be
keyed in:
MARC21:
245 04 *a The listing attic ; The unstrung harp /*c
by Edward Gorey
740 01 *a Listing attic
740 01 *a Unstrung harp
danMARC2:
245 00 *a The ¨listing attic *a The ¨unstrung
harp *e by Edward Gorey
Repetition of sub-field a (*a) and alphabetising
symbol ``¨'' facilitates direct indexing. The
smaller number of sub-fields in MARC21
means that design of indexes is less flexible and
the possibilities for variation of presentation
formats are more limited than in danMARC2.
To a certain extent, MARC21 compensates for
this by facilitating larger redundancy of data in
the records.
In MARC21 author and title of an added
work are placed in the same sub-field:
MARC21:
245 14 *a The analysis of the law /*c Sir Matthew
Hale. The students companion / Giles Jacob
danMARC2:
245 00 *a The ¨analysis of the law *e Sir Matthew
Hale *x The students companion *e Giles Jacob
With a specific sub-field for ISBN it is possible
to use this information for system functions ±
such as entry on ISBN in another system:
MARC21:
020 ## *a 0877790019 (black leather) *z
0877780116 : *c $14.00
danMARC2:
021 00 *a 0877790019 *c sort lúder *d $14.00 *x
0877780116
Codes are significantly different in MARC21
and danMARC2. The differences apply to
application areas, definitions of the individual
codes, and the values of these. In MARC21's
field 007, a considerable number of
position-determined one-character codes have
been defined for the statement of physical
details. They are entirely different from
danMARC2's material type codes, and seem
more suited for library-technical functions such
as choice of play-back equipment and storage
 After MARC ± what then?
Leif Andresen
conditions than for the generation of texts for
search and presentation purposes.
Multi-volume works
In Denmark, two different methods for the
formatting of multi-volume works are
facilitated, either independent registrations of
individual levels in separate bibliographic
records or independent registrations of
individual levels in one bibliographic record.
MARC21 does not offer a general instruction as
to the formatting of multi-volume works. The
most common practice seems to be a one-level
method, where the collective work is described
in one record. Both British Library and the
Swedish union catalogue LIBRIS have
considered various methods in connection with
their shift to MARC21, but they have not made
an unambiguous choice.
MARC21 is not very flexible. There is no
possibility for registering multi-volume works in
several-records structures, which is facilitated
and frequently used in danMARC2 records.
The previous description of the differences
between the two formats has served to illustrate
that USMARC, which has now been
re-christened MARC21, is a product of a 1960s
technology. The Danish danMARC2 format
has been modernised and adapted to the online
age, but is nevertheless a product of the 1980s
technology. The implementation of a MARC
format is in many ways time-limited and it has
hopefully been demonstrated that MARC is
much more than MARC21.
Problems with MARC
This section deals with a number of problems
associated with the MARC formats. It must be
stressed that these problems are associated with
the practical application of the MARC formats
and the problems mentioned could possibly be
solved with a MARC format. Nevertheless, it is
important to address the actual applications of
the MARC formats and not what might, under
different conditions, already have been worked
out.
MARC is used for text-based data input. The
division into fields and sub-fields supports a
relatively specific division of data. This is
suitable for bibliographic records and therefore
43
Library Hi Tech
Volume 22 . Number 1 . 2004 . 40-51
an advantage of the MARC formats. Gradually,
however, the text dependency has also turned
into a disadvantage. In practice the MARC
format allows for only strictly bibliographic
data. Data such as reviews, indexes in their
original forms, and image and sound files
cannot be added. Supplementary information,
which now and in the future will be used to
enhance registrations in the catalogues, cannot
be exchanged in a standardised form.
Furthermore, there will often be a loss of data,
because local additions cannot be read by a
recipient system.
A MARC format is by nature a strict format,
since it was originally intended for the
production of printed catalogue cards;
therefore, the interaction between different
library systems is not reflected. The lack of
flexibility means that local additions might
hinder exchange between local systems and
union catalogue systems. The various library
systems in the Danish public libraries have
invented their own non-standardised
peculiarities in order to update local records
with national updatings without overwriting
local additions/corrections. The research
libraries in Denmark do not interplay as much
with the union catalogue as the public libraries.
Nevertheless, the research libraries differ
according to cataloguing policy and practice,
which causes matching problems in the union
catalogue, where the identification and merging
of records for the same title/edition are
hampered.
Large volumes of data cannot easily be
incorporated in a MARC record, although there
is no fixed limit for the amount of data. The
author has seen MARC-based database systems
used for large volumes of text, which have
appeared rather clumsy. This is primarily
caused by the database systems, but the
construction of MARC does not really support
the display of continuous texts.
The foundation of MARC on the printed
catalogue means that the implementation of the
MARC format is directed towards description
and presentation of the individual document on
card or screen. This means that it is difficult to
handle relations between data that are
described in different fields. In danMARC2,
sub-field *aÊ[2] is used to tack fields together,
which means that, for example, connected title
 After MARC ± what then?
Leif Andresen
and artists on a music CD are stated in different
fields. A catalogue record describes an edition,
and there is no suitable system for describing
connections between editions. To show the
relation between main record and sub-records
for a multi-volume work, danMARC2 uses field
014 in the sub-record to link to field 001 in the
main record. This method for linking parts
together seems quite rigid.
MARC is implemented in library systems and
is thereby library-specific. MARC is not
immediately usable for exchange with
environments other than the internal library
environment. This goes for both the
technological side in relation to packing (cf.
later section) and for the construction of fields
that are assigned to information similar to
information used in systems outside the library
sector. Although a number of problems with the
MARC formats have been outlined, one must
remember that the different MARC formats
have served the libraries well. This author's
observations so far are not a criticism of
previous choices, but merely a basis for the
discussion of future developments. And, despite
the problems with the MARC formats, it is
evident that at the moment there is no
alternative!
Various future developments point at
upcoming changes, where the main initiator
will be IFLA's Functional Requirements for
Bibliographical Records (FRBR) (IFLA
Study Group on the Functional
Requirements for Bibliographic Records, 1998)
and the Extensible Markup Language
(XML)[3].
Functionality of bibliographic records
Over the years various theoretical demands
have been formulated regarding the
functionality of the catalogues and/or the
bibliographic records. The Anglo-American
cataloguing rules (AACR2) as well as the
Danish cataloguing rules are attempts to
implement the Paris principles from 1961. The
Danish cataloguing rules were in their original
form a modified version of the Anglo-American
cataloguing rules.
44
Library Hi Tech
Volume 22 . Number 1 . 2004 . 40-51
The Paris principles
In the Paris principles (Der Deutsche
Bibliothek, 1961) the catalogue's function is
described as:
The catalogue should be an efficient instrument
for ascertaining whether the library contains a
particular book (including other library materials)
specified by:
(a) its author and title; or
(b) if the author is not named in the book, its title
alone; or
(c) if author and title are inappropriate or
insufficient for identification, a suitable
substitute for the title;
and
(a) which works by a particular author; and
(b) which editions of a particular work are in the
library.
The first requirements support the catalogue's
identifying function. The cataloguing rules
prescribe citing of title, creator, etc. The second
requirements support the catalogue's
collocating functions. The obligation to show
an author's works is fulfilled by bringing
together an originator's production under a
controlled form of his/her name ± with
references between varying and controlled
forms of the name. In the same way the
obligatory overview of editions is secured by
using uniform titles. Here, the US cataloguing
tradition is better able to fulfil the demand than
the Danish one. Apart from the application of
uniform titles or standard titles for musical
works, there is no general Danish tradition for
stating titles in normative forms.
Functional requirements for bibliographic
records (FRBR)
Since the Paris principles, no requirements for
catalogues or bibliographic records were
seriously worked out until IFLA in 1998
published Functional Requirements for
Bibliographic Records (FRBR) (IFLA Study
Group on the Functional Requirements for
Bibliographic Records, 1998). These
requirements are important, because the Joint
Steering Committee for the Revision of AACR,
which is responsible for the development of
AACR, has a policy for working towards
accordance with FRBR.
 After MARC ± what then?
Leif Andresen
FRBR recommends a basic level for the
functionality of bibliographic records. The
bibliographic record should help the user:
(1) To find all documents containing:
. the works for which a given person or
corporation is responsible;
. the different representations of a given
work;
. works on a given topic; and
. works in a given series.
(2) To find a certain document:
. when name(s) of person(s) and/or
corporation(s) responsible for work(s)
in the document is/are known;
. when the title of the document is
known; and
. when the document identification is
known.
(3) To identify a work.
(4) To identify a representation of a work.
(5) To identify a document.
(6) To choose a work.
(7) To choose a representation of a work.
(8) To choose a document.
(9) To gain access to a document.
In these functional requirements the
bibliographic entities are defined as:
. A work is a delimited intellectual or artistic
product.
. A representation of a work (expression) is a
work given an intellectual or artistic form.
. A document (manifestation) is a
representation of a work fixed in a physical
form.
. An item is a copy of a document.
There are some discussions about the
delimitation between these bibliographic
entities (see, for example, Jonsson, 2002).
FRBR and MARC
An important difference between the Paris
principles and FRBR is that FRBR requires that
a document contain at least one representation
of one work. It is not sufficient to facilitate a
search for the documents' forms of title and
originator data, to facilitate collocation of an
author's works by using controlled forms of
names, and to facilitate collocation of the
representations of a work. It is also necessary for
the records to contain sufficient, unambiguous
data for identification at all levels as well as for
45
Library Hi Tech
Volume 22 . Number 1 . 2004 . 40-51
characterising and individualising data at all
four levels, in order to facilitate the
identification and qualified choice among the
records in a search set.
The MARC formats support, with their title
and document orientation, the Paris principles,
while FRBR is oriented towards the handling of
relations between works as well as subject-based
access. Denton (2003) has written about the
relationship between FRBR and the cataloguing
rules. There is no pre-packaged model for the
implementation of FRBR in practice, but work
with implementing and applying FRBR will
continue on an international level.
So far, FRBR has not been incorporated in
either a format or in cataloguing rules, but the
problematic issues are being studied and which
requirements, in relation to user interfaces in
the library systems, FRBR would entail.
XML
Extensible Markup Language (XML) is a
simple and flexible text format derived from
SGML (ISO 8879). Originally XML was
designed to meet the challenges of large-scale
electronic publishing. XML is also playing a
more and more important role in the exchange
of a wide variety of data on the Web and
elsewhere. XML was developed by The World
Wide Web Consortium (W3C), which develops
interoperable technologies (specifications,
guidelines, software, and tools) to lead the Web
to its full potential.
An example of XML: a sample of a
MODS-record with title information:
<mods:titleInfo>
<mods:title>Sound and fury :</mods:title>
<mods:subTitle>the making of the
punditocracy/</mods:subTitle>
</mods:titleInfo>
in MARC21 would look like this:
245 10 *a Sound and fury :*b the making of the
punditocracy
XML offers a more general standard for
describing data for transport. This was not the
case before and when tools like MARC and ISO
2709 were developed.
One changed condition is the space on discs
and cables. An XML-formatted record takes up
far more space than a MARC record, but the
requirement for space is no longer as important
 After MARC ± what then?
Leif Andresen
as before. With XML a container for data
exchange has been created that is being used
globally. In itself XML is nothing ± and it can
be both standardised and very private.
The formal description of an XML document
can be created in various ways, but it is more
and more common to define it in SML
schemata, which are available on the Internet.
This means that data themselves can contain a
format definition in the form of a URL, which
points to the definition somewhere on the Net,
that a local addition to a general schema is a
lesser problem, since data can contain a pointer
to the definitions. With XML related works can
be linked (on the basis of the FRBR concept)
and relationships presented in a logical way to
the user. It is also possible to create a tree
structure within XML, so that information
about single items on a CD can be described as
wholes (linked together on a ``branch'' of
the tree).
It is possible to embed a variety of other texts
either as complete texts or as links. Other
objects, such as image files, can also be
embedded in the form of links. Using authority
records more or less freely on the Net will also
be a possibility ± the ideal is to use the national
bibliographical authority base for authors from
the country in question.
XML has a number of tools attached to it,
and XML has definitely become a mainstream
technology. This means that programming of
IT systems in relation to library data is changed
from a specific to a mainstream technology.
Among the standard tools attached to XML is
the possibility of building conversions among
various formats into a stylesheet, so that the
individual record contains several formats. A
registration can thus be presented in various
ways, not only in shorter and longer
presentation formats, but also in different
MARC formats. This makes it possible to
register at a detailed level, and automatically let
data be represented in simpler structures for
international interoperability.
The specification of an XML format in the
form of an XML schema makes it possible to
incorporate data validation. This will mean that
different suppliers of systems by using the same
XML schema can support a uniform quality
of data.
46
Library Hi Tech
Volume 22 . Number 1 . 2004 . 40-51
MARC and XML
There are some initiatives concerned with the
use of XML in relation to MARC records. In
this context it is important to differentiate
between content formats and transportation
formats. A content format is a format that
defines actual descriptions and dictates, for
example, that a title must be in field 245
sub-field *a, and that a field number must have
three digits. A transportation format is a
container into which various content formats
can be placed. MARC21, UNIMARC and
danMARC2 are all content formats. So far the
only internationally standardised transport
format is ISO 2709, which can contain all the
different MARC formats.
A well-known content format presented in
XML is the Metadata Object Description
Schema (MODS)[4], which is a slightly
reduced MARC21 format, described verbally
and not in field codes. MODS is not a general
XML-solution for MARC records, but comes
close to a MARC21 solution. Yet, it does not
solve (most of) the problems associated with
MARC as such. As shown in the example in the
previous section ``title from a MODS record'',
the ISBD character set is applied. The
transportation format ISO 2709 uses a very
compact form of data packing, which is
eminently suited for the purpose for which it
was originally designed, namely packing
on magnetic tape, using the smallest
possible space.
There are various versions of XML packings
for MARC. For example, a MARC21 version,
created by Library of Congress (Library of
Congress, 2003) and one made in connection
with OAI-PMH (Open Archives Initiative ±
Protocol for Metadata Harvesting) (Open
Archives Initiative, 2002).
ISO 2709 will probably be replaced by an
XML schema. This was discussed at a meeting
in ISO's Committee for Interoperability within
Information and Documentation (TC46/SC4)
in May 2003. A process has begun to develop a
Library of Congress MARC21 XML packing
into an ISO-standard with a more general
XML-based transportation format,
incorporating all MARC formats. Apart from
editing the comments (where MARC21 is to be
replaced by MARC), this transportation format
 After MARC ± what then? Library Hi Tech
Leif Andresen Volume 22 . Number 1 . 2004 . 40-51

only requires information about formats that libraries, archives and museums is published on
are present in the record. the Internet:
The same title field in the above example Common data elements for Danish
would look like this in MODS: Archives-Libraries-Museums:
<datafield tag="245'' ind1="1" ind2="0"> Title
<subfield code="a"> Sound and fury : Creator
</subfield> Contributor
<subfield code="b"> the the making of Publisher
the punditocracy</subfield> Subject
</datafield> Description
Date ± Refinements by: Created, Modified
This kind of supplement to ISO 2709 is
Type
obviously made in XML, but offers only some
Format
of the advantages inherent in XML. Certainly,
Identifier
XML is a mainstream technology, but it is still
Source
the MARC format with fields, sub-fields and
Language
indicators that is embedded in the record.
Relation
Coverage ± Refinements by: Spatial, Temporal
Interplay with other sectors and functions Rights

It turns out that there were data for all 15

MARC is library-specific and cannot in practice
Dublin core elements (ISO, 2003). The need to
interact with environments other than the
go beyond the 15 general elements was
internal library environment. Previously, this was
primarily caused by the need to express
not a problem, but with the increased exchange
relations with other documents/objects in a
of data between different sectors it has now
more specific manner. Furthermore, there is a
become problematic. The world around libraries
has changed, and barriers between different need to describe other things than just the time
sectors have broken down in various ways. A of publication. Another example is various
library is no longer an independent island, since governments' or municipal administrations'
interplay between libraries and external sectors is need to exchange data. Here, Dublin Core has
a definite requirement. A university library must been chosen as the basis, and a set of metadata
be able to interrelate with the university's elements has been defined for exchange
administrative systems and export bibliographic between Danish authorities' case management
records to applications, which are often quite systems (DokForm-gruppen, 2002):
different and simpler, like various support tools Core metadata for Exchange of cases:
for writing reports. Title
Denmark has launched a project on Creator
recommendations for cooperation between Subject
institutions within the fields of archives, DateCreated
museums and libraries. The objective is to DateSend
reach a common presentation of data from the DateAvailable
three sectors. Dublin Core has been chosen, Identifier
since the overall structure of this format makes RightsSecurityClassification
a common presentation possible. On the other RightsAccessRights
hand, it is not feasible to use Dublin Core Receiver
internally in the sectors, as it is far too general Type
and unable to cope with specific needs. RelationHasPart
The choice of Dublin Core is problematic, RelationIsPartOf
because this rather simple format is basically Process
focusing on Web resources. But it is an attempt DateAction
to establish a cross-domain registration schema, Owner
and an ever-increasing part of materials from SendBy
47
 After MARC ± what then? Library Hi Tech
Leif Andresen Volume 22 . Number 1 . 2004 . 40-51

It turns out that public authorities have the Author or creator

same need to handle relations as archives and Title
museums. This points to FRBR as a feasible Series
model. Regarding the publishing sector, at the Edition
moment tremendous efforts are going on to Place of publication
ensure interoperability between different Publisher
systems, such as Online Information eXchange Other contributor
(ONIX)[5]. Some fairly comprehensive data Date of publication
schemes have been developed, which match Date of creation
MARC in complexity. Library of Congress has Form of contents
mapped 211 data elements in ONIX for Number of volumes
MARC21 (Library of Congress, Network Pagination
Development and MARC Standards Office, Size of item
2000), so interplay between ONIX and Accompanying material
Format of item (technical specifications)
MARC21 will be possible. Yet, ONIX is of
Subject or keyword
course completely adapted to the bookseller's
Classification
needs.
Abstract or description.
From the learning community some basic
data elements are picked up from Learning A number of data elements are associated with
Object Metadata (LOM) (IEEE LTSC circulation, ILL and acquisition. In this
Learning Object Metadata Working Group, context, rights management plays a part.
2002): The Dublin Core Metadata Initiative
Learning Object Metadata: (DCMI) Libraries Working Group has
Title explored various uses for the Dublin Core
Keyword
Metadata Element Set in library and related
Description
applications. They envisioned the following
Contribute
± Refinement by roles: Author, Publisher etc.
possible uses:
Contribute.date
. to serve as an interchange format between
Format various systems using different metadata
Identifier standards/formats;
Language . to use for harvesting metadata from data
Relation sources within and outside the library
Coverage domain;
Rights . to support simple creation of library
Version catalogue records for resources within a
Learning resource type variety of systems;
The wording is a little different from the
. to expose MARC data to other
previous examples, but the basic content is very communities (through a conversion to
much the same. DC); and
Today, a format has many functions, apart . to allow for acquiring resource discovery
from facilitating search and presentation. In metadata from non-library creators using
various administrative processes, data from DC:
bibliographic records are used in contexts, such DC-Library Application Profile (draft):
as acquisition of material and interlibrary loans. Title ± Refinements by: Alternative
In connection with the ISO 8459 series on data Creator
elements, a number of bibliographic data Contributor
elements are defined for use in relation to Publisher
non-bibliographic registration: Subject
ISO 8459 bibliographic data elements for Description ± Refinements by: Abstract, Table
non-bibliographic use: Of Contents
48
 After MARC ± what then?
Leif Andresen
Date ± Refinements by: Created, Valid,
Available, Issued, Modified, Copyrighted,
Submitted, Accepted, Captured
Type
Format ± Refinements by: Extent, Medium
Identifier ± Refinements by: Identifier Citation
Source
Language
Relation ± Refinements by: Is Version Of, Is
Format Of, Has Format, Is Replaced By,
Replaces, Is Part Of, Has Part, Requires, Is
Referenced By, References
Coverage ± Refinements by: Spatial, Temporal
Rights
Audience
Edition
Location
The question of rights management turns out to
be a major issue outside library systems. This
has not been the case for the libraries, since
they, as far as book material is concerned, have
been covered by a clause in the copyright law,
which states that loan can take place without an
agreement from the originator.
When comparing the examples above, one
suggestion for a common selection
(alphabetical order) could be:
. Creator;
. Contributor;
. Date (available/created/published);
. Description;
. Edition;
. Format (technical specifications);
. Identifier;
. Language;
. Publisher;
. Relation;
. Subject;
. Title; and
. Type (genre).
This could lead to a future catalogue based on
Dublin Core. But one has to bear in mind the
basic principle for Dublin Core: to describe
resources on the Internet for the purpose of
searching. The idea of a general format for
describing Internet resources has to some
extent been successful. An obvious danger is
just to use the Dublin Core to reinvent MARC.
The draft for DC-Library Application Profile
illustrates a Dublin Core problem, since the
element Edition is neither a part of Dublin core
nor any of the acknowledged refinements.
49
Library Hi Tech
Volume 22 . Number 1 . 2004 . 40-51
There has been an ongoing discussion among
Dublin Core users as well as within the
DCMI[6] whether DC is to be acknowledged
as the simple set or whether it should be greatly
expanded.
Conclusion
The development of the Internet means that
data from different sectors are more visible and
accessible than before. A natural consequence is
that the borders between sectors is being
demolished. This also applies to libraries. It is
necessary to be open to the world outside and to
share standards and data with other sectors.
Bibliographic records should be much easier
to reuse ± by other institutions as well as other
libraries. The question, then, is: how to create
descriptions with several layers, which can be
used in various contexts and still keep the
duplication of data to a minimum?
One possible model could contain a division
of data:
. Core data.
. Supplement: data generally necessary for
libraries.
. Supplement: national need for libraries.
. Supplement: specific needs of the
individual library.
. Supplement: data necessary for
governmental information.
The core data could be selected with inspiration
from Dublin Core's 15 elements and
applications of Dublin Core in other sectors.
The list in the previous section might act as an
inspiration, because it illustrates the necessity
for a general schema to look further than
Dublin Core, based as that is on Internet
resources. For data generally necessary for the
libraries, there are a great number of sources.
FRBR is undoubtedly important, but also data
element standards like ISO 8459 can be
considered. Supplements should not be seen as
a layer-upon-layer superstructure on the Core.
Output will be many-faceted, and vary
depending on different contexts.
Document descriptions could be embedded
in a common structure that reflects relations
between documents in relation to the
FRBR-model's expression and work. It must
 After MARC ± what then?
Leif Andresen
offer the user the chance to navigate between
different concrete documents as well as being
able to see their mutual relations.
The transition from the present formats will
of course cause some problems. But, if a new
format is sufficiently specific, various MARC
formats can be created based on data from such
a system, thereby ensuring that new data can be
used in old systems. On the other hand,
conversion from a MARC format is not always
easy, since the specificity will often be lower in
the recipient format. A comparison between
MARC21 and danMARC2 shows that
MARC21 has a relatively low specificity. One
could consider a revision of MARC21 adapted
to the online age. Although MARC21 contains
many archaic traits, it would seem more
reasonable to look forward than back to what
might have been a good idea some ten years
ago. Furthermore, a format transformation is
quite costly. Over the past few years XML has
become a magic term. But embedding of
MARC data in XML is not enough. Replacing
ISO 2709 with a MARC XML format would be
useful, but does not allow for data interplay
with other sectors.
It is obvious that an XML format must be
developed in cooperation with other sectors.
This XML format must be able to contain
several layers in the description and at the same
time accommodate different types of data.
Embedment in XML is not perfect for all types
of data, but for the most part an embedment
with a trivial http-reference will be quite
sufficient. It is important to get the balance
right. We need international development
efforts, because the definition of core data has
to be based on broad consensus in the
international library world. This also includes
the choice of XML. The library world will have
to leave MARC for something different and
more flexible. I have tried to suggest in which
direction they ought to move. Yet, there is a
long way to go and it is going to take time.
XML presents some opportunities and it
could certainly be developed further. Primarily,
a development of the FRBR-model and a
resulting change of paradigm in cataloguing and
registration practice are needed. This article
does not claim to have given an exhaustive
account of either FRBR or XML, but hopefully
there are some useful pointers to possible
50
Library Hi Tech
Volume 22 . Number 1 . 2004 . 40-51
developments for a future catalogue practice.
Ideally, the suggested solution should be for
``the whole world'', but not for all kind of
resources. The idea in this article is related to
describing and discovering ``information
resources'' which are primarily text-based.
Metadata for the registration of other resources
± from persons to nails and bricks ± are also
used, but the core metadata are completely
different.
Talking about core metadata for the whole
world of information resources is also tackling a
very big objective. In the practical world, there
will be different metadata sets for different
communities and not all of them will be
connected. Yet it will be useful to work with this
goal as a point of departure. Though not
applying to the whole world, it will still be very
valuable to bring the different MARC
communities together. It should be possible to
work out a broader solution. In any case: such a
solution will have the potential for being the
basis for interoperability between sectors.
Notes
1 The delimiter symbol is represented by a ``*'' in this
article.
2 The letter ``aÊ'' is a special Danish letter.
3 Extensible Markup Language (XML), available at:
www.w3.org/XML/
4 Metadata Object Description Schema (MODS),
available at: www.loc.gov/standards/mods/
5 Online Information eXchange (ONIX), available at:
www.editeur.org/onix.html
6 Dublin Core Metadata Initiative (DCMI), available at:
http://dublincore.org/
References
Denton, W. (2003), FRBR and Fundamental Cataloging
Rules, Miskatonic University Press, available at:
www.miskatonic.org/library/frbr.html
(Der) Deutsche Bibliothek (1961), ``Statement of principles'',
adopted by the International Conference on
Cataloguing Principles, Paris, October, available at:
www.ddb.de/news/pdf/paris_principles_1961.pdf
DokForm-gruppen (2002), Metadata til udveksling mellem
EDH/ESDH-systemer, IT ± og Telestyrelsen,
Copenhagen, available at: www.oio.dk/files/
horingsex-efter.doc
IEEE Learning Technology Standards Committee (LTSC)
Learning Object Metadata Working Group (2002),
 After MARC ± what then?
Leif Andresen
Standard for Information Technology ± Education
and Training Systems ± Learning Objects and
Metadata, IEEE P1484.12, available at: http://
ltsc.ieee.org/wg12/
IFLA (1994), UNIMARC Manual: Bibliographic Format 1994,
available at: www.ifla.org.sg/VI/3/p1996-1/sect.htm
IFLA Study Group on the Functional Requirements for
Bibliographic Records (1998), Functional
Requirements for Bibliographic Records: Final Report,
K.G. Saur, MuÈnchen, available at: www.ifla.org/VII/
s13/frbr/frbr.htm
International Organization for Standardization (ISO)
(1996), ISO 2709:1996 Information and
documentation ± Format for Information Exchange,
ISO, Geneva.
International Organization for Standardization (ISO)
(2003), ISO 15836:2003 The Dublin Core Metadata
Element Set, ISO, Geneva, available at: http://
dublincore.org/documents/dces/ (not ISO-style, but
DCMI-style).
51
Library Hi Tech
Volume 22 . Number 1 . 2004 . 40-51
Jonsson, G. (2002), The Basis for a Record in Major
Cataloguing Codes and the Relation to FRBR, IFLA,
Glasgow, available at: www.ifla.org/IV/ifla68/papers/
052-133e.pdf
KatalogdataraÊdet (1998), danMARC2. Edb-format til
inddatering og udveksling af bibliografiske data i
maskinlúsbar form, Biblioteksstyrelsen, Copenhagen,
available at: www.kat-format.dk/danMARC2/
default.html
Library of Congress (2003), MARCXML MARC21 XML
Schema, available at: www.loc.gov/standards/
marcxml/
Library of Congress, Network Development and MARC
Standards Office (2000), ONIX to MARC21
Mapping, available at: http://lcweb.loc.gov/marc/
onix2marc.html
Open Archives Initiative (2002), The Open Archives Initiative
Protocol for Metadata Harvesting Protocol Version 2.0,
available at: www.openarchives.org/OAI/2.0/
openarchivesprotocol.htm