Study of The Use of Metadata Standards For Cataloging Internet Resources - Thesis by NTU Student

ATTENTION: The Singapore Copyright Act applies to the use of this document. Nanyang Technological University Library.
NANYANG TECHNOLOGICAL UNIVERSITY
A STUDY OF THE USE OF METADATA STANDARDS FOR

CATALOGUING INTERNET RESOURCES
Submitted in Partial Fulfillment of the Requirements

for the Degree of Master of Science (Information Studies)
of the Nanyang Technological University
by
LOW KE KHOON
SCHOOL OF COMPUTER ENGINEERING

2001
ABSTRACT
A variety of metatadata standards have evolved in the recent years under

various group of professionals, as they began to realize the need to enable better
retrieval and discovery of electronic resources, especially resources on the Internet.
This study explored and investigated the various ways in which Dublin Core,
developed by the Dublin Core Metadata Initiative (DCMI) through a series of
workshops since 1995, has been used to describe and organize information on the
Internet. Sixteen Dublin Core projects were surveyed with the use of a checklist that
was constructed based on the key issues of the metadata schema, creation and
deployment model utilized.
The study revealed that Dublin Core has indeed been applied in several
countries by various communities (including universities / research institutions,
libraries, government, museums and archives, publishers and other information /
content providers) to enhance cross-disciplinary discovery of electronic resources,
including Web pages. While most of the surveyed projects were consistent in the use
of DC elements, the use of DC qualifiers – element refinement and encoding schemes,
were more varied and inconsistent in these projects. Moreover, the abundant
integration of non-DC elements, subelements and encoding schemes (whether locally
developed or using other established standards) clearly indicated that Dublin Core is
well-positioned to provide a ‘lowest common denominator’ foundation of
interoperability between network resources descriptions across all systems, disciplines
and cultures.
The study also found that “third party metadata model” and “view filter
metadata model” were more popular for the deployment of Dublin Core, as compared
to the “embedded metadata model”. The trend of using automatic metadata creation or
indexing is also beginning to gain momentum, as more metadata tools have been
developed in the recent years. Finally, the majority of the projects surveyed adopted
DC metadata standard for the following reasons to benefit the users: (a) to facilitate
searching and retrieval, (b) to improve resource discovery, (c) to help in the
i
management and organization of resources, and (d) for interoperability and / or

crosswalk between different metadata format. Such benefits are the strengths of Dublin
Core metadata standard.
ii
ACKNOWLEDGEMENTS
Upon the completion of my thesis, I would like to express my heartfelt

gratitude to my supervisor – Professor Abdus Sattar Chaudhry, for his constant
encouragement, guidance and confidence in me during the whole research process.
I would also like to thank the Nanyang Technological University Library

Management, especially the Librarian – Mr Foo Kok Pheow, and Mrs Low-Tan Lay
Ching, for their support and concern in my efforts throughout the Master of Science
(Information Studies) course.
I feel very lucky to have a very caring family, supportive friends and a loving
husband, who have helped me in many ways through the difficult stages during the
research and writing of thesis, and without whom, I would not have been able to
accomplish what I did, today.
iii
TABLE OF CONTENTS
Page
Abstract i
Acknowledgements iii
Table of Contents iv
List of Tables vi
List of Figures vii
Chapter 1 Introduction 1
1.1 Background on Metadata and the Dublin Core Metadata 1
Initiative (DCMI)
1.2 Problem Statement 3
1.3 Organization of Dissertation Chapters 4
Chapter 2 Literature Review 5

2.1 Metadata in General 5
2.2 Dublin Core Metadata Initiative (DCMI) 8
2.3 Applications of Metadata Standard (with focus on Dublin Core) 10
Chapter 3 Methodology 15
3.1 Selection of Dublin Core Projects 15
3.2 Data Collection 17
3.3 Presentation of Data 20
Chapter 4 Findings 21
4.1 Consistency with the Use of Dublin Core Elements 21
4.2 Consistency with the Use of Dublin Core Qualifiers – Element 23
Refinements
4.3 Consistency with the Use of Dublin Core Qualifiers – Encoding 30
Schemes
4.4 Overview of Dublin Core Projects 34
iv
Chapter 5 Discussion 43
5.1 Metadata Schema 43
5.2 Overview of Dublin Core Projects 48
5.3 Use of Local / Non-DC Elements 50
Chapter 6 Summary and Conclusions 53
References 56
Appendices
Appendix A Checklist Used for Survey of Dublin Core Metadata A-1
Projects
Appendix B Projects’ Metadata Schemas Used for Comparison B-1
with DCMES
Appendix C Raw Data Collected for the Use of Subelements C-1
Appendix D Raw Data Collected for the Use of Encoding Schemes D-1
Appendix E Use of Local / Non-DC Metadata Elements E-1
v
LIST OF TABLES
Table Page
3.1 Summary of DCMES and Qualifiers 19
4.1 Overview of Dublin Core Elements Adopted by Each 22
Dublin Core Project
4.2 Projects Consistent with the Use of Qualifiers – Element 29
Refinement
4.3 Projects Consistent with the Use of Qualifiers – Encoding 33
Scheme
4.7.1 Submission and Selection of Resources 35
4.7.2 Collection Scope and Coverage 36
4.7.3 Collection - Types of Materials Cataloged 37
4.7.4 Metadata Creators 38
4.7.5 Metadata Tools 39
4.7.6 Metadata Use and Storage 40
4.7.7 Resource Description Model 41
4.7.8 Metadata Search and Retrieval 41
4.7.9 Benefits / Purposes of Deploying Metadata 42
5.1 Projects Ranked in Terms of Consistency on the Use of DC 43
Elements
Subelements
Schemes
vi
LIST OF FIGURES
Figure Page
2.1 Framework for Metadata Scheme Expansion 13
4.1 Percentage Consistency in the Use of DC Elements for 24
Each Project
4.2 Percentage Use by Projects for Each DC Element 25
4.3 Percentage Use of Local Element(s) and DC Elements 26
4.3.1 Subelement(s) Used for Title (A1) based on 16 Projects 27
4.3.2 Subelement(s) Used for Description (A5) based on 16 Projects 27
4.3.3 Subelement(s) Used for Coverage (A6) based on 11 Projects 27
4.3.4 Subelement(s) Used for Relation (A7) based on 8 Projects 28
4.3.5 Subelement(s) Used for Format (C2) based on 13 Projects 28
4.3.6 Subelement(s) Used for Date (C3) based on 16 Projects 28
4.4 Percentage Use of Local Subelements by DC Projects 29
4.5.1 Scheme(s) Used for Source (A2) based on 7 Projects 30
4.5.2 Scheme(s) Used for Language (A3) based on 16 Projects 31
4.5.3 Scheme(s) Used for Subject (A4) based on 16 Projects 31
4.5.4 Scheme(s) Used for Coverage (A6) based on 11 Projects 31
4.5.5 Scheme(s) Used for Relation (A7) based on 8 Projects 32
4.5.6 Scheme(s) Used for Type (C1) based on 14 Projects 32
4.5.7 Scheme(s) Used for Format (C2) based on 13 Projects 32
4.5.8 Scheme(s) Used for Date (C3) based on 16 Projects 33
4.5.9 Scheme(s) Used for Identifier (C4) based on 16 Projects 33
4.6 Percentage Use of Local Schemes by DC Projects 34
vii
CHAPTER 1
INTRODUCTION
1.1. Background on Metadata and the Dublin Core Metadata Initiative

(DCMI)
In 2001, the International Federation of Library Associations and Institutions
(IFLA) defined metadata as follows:
Metadata is data about data. The term refers to any data used to aid the
identification, description and location of networked electronic resources.
Many different metadata formats exist, some quite simple in their description,
others quite complex and rich.
According to the Dublin Core Metadata Initiative (“DCMI Frequently Asked

Questions,” 2001):
The simplest definition of metadata is "structured data about data." Metadata
is descriptive information about an object or resource whether it be physical or
electronic. While metadata itself is relatively new, the underlying concepts
behind metadata have been in use for as long as collections of information
have been organized. Library card catalogs represent a well-established type
of metadata that has served as collection management and resource discovery
tools for decades.
After a study of 27 potential definitions, American Library Association (ALA)

Committee on Cataloging: Description and Access (CC:DA) submitted a formal
working definition:
Metadata are structured, encoded data that describe characteristics of
information-bearing entities to aid in the identification, discovery, assessment,
and management of the described entities.
While metadata is a relatively new term adopted by the library and information
science community, based on the above definitions, what is most intriguing is its
similarity to the traditional MAchine-Readable Cataloging (MARC) standard (Library
1
of Congress, 2001b) used for library OPACs (Online Public Access Catalogs)
developed decades ago.
In the context of this research, metadata would be treated as any structured

descriptions that aid in the discovery of networked electronic resources.
As Lee-Smeltzer (2000) aptly pointed out, the phenomenal growth of digital

resource on the Internet, their lack of organization, and the deficiency of the search
tools currently available, make searching for information on the Internet comparable to
looking for the proverbial “needle in a haystack”. Due to the inadequacy of Internet
search engines, information providers, including catalogers from libraries, metadata
experts, publishers and many others began to realize that something must be done to
enable better retrieval and discovery of their electronic resources that would be useful
to their customers or clientele. From the efforts by different information providers,
metadata standards began to evolve in many different directions under the various
groups of professionals who are actively involved.
Dublin Core Metadata Element Set (DCMES) is a metadata standard employed

by a wide variety of communities. Originally conceived for author-generated
description of Web resource, it has also attracted the attention of formal resource
description communities such as archives, museums, libraries and other information
providers (Weibel, 1997). Today, DCMES, now translated into twenty-five languages
(Andresen, 2000), has become the de facto standard for describing Internet resources
in many countries including Australia, Europe and North America (“Dublin Core
Releases New Recommended Qualifiers,” 2000; Weibel & Koch, 2000).
The Dublin Core is a 15-element metadata element set intended to facilitate

discovery of electronic resources. The Dublin Core has been in development since
1995 through a series of focused invitational workshops, sponsored by the Online
Computer Library Center (OCLC) and other organizations, that gather experts from the
library world, the networking and digital library research communities, and a variety of
content specialties (Hillmann, 2001). In addition to the DC elements, DCMI also
released its first formal recommendation on the use of DC qualifiers, meant to enhance
2
the semantic precision of the existing DCMES, approved by the Dublin Core Usage
Committee in July 2000 (“Dublin Core Qualifiers,” 2000).
One of the reasons for such popularity of Dublin Core metadata standard is
probably due the four characteristics of DC elements: simplicity, semantic
interoperability, international consensus, and extensibility. However, Dublin Core
metadata standard is still quite unstable due to its relatively short history of
development. Revisions and refinements are continually made to DCMES in order to
accommodate the specific needs and purposes of its practitioners. This has made it
difficult for any evaluation to be done on the effectiveness of the use of DCMES.
Although a variety of guidelines have been developed over the years, there is still a
lack of documentation on how this metadata standard can be deployed effectively.
1.2. Problem Statement

This research is aimed at investigating and exploring the various ways in which
DCMES has been used to organize information on the Internet (i.e., Web pages or Web
objects). At the same time, it is also intended to examine the four characteristics that
are intrinsic to the DC elements and their influence on metadata. The main focus is to
find out to what extent have these DC projects adopted the DC elements and whether
recommended qualifiers – element refinement and encoding schemes, have been used
together with the adopted DC elements. In this way, the effectiveness of the DCMES
in the description of networked electronic resources will be evaluated.
The study attempted to focus on the following specific objectives:

! To find out how consistently DCMES has been adopted.
! To find out how consistently the qualifiers recommended by DCMI have
been used.
! To evaluate the perceived usefulness and importance of DC metadata
elements and qualifiers – element refinement and encoding scheme.
! To examine the metadata schemas adopted by DC projects in relation to
DCMES.
! To discover how DC metadata was created and who was involved in the
metadata creation.
3
! To explore the deployment, storage and retrieval of DC metadata for

discovery of electronic resources
! To examine the various applications of DCMES in DC projects and identify
the trends
This is an exploratory study on the use of DCMES by project implementors. The

results are expected to be useful to future implementors of DC projects by providing
information on the type of deployment models most suited for DC metadata.
Moreover, the study will also indicate how well can DC metadata be used to describe
various types of digital objects, especially Web pages and networked digital resources.
1.3. Organization of Dissertation Chapters

This study will start by examining and reviewing related and relevant literature
and research, both in print and on the Internet. This will be followed by description of
the methodology used for the research, including how the sample was selected and the
instrument used for data collection. The data collected will be presented in the
“findings” chapter, continued by analysis and interpretation of the data in the
“discussion” chapter. Summary and conclusions of this study will be provided at the
end of the dissertation.
4
CHAPTER 2
LITERATURE REVIEW
Initially this chapter was intended to review only related research. Considering
the emerging field of metadata, it was considered that the inclusion of literature on
general aspects of the subject would be useful.
2.1. Metadata in General

During the period of 1996 to 1998, much of the literature published on
metadata standards and the Dublin Core were centred on reviews of and overviews of
the available metadata standards. These reviewing literature can be divided into a
several distinctive clusters. The first cluster grouped the earliest research attempts at
describing and reviewing the large number of metadata standards that have evolved for
describing electronic resources, including Dublin Core (e.g., BIBLINK, 1996;
Dempsey & Heery, 1997; Heery, 1996; Taylor, A. G., 1999).
Heery (1996) was the first to review five metadata formats - Dublin Core,
MARC, Internet Anonymous Ftp Archive (IAFA) templates, Text Encoding Initiative
(TEI) headers and Universal Resource Characteristics (URCs) - chosen for their
particular relevance to those working within the UK eLIB projects. Comparison was
done in the context of the requirements of bibliographic control, with reference to the
suitability of the various record formats for this purpose. The criteria for comparison of
record characteristics were:
(1) Constituency (Who is actively using this record format? Is it associated

with a particular professional interest or academic discipline? etc.)
(2) Ease of creation (Are special skills required to formulate the records?
Are the records designed created by the information ‘publisher’ or
centrally by service providers? etc.)
(3) Content - the record structure, content designation and rules for
formulation of data element content
5
(4) Associated Internet protocols - whether particular metadata formats can

be carried by existing Internet protocols and whether a database of that
metadata format can be searched using existing Internet protocols
(5) Progress towards international standard status.
Following that, two separate metadata projects - BIBLINK (1996) and DESIRE
(Dempsey & Heery, 1997) - carried the research one step further to assess and further
analyze many other metadata standards. Dublin Core was also one of the metadata
standards analyzed in order to provide recommendations on which metadata standard
was more suited for deployment to meet the project’s objectives. To date, research
done by DESIRE project is the single most comprehensive and extensive survey of
over twenty metadata standards, including review of issues such as consideration of the
environment of use, format issues, protocol issues and implementation.
The DESIRE research was also among the first to point out that it is unlikely
that some monolithic metadata format will be universally used. This is for a number of
more or less well known reasons, not least the investment represented by legacy
systems in terms of technology and human effort. In addition the variety of record
formats represent an attempt to meet the diverse requirements of the different
communities. The various communities involved in resource description have vested
significant effort in developing specialized structures to enable rich record descriptions
to be created to fulfil the requirements of their particular domain. These structures are
embodied in systems. In addition the people who maintain these structures have
developed considerable detailed knowledge and skills of a specialist nature. For these
reasons it is unlikely that one format will fulfil their diverse requirements.
Metadata implementors began to realize that interoperability between different

metadata standards was the key to providing cross-domain access to distributed
systems. With this realization, metadata crosswalks, which support conversion projects
and semantic interoperability to enable searching across heterogeneous distributed
databases, became the main focus in metadata development (Baca, 2000; “Crosswalk
from the Alexandria metadata schema,” 1997; Day, Michael; Library of Congress,
2001; State and University Library at Göttingen, 2000).
6
Especially of interest to the library community would be “Dublin

Core/MARC/GILS Crosswalk” provided by Library of Congress, Network
Development and MARC Standards Office (2001a), where a crosswalk between the
fifteen elements in the Dublin Core Element Set and MARC 21 bibliographic data
elements was presented. In addition, it includes a crosswalk from Dublin Core to GILS
attributes. It also stated that a mapping between the elements in the Dublin Core and
USMARC fields is necessary so that conversions between various syntaxes can occur
accurately. Once Dublin Core style metadata is widely provided, it might interact with
MARC records in various ways such as the following:
a) Enhancement of simple resource description record - a cataloging

agency may wish to extract the metadata provided in Dublin Core style
(presumably in HTML or XML) and convert the data elements to
MARC fields, resulting in a skeletal record. That record might then be
enhanced as needed to add additional information generally provided in
the particular catalog. Some projects convert data and use as basic
record for reporting to national bibliography.
b) Searching across syntaxes and databases - libraries have large systems

with valuable information in metadata records in MARC format. Over
the past few years with the expansion of electronic resource over the
Internet, other syntaxes have also been considered for providing
metadata. It will be important for systems to be able to search metadata
in different syntaxes and databases and have commonality in the
definition and use of elements.
Another good example is the book entitled “Introduction to metadata: pathways

to digital information” edited by Murtha Baca (2000), where an extensive mapping of
various elements in different metadata standards was listed in tables that spread across
many pages. In particular, a crosswalk of eight metadata element sets including Dublin
Core was provided for art, architecture, and cultural heritage information and online
resources.
7
2.2. Dublin Core Metadata Initiative (DCMI)

The second literary clusters essentially focused on the proceedings and reports
from the Dublin Core Workshops, since its first meeting in 1995 to its eighth meeting
in 2000. These papers and reports form the largest portion of the literature on Dublin
Core, with many of them available either in print or freely available on the Internet
(Dempsey & Weibel, 1996; Weibel, 1999; Weibel & Hakala, 1998; Weibel, Iannella
and Cathro, 1997; Weibel & Koch, 2000; Weibel & Lagoze, 1997).
Thiele (1998) gave a most exhaustive and convincing review of the literature
available from March 1995 to September 1997 based on Dublin Core. In the review,
D-Lib Magazine (http://www.dlib.org) and Ariadne (http://www.ariadne.ac.uk) were
identified as two of the most popular outlets for publishing information about the
Dublin Core and Warwick Framework. Key documents and key researchers – Stuart L.
Weibel (a Senior Research Scientist with the Office of Research and Special Projects
at OCLC), Carl Lagoze (Head of the Cornell Digital Library Research Group at
Cornell University) and Renato Iannella (Senior Research Scientist at the Distributed
Systems Technology Centre in Brisbane, Australia) – were also identified. However,
no other review of such scope has been collated since then.
The third cluster consists of the main flow of literature that describe important
issues, key considerations and challenges faced by implementors of metadata
standards, especially with regard to Dublin Core. A typical paper would describe the
metadata deployment model, how DCMES could be used and stored, with emphasis on
metadata creation procedure and problems (Hillmann, 2001; Hodgson, 1998; Lange &
Winkler, 1997; Taylor, Chris, 1999; Weibel, 1997).
Hodgson (1998) described aptly three areas in which challenges must be met in
creating metadata: resource description, metadata production and interoperability.
Weibel (1997) came up with three models for deploying Dublin Core Description on
the Web:
(1) Embedded Metadata

The easiest way of deploying metadata on the Web is by embedding it
in HTML documents (using the META tag). The advantage of
8
embedded metadata is that no additional system must be in place to use

it.
(2) Third Party Metadata
A model more familiar to the library community includes what is
known in Web parlance as a third party label bureau, that is, an entity
that collects and manages metadata records that refer to resources but
are not embedded in the resource (a library catalog, for example). This
model is important not only to libraries and museums, but also supports
the development of agencies that might label resources according to age
appropriateness or other acceptability criteria.
(3) View Filter
A third model also involves management of records by a distinct entity,
but not necessarily Dublin Core records per se. Managing a wide variety
of data stores often involves reconciling very different description
models. One approach to achieving interoperability in such an
environment involves mapping many description schemas into a
common set such as the Dublin Core, giving users a single query model.
Weibel (1997) concluded “much remains to be done to bring the Dublin Core
to a state of sufficient maturity and stability to fulfill its promise as a foundation for
resource discovery on the Net”. He pointed out unsolved problems and future
directions in the development of Dublin Core. These included continued refinement of
Dublin Core elements, user education and application guides, metadata registries, tools
for creation and management of Web-based metadata, and formalized standards of best
practice.
Both Rusch-Feja (1998) and Taylor (1999) described three ways of deploying
and storing metadata:
(1) Embedded in the HTML coding of a Web page using META tags.
(2) As a separate HTML document linked to the resource it describes (the
resource being a non-HTML-file, for example sound, image, or program
file).
(3) In a database linked to the resource. The records may have been directly
9
created within the database or extracted from another source, such as

Web pages (by harvesting and / or search engine).
Besides dealing with issues regarding metadata deployment, several other

descriptive guidelines have also been written on the process or procedure for metadata
deployment (Campbell, 1999; Hudgins, 1999; Thornely, 1999). Theme usually
encompasses the selection of collection, target audience, scope and depth of metadata
cataloging provided, metadata record design and structure, and staffing. For
deployment of Dublin Core, decisions for the metadata schema and use of qualifiers
were also important considerations during the process.
2.3. Applications of Metadata Standard (with focus on Dublin Core)

In the recent two years, more papers have been published regarding the
applications of Dublin Core standard, especially for digital or digitized collections in
the context of digital libraries. Most of the research described the planning and
implementation process, while others were experimental and exploratory especially on
the use of Dublin Core elements. However, only a few of the research attempted to
evaluate the effectiveness of using DC elements for description.
A large amount of information and documentation, both in print and on the

Internet, about projects which experimented and implemented Dublin Core metadata
standard, could be found. Most of these publications consisted of information on the
implementation process, the goals of the projects, why Dublin Core metadata standard
was chosen, the metadata schemas adopted, and metadata creation procedures and
guidelines. A most comprehensive list of DC project web sites arranged in alphabetical
and geographical order is provided at the Dublin Core Metadata Initiative Projects
Web page at http://dublincore.org/projects/ (“DCMI Projects,” 2001).
Zeng (1999) reported on a project that applied existing metadata formats to

Kent State University Museum’s collection of fashionable and traditional costumes
from the eighteenth through the twentieth centuries. An evaluation of how DCMES
could be applied to such a collection containing digitized image of three-dimensional
museum objects was done in comparison to two other metadata standards – United
10
States MAchine-Readable Cataloging (USMARC) format, and the Visual Resources

Association (VRA) Core Categories for Visual Resource.
The format testing involved creating metadata records using the three specified
metadata standards for a selected sample collection. Strengths and weaknesses of each
format when applied to a specific costume item were assessed element by element,
using criteria such as richness of content and structural presentation in a record, as well
as productivity and quality of cataloging. It was interesting to note that though VRA
Core was adopted finally, Zeng (1999) stated that “it may still be possible for an
enhancement of DC to meet the needs of describing three-dimensional objects, like
those for describing images”. This study would probably set the stage for more similar
exploratory or experimental research to be done, especially for digital objects or
formats not yet explored by existing metadata standards, including DC.
Vercoustre (1999) who stated that “there is very little report on the use of DC
metadata for images and photographs” experimented further with the usability of
Dublin Core for interoperable photographs metadata in a CD-ROM, together with
more detailed XML descriptions to support a specific multimedia application.
However, no evaluation or comparison with other metadata standards was made.
In another research paper, Fullerton, Greenberg, McClure, Rasmussen, and

Stewart (1999) addressed the design problems of a digital library project named
“PEN-DOR (Pennsylvania Educational Network Digital Object Repository)” that
adopted GEM Metadata Standard. Problems included the design of a distributed,
object-oriented database architecture, the description and cataloguing of multimedia
objects, and issues related to usability and training for a geographically scattered user
community. The PEN-DOR team elected to use GEM because it not only incorporates
the DC’s fifteen core elements, but is made richer by the inclusion of additional
domain-specific elements, such as ‘pedagogy’ and ‘grade level’, which are necessary
for the description of educational resources.
This implied that scenarios where a second generation of metadata standards

(developed based on an empirical standard such as DC, etc) is adopted or used in
11
preference, would become more common as the new generation of metadata standards
are able to cater for more specific usage.
Special mention was made as to how the metadata elements were created –
either user supplied or system generated. As more complex metadata architecture was
built in digital library systems, system generated elements would probably play a
bigger role as compared to other simple metadata deployment models.
From the above examples, it can be seen that research done on the applications
of DC standard can generally be divided into two different types: (1) theoretical
exploration of the element set and possible applications to different or specific types of
electronic or web objects, and (2) experimenting with metadata models for the
application of DC standard.
The only research that surveyed the current use of meta fields by non-
information professional and attempted to review and compare the use of DCMES by
information professionals among five DC projects was done by Qin (1998). This is the
first research of its kind to provide valuable insights into the whole process of
computational representation of Web objects in a subject domain, through a four-part
research design, each targeting different aspects of metadata creation and application,
that focused on DC metadata scheme adoption and expansion.
Although only a handful of DC projects, limited to those in scientific domains,

were reviewed, the results revealed that these DC projects used three different methods
in expanding DC: (1) developed local subelements under fifteen DC elements, (2) used
DC for describing basic information but developed new elements under local
namespace for specialized needs, and (3) created new elements under namespaces
based on DC.
Summarizing these three methods in expanding DC, it can be seen that the
multidimensionality of Web objects were expressed in several different areas (see the
triangle in Figure 2.1). The bottom three are DC's content, rights, and instantiation
packages that have appeared in many metadata projects as basic elements. As the
description areas move to the top, metadata elements become more specialized and
12
individualized. In reality, the nature of all these description areas may differ little from
namespace to namespace, but large variations can be expected in naming individual
elements. Most namespaces currently in use in scientific disciplines are
organizationally bound, and very few of them are disciplinary oriented.
Figure 2.1 Framework for Metadata Scheme Expansion (Source: Qin, 1998)
With more and more organizations, disciplines, industries and businesses

joining the concert of metadata creation, the importance of metadata scheme and
namespace control cannot be emphasized enough. To realize the goal of
interoperability, being compliant with DC is inadequate. Discipline- (subject domain),
industry-, and businesswide metadata namespaces will be necessary to provide the
standard and consistency in metadata for networked resource discovery.
Other interesting points raised were that the DC projects were all institutionally
oriented, except the Medical Core Metadata project which was the only discipline-
wide metadata scheme development. The research concluded that these projects
represent a movement of retro-encoding in current metadata effort within the
information professional community-either from libraries or information centers, or
from research institutions. The researcher predicted that the retro-encoding trend
would continue to grow as the digital resources grow. As metadata technology
13
becomes mature, an increase in non-information professional metadata creation could

also be expected, that is, metadata encoding would become synchronous with Web
object creation. The research also recommended that librarians and information
professionals would need to work with professional societies and industries to develop
discipline- and industry-wide metadata schemes and accelerate metadata tool
development for both retro- and synchronous-encoding.
14
CHAPTER 3
METHODOLOGY
This chapter will provide details for the source of data collection, the method
used and how the sample was selected. Due to the abundance of Dublin Core project
documentation and information available on the Internet, the research involved
surveying the web sites of Dublin Core projects, with the use of a carefully constructed
checklist.
3.1. Selection of Dublin Core Projects

The most comprehensive listing of Dublin Core projects is found at the DCMI
Projects Web page at http://dublincore.org/projects/ (“DCMI Projects,” 2001).
Initially, all the Dublin Core projects listed there were taken into consideration and a
brief review of the project web sites with the checklist constructed gave an idea of
whether sufficient information could be obtained for each section of the survey. A total
fifty-seven project web sites were explored initially.
However, some of the projects were either in foreign languages or lack detailed
definition and explanation for the metadata elements that has been adopted. As the
main focus was to make comparisons between the metadata schema used and DCMES,
the number of DC projects was reduced to twenty-two. Out of the remaining twenty-
two DC projects, sixteen were finally selected for the survey as sufficient and useful
information could be gathered for all main sections of the survey.
The following sixteen projects were selected:
1) Australian Digital Theses Program (ADTP)

URL: http://adt.caul.edu.au
2) Australiasian Virtual Engineering Library (AVEL)
URL: http://avel.edu.au
15
3) BIBLINK (BIBLINK)
URL: http://hosted.ukoln.ac.uk/biblink
4) Business Entry Point (BEP)
URL: http://www.business.gov.au
5) Catalog and Index for French Speaking Health Sites (CISMeF)
URL: http://www.chu-rouen.fr/cismef/cismefeng.html
6) Colorado Digitization Project (Colorado)
URL: http://coloradodigital.coalliance.org
7) Education Network Australia (EdNA)
URL: http://www.edna.edu.au
8) European Libraries and Electronic Resources in Mathematical Sciences
(EULER)
URL: http://www.emis.de/projects/EULER/
9) Florida International University Digital Library (FIU DL)
URL: http://fiudl.fiu.edu/
10) Gateway to Educational Materials (GEM)
URL: http://www.thegateway.org/
11) The Foundations Project - Bridges: Minnesota’s Gateway to
Environmental Information (Minnesota)
URL: http://bridges.state.mn.us/
12) NewsAgent (NewsAgt)
URL: http://www.sbu.ac.uk/litc/newsagent/
13) State Library of Queensland Metadata Project (Queensld)
URL: http://www.slq.qld.gov.au/meta/
14) SAFARI (SAFARI)
URL: http://safari.hsv.se/index.html.en
15) Scout Report Signpost, now called “Scout Report Archives” (Scout)
URL: http://scout.cs.wisc.edu/addserv/signpost/
16) Swedish EnviroNet (Swedish)
URL: http://smn.environ.se/miljonat/english/index.htm
Project codes, listed beside each project title, were used in this study to provide for
easy references.
16
3.2. Data Collection

From the literature reviewed, it was observed that there have not been extensive
research done on projects that made use of the DCMES (“Dublin Core Metadata
Element Set, Version 1.1,” 1999). In particular, no attempt had been made to measure
the consistency of the deployment of DCMES by these projects.
In view of that, I have decided to carry out an exploratory survey of DC

projects web sites in order to find out the metadata schemas used and to investigate the
nature of these projects.
After studying the results of an earlier survey conducted for thirty-two DC

projects during the fifth Dublin Core Metadata Workshop in 1997
(http://linnea.helsinki.fi/meta/projects.html), a similar checklist was drafted initially.
On further review of the literature, a more comprehensive checklist (see Appendix A)
was constructed based on the key issues raised by several prominent “players” in the
field of metadata and cataloging.
The survey form was divided into seven sections, each section intending to
examine specific issues pertinent to metadata deployment and application:
(a) Resource submission and selection
(b) Collection scope and coverage
(c) Metadata creators
(d) Metadata deployment and retrieval
(e) Metadata schema
(f) Tools and aids for metadata creation
(g) Project achievements
Each of the above section was made up of a mixture of open-ended and

multiple-choice questions. Data was gathered by reviewing the information and
documentation available at each project web site. Published literature containing
information relevant to the checklist were also reviewed and incorporated into the
survey results, in order to gather more extensive data and enhance the analysis process.
17
Data collected for section (e) will be compared to DCMES (“Dublin Core
Metadata Element Set, Version 1.1,” 1999) and the Dublin Core Qualifiers (2000).
Each DC element, subelement, and scheme was given a separate code for easier
referencing (see Table 3.1). Information on the projects’ metadata metadata schemas
used for comparison with DCMES is presented in Appendix B.
All the other sections helped to provide an overview of the project nature and
goals. Such data might also give insights or clues for explanation of data collected
from Section (e). There may also be correlation between data collected from different
sections of the survey.
Due to the varying nature of the data to be collected in the survey, both
quantitative and qualitative analysis would be carried out. It was expected that
quantitative data would be collected and presented predominantly from section (e). It
was also planned that results from section (e) of the survey would be supported by
qualitative analysis of the other remaining sections.
One of the problems faced when surveying web sites was that information on
the Internet could be updated frequently and instantly. Due to the large amount of
information and documentation available at some of the project Web sites, much time
was required to systematically go through the hyperlinks provided, in order not to miss
out certain sections while navigating through these Web sites. The information was
saved and printed where possible in order to keep track of which sites and documents
had been read and surveyed.
However, some of these DC projects were more active, thus their Web sites
underwent revision quite frequently. Thus, information and data collected may not
reflect the latest versions of the metadata schema adopted.
18
Table 3.1: Summary of DCMES and Qualifiers

DCMES Element Element Refinements (s) Element Encoding Scheme (s)
Title (A1) Alternative (R) -
Creator (B2) - -
Subject (A4) - LCSH (S1)
MeSH (S2)
DDC (S3)
LCC (S4)
UDC (S5)
Description (A5) Table of Contents (R1) -
Abstract (R2)
Publisher (B1) - -
Contributor (B3) - -
Date (C3) Created (R1) DCMI Period (S1)
Valid (R2) W3C-DTF (S2)
Available (R3)
Issued (R4)
Modified (R5)
Type (C1) - DCMI Type Vocabulary (S)
Format (C2) Extent (R1) IMT (S)
Medium (R2)
Identifier (C4) - URI (S)
Source (A2) - URI (S)
Language (A3) - ISO 639-2 (S1)
RFC 1766 (S2)
Relation (A7) Is Version Of (R1) URI (S)
Has Version (R2)
Is Replaced By (R3)
Replaces (R4)
Is Required By (R5)
Requires (R6)
Is Part Of (R7)
Has Part (R8)
Is Referenced By (R9)
References (R10)
Is Format of (R11)
Has Format (R12)
Coverage (A6) Spatial (R1) DCMI Point (S1)
ISO 3166 (S2)
DCMI Box (S3)
TGN (S4)
Temporal (R2) DCMI Period (S5)
W3C-DTF (S6)
Rights (B4) - -
Note
DC Elements with code prefix “A” belongs to “Content” category.
DC Elements with code prefix “B” belongs to “Intellectual Property” category.
DC Elements with code prefix “C” belongs to “Instantiation” category.
19
3.3. Presentation of Data

Quantitative data collected from Section (e) of the checklist will be presented in
tables, and percentage calculations presented in bar charts and pie charts whenever
possible, in order to provide a clearer illustration. Qualitative data collected from the
remaining sections of the checklist was tabulated initially, however, only significant
and important data will be presented in tables in the next chapter.
20
CHAPTER 4
FINDINGS
In this chapter, results from the survey of sixteen Dublin Core projects listed in
the previous chapter will be documented under two main sections:
a) Comparison of Metadata Schema with DCMES (Version 1.1, 1999) and
Dublin Core Qualifiers (2000)
b) Overview of Metadata Projects
The predominant quantitative data came from analysis of the metadata schemas
adopted by these 16 projects. DCMI recognizes two broad classes of qualifiers (see
Table 3.1):
a) Element Refinements: qualifiers that make the meaning of an element
narrower or more specific.
b) Encoding Scheme: qualifiers that aid in the interpretation of an element
value. These schemes include controlled vocabularies and formal notations
or parsing rules.
Each element refinement was given a code with prefix R (i.e. R1, R2, etc.) and each
encoding scheme was given a code with prefix S (i.e. S1, S2, etc.) in order to identify
them more easily in the representation of data.
4.1. Consistency with the Use of Dublin Core Elements

The Dublin Core (DC) elements adopted by the sixteen projects surveyed were
tabulated in Table 4.1. Eight of the fifteen DC elements - Title (A1), Language (A3),
Subject and Keywords (A4), Publisher (B1), Creator (B2), Contributor (B3), Date
(C3), and Resource Identifier (C4) - were adopted by all the projects surveyed. These
eight DC elements came from all three categories of description: content, intellectual
property and instantiation. From the projects’ perspective, six of the sixteen projects
surveyed adopted all the fifteen DC elements elements in their metadata schemas. The
six projects are BEP, Colorado, EdNA, FIU DL, Minnesota and Queensld.
21
Table 4.1 Overview of Dublin Core Elements Adopted by Each Dublin Core Project
Dublin Core Elements Used

Content Intellectual Property Instantiation
Project
Title Source Language Subject Description Coverage Relation Publisher Creator Contributor Rights Type Format Date Identifier Total
(A1) (A2) (A3) (A4) (A5) (A6) (A7) (B1) (B2) (B3) (B4) (C1) (C2) (C3) (C4)
ADTP !" #" !" !" !" #" #" !" !" #" !" #" #" !" !" 9
AVEL !" #" !" !" !" !" !" !" !" !" !" !" !" !" !" 14
BEP !" !" !" !" !" !" !" !" !" !" !" !" !" !" !" 15
BIBLINK !" !" !" !" !" #" #" !" !" !" !" #" !" !" !" 12
CISMeF !" #" !" !" !" #" #" !" !" #" !" !" !" !" !" 11
Colorado !" !" !" !" !" !" !" !" !" !" !" !" !" !" !" 15
EdNA !" !" !" !" !" !" !" !" !" !" !" !" !" !" !" 15
EULER !" #" !" !" !" #" #" !" !" !" !" !" !" !" !" 12
FIU DL !" !" !" !" !" !" !" !" !" !" !" !" !" !" !" 15
GEM !" #" !" !" !" !" !" !" !" #" !" !" !" !" !" 13
Minnesota !" !" !" !" !" !" !" !" !" !" !" !" !" !" !" 15
NewsAgt !" #" !" !" !" !" #" !" !" #" #" !" !" !" !" 11
Queensld !" !" !" !" !" !" !" !" !" !" !" !" !" !" !" 15
SAFARI !" #" !" !" !" !" #" !" !" #" #" !" #" !" !" 10
Scout !" #" !" !" !" #" #" !" !" !" #" !" !" !" !" 11
Swedish !" #" !" !" !" !" #" !" !" #" #" !" #" !" !" 10
Total Projects 16 7 16 16 16 11 8 16 16 10 12 14 13 16 16
Key: #= Not Adopted; !"= Adopted
From Table 4.1, two bar charts were plotted: one showing the percentage
consistency calculated for the usage of all DC elements (see Figure 4.1) and the other
showing the percentage of projects that adopted each DC element (see Figure 4.2).
Figure 4.1 showed that more than 50% of the DC elements were adopted by all sixteen
project and Figure 4.2 showed that Source (A2) and Relation (A7) were less frequently
adopted by the projects.
Besides the usage of DC elements in the projects surveyed, many of them

developed their own local (non-DC) metadata elements or adopted other standards’
metadata elements as well. In order to understand the use of such elements, the names
and definitions of these elements were listed in Appendix E. The percentage proportion
of use of local elements as compared to the DC elements was calculated and presented
in Figure 4.3.
4.2. Consistency with the Use of DC Qualifiers – Element Refinements

Each element refinement recommended by DCMI is identified as a subelement.
Raw data collected on the use of subelements is presented in Appendix C. As shown in
Table 3.1, six of the fifteen DC elements - Title (A1), Description (A5), Coverage
(A6), Relation (A7), Format (C2) and Date (C3) - have DCMI-recommended
subelement(s). A series of pie charts (Figure 4.3.1 to 4.3.6) was drawn for each
element, based on the percentage of projects using at least one DCMI-recommended
subelement, the percentage of projects using local subelements only, and the
percentage of projects not using any subelements at all. The percentage of projects was
calculated based on the total number of projects that adopted that particular DC
element.
It was observed that most of the projects used at least one subelement(s)
recommended by DCMI for Coverage (A6), Relation (A7) and Date (C3) elements.
The majority of the projects, however, did not use any subelement recommended by
DCMI for Title (A1) – 23%, Format (C2) – 69% and Description (A5) – 75%
elements. Only a small percentage of the projects ranging from 10% to 13% developed
local subelements for all six DC elements.
23
ADTP 60
AVEL 93
BEP 100
BIBLINK 80
CISMeF 73
Colorado 100
EdNA 100
EULER 80
Project
FIU DL 100
GEM 87
Minnesota 100
NewsAgt 73
Queensld 100
SAFARI 67
Scout 73
Swedish 67
0 20 40 60 80 100
Percentage Consistency (% )
Figure 4.1: Percentage Consistency in the Use of DC Elements for Each Project
24
Title (A1) 100
Source (A2) 44
Language (A3) 100
Subject and Keywords

100
(A4)
Description (A5) 100
Coverage (A6) 69
Relation (A7) 50
DC Element
Publisher (B1) 100
Creator (B2) 100
Contributor (B3) 63
Rights Management
75
(B4)
Resource Type (C1) 88
Format (C2) 81
Date (C3) 100
Resource Identifier
100
(C4)
0 20 40 60 80 100
Percentage Use by Projects (% )
Figure 4.2: Percentage Use by Projects for Each DC Element
25
ADTP 100
AVEL 74 26
BEP 88 12
BIBLINK 63 37
CISMeF 58 42
Colorado 100
EdNA 65 35
Project
EULER 55 45
FIU DL 79 21
GEM 62 38
Minnesota 100
NewsAgt 92 8
Queensld 88 12
SAFARI 91 9
Scout 61 39
Swedish 100
0 20 40 60 80 100
Percentage Use (% )
Percentage of DC Elements Adopted (%) Percentage of Local Elements Adopted (%)
Figure 4.3: Percentage Use of Local Element(s) and DC Elements
26
Title (A1)
44%
56%
0%
Projects Using Subelement(s) Recommended by DCMI

Projects Using Local Subelement(s) Only
Projects Not Using Subelements
Figure 4.3.1: Subelement(s) Used for Title (A1) based on 16 Projects
Description (A5)
25%
0%
75%
Figure 4.3.2: Subelement(s) Used for Description (A5) based on 16 Projects
Coverage (A6)
9%
0%
91%
Figure 4.3.3: Subelement(s) Used for Coverage (A6) based on 11 Projects
27
Relation (A7)
13%
13%
74%
Figure 4.3.4: Subelement(s) Used for Relation (A7) based on 8 Projects
Format (C2)
23%
8%
69%
Figure 4.3.5: Subelement(s) Used for Format (C2) based on 13 Projects
Date (C3)
13%
6%
81%

Figure 4.3.6: Subelement(s) Used for Date (C3) based on 16 Projects
28
Table 4.2 was presented to find out which of the surveyed projects most
consistently followed all the subelement recommendations (based on raw data
collected in Appendix C). As some of the projects adopted local subelements not
specified in the DCMES, a bar chart (see Figure 4.4) was plotted in order to find out
whether local subelements had been widely adopted.
Table 4.2: Projects Consistent with the Use of Qualifiers – Element Refinement
DC Element Percentage of Project that Project Consistent with the use of
Used All DC Subelement(s) Qualifiers - Element Refinement
Title (A1) 44% AVEL, BIBLINK, EdNA, EULER, FIU
DL, Queensld, Scout
Description 13% EdNA, Minnesota
(A5)
Coverage (A6) 64% AVEL, Colorado, EdNA, FIU DL, GEM,
Minnesota, Queensld
Relation (A7) 13% EdNA
Format (C2) 15% EdNA, GEM
Date (C3) 6% EdNA
Source (A2) 71 29
Language (A3) 94 6
Subject (A4) 81 19
Publisher (B1) 56 44
DC Element
Creator (B2) 31 69
Contributor (B3) 30 70
Rights (B4) 83 17
Type (C1) 100
Identifier (C4) 94 6
0 20 40 60 80 100
Percentage of Projects (% )
Percentage of Projects W ithout Subelement (%)

Percentage of Projects W ith Subelement(s) (%)
Figure 4.4: Percentage Use of Local Subelements by DC Projects
29
4.3. Consistency with the Use of DC Qualifiers – Encoding Schemes

According to Table 3.1, nine of the sixteen DC elements - Source (A2),
Language (A3), Subject (A4), Coverage (A6), Relation (A7), Type (C1), Format (C2),
Date (C3) and Identifier (C4) - have DCMI-recommended schemes.
Raw data collected on the use of schemes is presented in Appendix D. A series

of pie charts (Figure 4.5.1 to 4.5.9) was drawn for each element, based on the
percentage of projects using at least one DCMI-recommended scheme, the percentage
of projects using local schemes only, and the percentage of projects not using schemes
at all. Again, the percentage of projects was calculated based on the total number of
projects that adopted that particular DC element.
It was observed that the most of the projects surveyed adopted either DCMI-
recommended schemes or their own local schemes. The percentage of projects not
using any scheme ranged from 0% to 29%. In fact, all projects used schemes for four
of the nine DC elements – Language (A3), Subject (A4), Type (C1) and Identifier
(C4).
Following that, Table 4.3 was presented to find out which of the surveyed
projects most consistently followed all the scheme recommendations (based on raw
data collected in Appendix D). As some projects adopted local schemes not specified
in the DCMES, a bar chart (see Figure 4.6) was plotted in order to find out whether
local schemes had been adopted widely.
Source (A2)
29% 29%
42%
Projects Using Scheme(s) Recommended by DCMI
Projects Using Local Scheme(s) Only
Projects Not Using Scheme
Figure 4.5.1: Scheme(s) Used for Source (A2) based on 7 Projects
30
Language (A3)
13% 0%
87%

Figure 4.5.2: Scheme(s) Used for Language (A3) based on 16 Projects
Subject (A4)
0%
38%
62%

Figure 4.5.3: Scheme(s) Used for Subject (A4) based on 16 Projects
Coverage (A6)
9% 27%
64%
Figure 4.5.4: Scheme(s) Used for Coverage (A6) based on 11 Projects
31
Relation (A7)
13%
25% 62%

Figure 4.5.5: Scheme(s) Used for Relation (A7) based on 8 Projects
Type (C1)
0%
50% 50%

Figure 4.5.6: Scheme(s) Used for Type (C1) based on 14 Projects
Format (C2)
15%
8%
77%

Figure 4.5.7: Scheme(s) Used for Format (C2) based on 13 Projects
32
Date (C3)
6%
44%
50%

Figure 4.5.8: Scheme(s) Used for Date (C3) based on 16 Projects
Identifier (C4)
6% 0%
94%

Figure 4.5.9: Scheme(s) Used for Identifier (C4) based on 16 Projects
Table 4.3: Projects Consistent with the Use of Qualifiers – Encoding Scheme
DC Element Percentage of Project Consistent with the Use of
Projects that Used Qualifiers – Encoding Scheme
All DC Scheme(s)
Source (A2) 29% EdNA, Queensld
Language (A3) 7% EdNA
Subject (A4) 10% EdNA
Coverage (A6) 33% EdNA
Relation (A7) 63% AVEL, Colorado, EdNA, GEM, Queensld
Type (C1) 50% AVEL, Colorado, EdNA, EULER, NewsAgt,
Queensld, Scout
Format (C2) 77% AVEL, BEP, BIBLINK, CISMeF, Colorado,
EdNA, EULER, GEM, Minnesota, NewsAgt
Date (C3) 14% EdNA
Identifier (C4) 94% ADTP, AVEL, BEP, BIBLINK, CISMeF,
Colorado, EdNA, EULER, FIU DL, GEM,
Minnesota, NewsAgt, Queensld, SAFARI,
Swedish
33
Title (A1) 81 19
Description (A5) 81 19
DC Element
Publisher (B1) 62 38
Creator (B2) 50 50
Contributor (B3) 40 60
Rights (B4) 25 75
0 20 40 60 80 100
Percentage of Projects (% )
Percentage of Projects Without Scheme (%)

Percentage of Projects With Scheme(s) (%)
Figure 4.6: Percentage Use of Local Schemes by DC Projects
4.4. Overview of Dublin Core Projects

Useful and significant results from the survey was tabulated whenever possible.
Table 4.7.1 showed details gathered on the resource submission and selection (see
Appendix A: Section A). Table 4.7.2 and 4.7.3 showed details gathered about the
collection (see Appendix A: Section B). Table 4.7.4 and 4.7.5 showed details gathered
about the metadata creation and tools (see Appendix A: Section C and F). Table 4.7.6,
4.7.7 and 4.7.8 showed details gather about the deployment and retrieval of metadata
(see Appendix A: Section D). Finally, Table 4.7.9 showed the benefits for using
metadata (see Appendix A: Section G).
From Table 4.7.1, all the sixteen projects restricted submission of resources to a
specified group of people, usually the project participants or consortium members.
Some of them allow resource submission from any interested party or individual as
well. Majority of the projects included a review process as well, with the use of some
selection criteria. As for the collection scope and coverage, the majority of the projects
34
- eleven of the sixteen projects - focused their collection to cater to specific subjects
and / or target audiences, such as business, engineering, education or environmental,
etc (as shown in Table 4.7.2). Some of the projects that did not focus their collection
on specific subjects or target audiences restrict the collection to specific geographical
location instead.
Table 4.7.1: Submission and Selection of Resources

Project Resource Submission Resource Selection
Submission by Specified Submission by Anyone Selection Criteria
Group
ADTP Post-graduate research students Nil Nil
at Australian University. Self-
submission by authors using the
ADT Deposit form.
AVEL Unique partnership between the Anyone can suggest a site – own site AVEL Resource
library community and the or any site by filling in Online Selection Criteria
engineering academic and Suggestion Form
professional communities
scattered across Australia.
Partner institutions, mainly
universities.
BEP Participating agencies in the Nil No information
initiative. Agents register provided.
resources / online services
through an online registration
system.
BIBLINK Publishers submit their Nil Tagged to requirements
bibliographic data via email or of the National
web interface to the BIBLINK Bibliographical
Workspace. Agencies (NBAs)
CISMeF One deputy librarian performs the A total of 672 health webmasters Uses Net Scoring
resource collection and the have sent them an Email or a specific (criteria to assess the
information watch. form to be indexed in CISMeF. quality of Health
Internet Information)
Colorado Accept digital resources created Nil (No personal collection) Reviewed based on
by established Colorado archives, collection policy.
historical societies, museums and
libraries that wish to participate in
a program to digitize and share
their resources with the people
Colorado via the Internet. Can fill
in online form to add other
project’s website or information
about a future digitization project
in planning.
EdNA EdNA users of the role Direct submission - anyone can “Core” items are
“Contributor”, education suggest & submit items i.e. URL approved and evaluated
community including a wide range using an online form according to EdNA
of educators, librarians, support content standards.
staff, associations, trainer and
students, professional groups.
EULER Participants and project partners. Anyone who wishes to submit a web Nil
site can register with the EULER
metadata creator.
35
FIU DL FIU faculty/departments or Nil Use scoring mechanism

individuals. on a worksheet for
selecting and prioritizing
new resources.
GEM GEM Consortium members. Nil Use an evaluation form.
Minnesota Project management Nil 13 selected state
agency web sites.
NewsAgt Consortium partners, publishers / Nil Nil
content providers.
Queensld Web authors in different Divisions Nil Nil
submit pages.
SAFARI Participating organizations or Anyone having research information Nil
members of SAFARI, i.e., informs SAFARI that it is available at
universities, university colleges a certain address during a certain
and other public research period of time.
organizations.
Scout Based on Scout Report. Also consider sites submitted by Scout Report Selection
readers. Criteria
Swedish Over 100 members (as at Jan Nil There are certain
2001) – Swedish governmental general requirements
agencies, companies and NGOs - that need to be filled in
are responsible for the order to become a
information content. member and also there
are certain quality
requirements regarding
the documents.
Table 4.7.2: Collection Scope and Coverage

Project Collection Scope and Coverage
Geographical Subject Others
ADTP Australian Universities All subjects Digitized Ph.D. (Doctor of Philosophy)
or a Masters Thesis (by research
only).
AVEL Resources or web sites Engineering and IT, The Built Nil
published in the Environment with an
geographic areas of emphasis on major areas of
Australia, New Zealand, research by participating
Papua New Guinea, and institutions.
other parts of the Asia
Pacific region
BEP Australia Information related to running Provides a single point of entry for
a business. Material useful for business to all levels of governments
target audiences: to assist resources from Commonwealth State,
business owners develop Territory, and local governments.
business, aim at business
community.
BIBLINK European National All subjects. Electronic documents have been
Libraries limited to those whose content makes
them suitable for inclusion in a
national bibliography. The scope
includes all those publications that
would traditionally be included in a
national bibliography in whatever
electronic medium they are
published.
36
CISMeF About 70% of the Healthcare disciplines and Main French language Internet
resources are located in medical sciences. resources
France, 16% are from
Canada, in particular the
Quebec Province, 4%
from Switzerland and
Belgium, and 3% from
Africa.
Colorado Colorado State Colorado history, culture, Nil
government and industry.
EdNA Australian curriculum Education & training – useful Nil
for teaching and learning.
Tools for Australian educators
and learners to use.
EULER Global Mathematical resources. Nil
FIU DL Latin America, Florida Current collections focus on Multimedia collections designed to
and FIU Latin American history and support the research and instructional
politics, decorative and goals of the University.
propaganda arts, ancient
architecture, the Florida
environment, religion, and
FIU history.
GEM U.S.A Links to state and national GEM Consortium members.
curriculum standard.
Educational - lesson plans
and teacher guides.
Minnesota Minnesota state Environmental and natural Minnesota state government
resources data and environmental agencies
information
NewsAgt Global Library and information Current awareness, up-to-date news
science.
Queensld Queensland University of All subjects Nil
State Library & Divisions
SAFARI Swedish All subjects Academic research information
Scout Global All subjects Based on Scout Reports.
Swedish Swedish Environment & environmental Swedish governmental agencies,
work, information and data companies and non-government
organizations (NGOs).
Table 4.7.3 showed that almost all the projects used DC elements to describe
either web pages or networked electronic resources, or a combination of both. Only
three of the projects used DC elements to describe non-networked electronic resources
and / or non-electronic resources as well.
Table 4.7.3: Collection - Types of Materials Cataloged

Project Web Pages Networked Electronic Electronic Resources, Non-electronic
Resources Non-networked Resources
ADTP X ! X X
AVEL ! ! X X
BEP ! ! ! !
BIBLINK ! ! ! X
CISMeF ! ! X X
Colorado X ! X X
37
EdNA ! ! X X
EULER ! ! ! !
FIU DL X ! X X
GEM ! ! X X
Minnesota ! ! X X
NewsAgt ! ! X X
Queensld ! X X X
SAFARI ! ! X X
Scout ! ! X X
Swedish ! ! X X
Key: X = No; ! = Yes
Table 4.7.4 showed that metadata creators come from all four categories:
author / creator of resource, publisher, staff / librarians and independent intermediaries,
and Table 4.7.5 showed that the most abundant metadata tools used by the projects are
metadata creation template or software. Furthermore, automatic metadata extraction or
indexing tools, metadata format conversion tools and mapping tools are also used by
some of the projects.
Table: 4.7.4: Metadata Creators

Project Metadata Creators
Author / Creator of Publisher Staff / Librarians Independent
Resource Intermediaries
ADTP ! X ! !
AVEL ! X ! X
BEP ! ! ! !
BIBLINK X ! ! !
CISMeF X X ! X
Colorado X X X !
EdNA ! ! ! !
EULER ! ! ! !
FIU DL ! X X X
GEM X X X !
Minnesota ! X ! !
NewsAgt X ! X X
Queensld ! X ! X
SAFARI ! ! X X
Scout X X ! X
Swedish ! ! X X
38
Table 4.7.5: Metadata Tools

Project Metadata Tools
Metadata Creation Automatic Metadata Metadata Format Mapping Tools
Template / Software Extraction / Indexing Conversion Tools
Tools
ADTP ADT program and HotMeta – Metadata Nil Nil
software – ADT Deposit Search Engine
Form. developed by the
Distributed Systems
Technology Centre
(DSTC) based at
Queensland
University.
AVEL Reg, the metadata HotMeta – Metadata Nil Nil
creation tool (JavaScript Search Engine
Web editor) developed by developed by the
the Distributed Systems Distributed Systems
Technology Centre Technology Centre
(DSTC) at the University (DSTC) based at
of Queensland. Queensland
University.
BEP BEP’s Content Online Once an item is Produce metadata Other metadata
Registration Environment registered, it is in XML/RDF or mapped to BEP.
(CORE) managed by Aus indexed overnight. HTML 4.0 format.
Industry. BEP AGLS
Tagging System (BATS).
BIBLINK BIBLINK metadata Nil Generate DC in a USEMARCON
creator variety of formats software. The
UNIMARC format was
chosen as the central
format and conversion
is possible to and
from several national
MARC formats and to
BIBLINK Core
CISMeF Information in French.
Colorado Develop web-based Nil Nil Load records from
Dublin Core input system other standards
and database software. including MARC,
Dublin Core, VRA,
GILS, etc
EdNA Enter direct into EdNA EdNA Online Nil Nil
Online database or use Harvester
EdNA Metadata Editor
EULER EULER Metadata creator EULER Engine Nil Map distributed
metadata database to
EULER.
FIU DL Blue Angel Repository Nil Can export as Map FIU DL metadata
software, repository for HTML tags, or to MARC.
creating metadata. SGML / MARC
records from FIU
DC
GEM GEMCat - a cataloging Metadata Harvest The first generation Consortium members
program. program of GEMCat outputs with database-driven
data in forms dynamic pages have
suitable for HTML2 successfully mapped
and HTML4. Work existing data
is underway on structures to the GEM
39
RDF/XML. element set.

Minnesota The Foundations Project Nil Nil Nil
worked in close
collaboration with
Hiawatha Island Software
Company to develop
TagGen DC metadata
generator / editor.
NewsAgt NewsAgent DC Generator Software robots. Convert metadata Nil
and generate in
other formats, i.e.
RDF, Abbreviated
RDF, IMS, HTML
text, US MARC,
SOIF, TEI header,
IAFA/ROADS,
GILS, OLSTF, XML.
Queensld Metadata templates. Nil Nil Nil
SAFARI The technological Search robots. Nil Nil
solutions, e.g. in the form
of metadata tools and
search robots, are being
supplied by NetLab at
Lund University. Metadata
viewer and editor
Scout HTML templates in Nil Nil Nil
combination with a Perl
script.
Swedish EnviroNet has developed Includes a harvestor. Nil Nil
an application that
members can use to
create and edit metadata.
As for metadata use and storage, a variety of methods have been employed by
the projects, the most popular one being the use of database records linked to resources
(as shown in Table 4.7.6). It was also observed that “Third party metadata model” has
been deployed by more projects as compared to the other two resources description
models (as shown in Table 4.7.7).
Table 4.7.6: Metadata Use and Storage

Project Embedded in Web Page As a separate HTML Page Database Record Linked to Resource
ADTP X ! !
AVEL X X !
BEP ! ! !
BIBLINK ! X !
CISMeF X ! !
Colorado X X !
EdNA ! ! !
EULER ! X !
FIU DL X X !
GEM ! ! !
Minnesota ! ! X
40
NewsAgt ! X !
Queensld ! X X
SAFARI ! ! !
Scout ! X !
Swedish ! X !
Table 4.7.7: Resource Description Model

Project Embedded Metadata Third Party Metadata View Filter
ADTP X ! X
AVEL X ! X
BEP X ! X
BIBLINK X X !
CISMeF X ! X
Colorado X X !
EdNA X ! X
EULER X X !
FIU DL X ! X
GEM X X !
Minnesota ! X X
NewsAgt X X !
Queensld ! X X
SAFARI X X !
Scout X ! X
Swedish X ! X
Table 4.7.8: Metadata Search and Retrieval

Project Search Gateway Search Browse
Across Distributed
Databases
ADTP ! ! By partner institution
AVEL ! ! By subject
BEP ! X Nil
BIBLINK No information
CISMeF ! ! Alphabetical or thematic indices (MeSH)
Colorado X ! By media format type or geographic location
EdNA ! ! By resource type or category
EULER X ! By resource type or category
FIU DL ! ! By resource type or subject
GEM ! X By subject, keyword or grade/education level
Minnesota ! X By environmental topic categories
NewsAgt ! X By channels (topics)
Queensld ! X Nil
SAFARI ! X By subject
Scout ! ! By LCC or LCSH
Swedish ! ! By environmental catalogue (subject)
41
Table 4.7.9: Benefits / Purposes of Deploying Metadata

Project Facilitate Searching Improve Resource Management of Crosswalk /
& Retrieval Discovery resources Interoperability
ADTP ! ! ! !
AVEL ! ! ! !
BEP ! ! ! !
BIBLINK ! X ! !
CISMeF ! ! X X
Colorado ! ! X !
EdNA ! ! ! !
EULER X X X !
FIU DL ! ! ! !
GEM ! ! ! !
Minnesota ! ! ! !
NewsAgt ! ! ! !
Queensld ! ! ! !
SAFARI X ! X !
Scout ! ! ! X
Swedish ! ! X X
Table 4.7.8 showed that most of the projects offered searching and browsing
mechanisms for retrieval of the resources. Finally, Table 4.7.9 showed that all projects
deployed metadata for many reasons.
42
CHAPTER 5
DISCUSSION
In this chapter, I shall discuss and analyze the results presented in the previous
chapter. The discussion will be divided into two main sections. The first section will
focus on the comparison between the metadata schemas employed by the projects and
DCMES. The second section will provide a general overview of the DC projects
surveyed and correlate the nature of the projects (i.e. collection scope and coverage,
creation, etc.), the metadata schemas and the metadata deployment models adopted.
5.1. Metadata Schema

The metadata schemas used by the projects shall be analyzed in detail in the
following manner:
(1) to compare the consistency in adopting the DCMES
(2) to compare the usage of each DC element
In terms of the usage of DCMES in general, all the sixteen projects surveyed
adopted more than 50% of the DC elements (see Figure 4.1) and six of the projects
adopted all fifteen DC elements (see Table 4.1). This showed that though not all the
DC elements are equally popular among project implementors, the general trend was to
adopt most of the DC elements.
Based on the percentage consistency in the use of DCMES (see Figure 4.1), the
projects can be ranked (from most consistent to least consistent) as shown in Table 5.1
Table 5.1: Projects Ranked in Terms of Consistency on the Use of DC Elements

Rank Project
1st BEP, Colorado, EdNA, FIU DL, Minnesota, Queensld
2nd AVEL
3rd GEM
4th EULER
5th CISMeF, NewsAgt, Scout
6th SAFARI, Swedish
7th ADTP
43
In contrast, most of the projects were not as consistent in the usage of qualifiers
recommended by DCMI. From Table 4.2 and Table 4.3, the projects can be ranked in
terms of percentage consistency (from most consistent to the least consistent) in the
use of qualifiers – element refinement / subelement (see Table 5.2) and scheme (see
Table 5.3).
Table 5.2: Projects Ranked in Terms of Consistency on the Use of DC Subelements

Rank Project
1st EdNA
2nd AVEL, FIU DL, GEM, Queensld, Minnesota
3rd BIBLINK, Colorado, EULER, Scout
Table 5.3: Projects Ranked in Terms of consistency on the use of DC Schemes

Rank Project
1st EdNA
2nd Queensld, Colorado, AVEL,
3rd GEM, EULER, NewsAgt
4th BEP, BIBLINK, CISMeF, Minnesota
5th ADTP, FIU DL, SAFARI, Swedish, Scout
From the consistency ranking shown from Table 5.1 to Table 5.3, one project –
EdNA, significantly stood out from the other projects as it ranked highest in the overall
application of DCMES.
On further comparison of the metadata schemas used by the projects with

DCMES, 75% of the projects surveyed was found to have adopted non-DC metadata
elements as well. From Appendix E, the number of non-DC metadata elements used to
supplement the DC elements ranged from one to as many as ten. Moreover, the
percentage of non-DC metadata elements used as compared to the total number of
metadata elements used in a project can be as high as 45%, as in EULER (see Figure
4.3). The abundant use of local or non-DC elements could be interpreted in two
contrasting views:
(a) DCMES is insufficient for resource description, or,
(b) Dublin Core is in fact able to provide minimal resource description,
with the flexibility for project implementors to tailor its use for their
local applications or specific domains.
44
I think the second opinion is most descriptive, as most of the local elements used by
the projects were actually intended more for resource management and other purposes,
not resource description (see Appendix E).
One interesting point is that though EdNA is the most consistent in following
the DCMES, it is also among one of the projects that employ many non-DC elements.
Thus, EdNA can be said to be exemplary in its attempt to adopt DCMES fully and yet
still able to extend its metadata schema to accommodate other more specific
requirements in resource description and management.
From another perspective, each DC element usage is analyzed, especially with

regard to the subelements and encoding schemes adopted by the projects. Results from
Table 4.1 showed that eight of the fifteen DC elements were employed by all the
sixteen projects surveyed. These eight DC elements are Title (A1), Language (A3),
Subject (A4), Description (A5), Publisher (B1), Creator (B2), Date (C3) and Identifier
(C4). It was observed that elements from each of the categories - content, intellectual
property, and instantiation - were employed, implying that elements from all the three
categories are deemed to be equally important for resource description. On the other
hand, Source (A2) and Relation (A7) are two DC elements that were used to a lesser
extent by the projects (see Figure 4.2).
Upon further analysis of each DC elements, it is found that the usage of

qualifiers varied greatly among the projects surveyed. From the raw data collected (see
Appendix C and D), it was observed that qualifiers were employed in the following
scenarios:
(a) use only subelements / schemes recommended by DCMI
(b) use a mixture of subelements / schemes recommended by DCMI and local
subelements / schemes
(c) local subelements / schemes only
(d) no subelement / scheme used
DCMI recommended subelement(s) for six of the fiftteen DC elements (see

Table 3.1). As shown in Figure 4.3.1, 4.3.2 and 4.3.5, most of the projects did not
employ any subelements for Title (A1), Description (A5) and Format (C2). On the
45
other hand, most of them employed subelements recommended by DCMI for Coverage
(A6), Relation (A7) and Date (C3), as shown in Figure 4.3.3, 4.3.4 and 4.3.6.
Analysis was also done on the remaining nine DC elements, which do not have
subelements recommended by DCMI (see Figure 4.4). It was interesting to note that
there are projects that adopted local subelements for each of the remaining eight DC
elements, except for Type (C1). In fact, the percentage of projects with subelements
for Publisher (B1), Creator (B2) and Contributor (B3) ranges from 44% to 70%. This
is a strong indication of the fact that the project implementors felt that more elaborate
description is necessary for these three DC elements belonging to the “Intellectual
Property” category. The main subelements used for these three DC elements were
“Personal Name” and “Corporate Name”. This bears similarity to the use of author and
publisher fields with extensive descriptions in catalog records in the MARC format.
Results from the analysis of encoding schemes used by the sixteen projects,
however, differed greatly from that of subelements. DCMI recommended schemes for
nine of the fifteen DC elements (see Table 3.1). The most significant difference is that
most of the projects used schemes– either recommended by DCMI, local schemes
(developed locally or using other established schemes), or a mixture of both - for the
nine DC elements. The percentage of projects not using any scheme ranged from 0%
for Language (A3), Subject (A4), Type (C1) and Identifier (C4) (see Figure 4.5.2,
4.5.3, 4.5.6, 4.5.9), to only 29% for Source (A2) (see Figure 4.5.1).
Local schemes seem to be given more emphasis by project implementors, as

opposed to local subelements. In fact, for four of the DC elements - Source (A2),
Coverage (A6), Type (C1) and Date (C3) – projects who employed only local schemes
were equal in number, if not more, than the projects who employed DCMI-
recommended schemes (see Figure 4.5.1, 4.5.4, 4.5.6 and 4.5.8). Generally, the
percentage of projects that adopted local schemes only is higher than the percentage of
projects that adopted local subelements only.
Particular elements to note are the Subject (A3) and Identifier (C4), where a
mixture of both DCMI-recommended schemes and local schemes have been used
concurrently. Eight of the sixteen projects - AVEL, BEP, EdNA, FIU DL, GEM,
46
Minnesota, NewsAgt and Swedish – were found to have developed their own local
controlled vocabulary or classification schemes for the Subject element. This is not
unusual due to the fact that specific subjects limited the scope of their collections (see
Table 4.7.2). Besides the use of local schemes, many other established thesaurus,
controlled vocabulary listings and classification systems were used as well. Some
examples of them are the Art and Architecture Thesaurus (AAT), ERIC,
ICONCLASS, Mathematics Subject Classification Scheme (MSC), Computing
Classification System (CCS) and Common European Research Information Format
(CERIF) Classification System.
Scout Report Signpost is especially worth mentioning in this aspect. The

primary goal of the Scout Report Signpost was to demonstrate that Internet Resources
could be cataloged, classified, and arranged using existing controlled vocabularies and
taxonomies such as the Library of Congress Classification Scheme and the Library of
Congress Subject Headings in concert with the Dublin Core metadata standard. It is
one of the few DC projects that applied cataloging rules and make use of cataloging
tools such as Anglo-American Cataloging Rules (AACR2R, 1998), OCLC
Bibliographic Formats and Standards, and Library of Congress Subject Cataloging
Manual, etc.
The remaining six DC elements (without any DCMI-recommended scheme)

were also analyzed for the usage of schemes, as shown in Figure 4.6. It was found that
for each of the six DC elements, local schemes were used by at least three projects.
The trend is again reflecting that project implementors felt the need to follow some
schemes for Publisher (B1), Creator (B1), Contributor (B3) and Rights (B4) – all
belonging to the “Intellectual Property” category.
The above observations of the usage of qualifiers by project implementors are

in line with the DCMI recommendations (Dublin Core Qualifiers, 2000), as “it is
expected that implementors will develop additional qualifiers for use within local
applications or specific domains”. Moreover, for schemes, there are many more
controlled vocabularies or classification systems that were not identified in Dublin
Core Qualifiers (2000), as it is one of the first recommendations made by DCMI
47
regarding the use of qualifiers. Thus, this resulted in the larger discrepancies observed,
especially between the use of DCMI-recommended schemes and local schemes.
5.2. Overview of Dublin Core Projects

One has to understand the nature of the DC projects in order to explain the
metadata schema adopted. Many other deployment and application issues were also
explored. Thus, results from the qualitative analysis under section 4.10 would allow
one to gain insight as to how Dublin Core has been deployed and how DCMES can be
applied in various ways and for various purposes.
Results from Table 4.7.1 showed that many different communities were
involved in resource submission. However, these communities were usually specified
to a certain consortiums or participating memberships. A few key groups of interested
parties can be identified:
(a) Universities, learning institutions, and research organizations,
(b) Libraries, archives and museums,
(c) Publishers and other content providers, and
(d) Government agencies
Such a wide spectrum of Dublin Core usage is especially encouraging, as this

reflected the trend and showed in reality that Dublin Core has indeed stirred up
interests among a wide variety of audiences, and that this standard can be and has been
applied to resources from many disciplines. Moreover, just from the sixteen projects
surveyed, it was obvious that the efforts came not only from different communities,
and more importantly, these communities are also from different countries such as
Australia, Europe, United States of America and Sweden.
Another interesting aspect regarding the submission and selection of resources

(see Table 4.7.1) is the presence of selection criteria for most of the projects surveyed.
This suggests that part of the process for metadata creation may not be an automated
one, as many of the projects emphasized on providing access to quality resources on
the Internet, thus the term “Subject Gateway” came about. It was clear, from Table
48
4.7.8, that many of the projects are subject gateways, as users are able to browse the
collection via subject categories
As for the type of material that has been cataloged, it is found that all projects
except Queensland used Dublin Core to describe networked electronic resources, and
that the majority of them specifically describe Web pages (see Table 4.7.3). This is a
significant discovery as the deployment of Dublin Core is not only restricted to HTML
Web pages, but more for describing other material types available on the network
(Internet or Intranet) as well.
Consequently, as shown in Table 4.7.7, the resource description model

deployed by the projects is seldom the “embedded metadata model” (Minnesota and
Queensld). Embedded metadata model is considered to be the simplest and easiest
application model for deploying Dublin Core metadata, the advantage being that no
additional system must be in place to use it. This advantage is reflected in Tables 4.7.6
and 4.7.5, where Minnesota and Queensld were not required to develop any database
for storage and tools for retrieval of metadata.
Subsequently, as shown in Table 4.7.7, there is almost an equal deployment of

“third party metadata model” and “view filter metadata model”. These two resource
description models are more complicated to implement and utilize, especially the
“view filter metadata model”, and involve the use of databases (see Table 4.7.6).
BIBLINK, EULER and GEM deployed such a model, and from the metadata tools
developed and used by these three projects (see Table 4.7.5), metadata creation could
be either manual or automated by harvesting, conversion of metadata format, or
mapping from different metadata formats such as UNIMARC, MARC and GILS, etc.
Thus, more sophisticated metadata tools are required for projects deploying the "view
filter metadata model” for resource description.
A further look into the metadata creators and metadata creation tools might
provide some clues as to how Dublin Core was created and handled by the projects.
According to the DCMI, the Dublin Core is intended to be usable by non-catalogers as
well as resource description specialists, the results shown in Table 4.7.4 showed that
this statement is indeed an accurate reflection of this aspect on the applications of
49
Dublin Core. For the surveyed projects, authors or creators of the resources, and
librarians have been active players in the creation of metadata. Publishers and other
independent intermediaries have also began to play a role as well (see Table 4.7.4).
Numerous and varied metadata creation templates and metadata generation

software have also been developed for use in all the projects (see Table 4.7.5).
Development in this particular area has flourished since the fifth Dublin Core metadata
workshop in 1997, as the need for tools for creation, harvesting and indexing of Dublin
Core metadata became more urgent. Developers of such tools ranged from
universities’ and research organizations, such as the Distributed Systems Technology
Centre (DSTC) at the University of Queensland, to other proprietary software
companies such as Hiawatha Island Software Company (see Table 4.7.5). From the
abundance of metadata creation and indexing tools, it became clear that metadata
creation and retrieval have not been a problem to project implementors. However, this
is only true for projects that involved professionals from many different areas,
especially from computer science. Efforts from libraries, universities or government
agencies alone, would not be able to deal with the implementation of such complicated
computer systems and structures.
5.3. Use of Local / Non-DC Elements

Another important aspect not to be missed out is the use of local or non-DC
elements and to relate the use of local or non-DC elements by project implementors
with the nature of the projects. Other important attributes of metadata elements,
besides resource description, can be observed from the local element names and
definitions provided in Appendix E.
According to Burnett (1999), metadata elements may be roughly divided into

two categories: intrinsic (i.e., those that are related to resource identification and
discovery) and extrinsic (i.e., those that are related administration and other non-
bibliographic data). Burnett (1999) continued that Dublin Core metadata elements
belong to the first category, which facilitate resource description and identification, but
lacks extrinsic metadata elements which are more useful for management and
administrative purposes. Examples of extrinsic metadata elements are system
50
requirement, mode of access, availability, cost, control, extent (size), encoding

description and revisions description.
Following Burnett’s theory (1999), the local elements that have been adopted
by twelve of the DC projects surveyed were categorized as “intrinsic metadata
elements” or “extrinsic metadata elements”. It was found that many of the local
elements used fit into both categories. Some of the local elements that clearly fit as
“intrinsic metadata elements” are:
(i) AC.Creator, AC.DateCreated, AGLS.Availability,
AVEL.Comments (see Table E1 and E2)
(ii) BIBLINK.Price, BIBLINK.SystemRequirements,
BIBLINK.Checksum (see Table E3)
(iii) Type of access, Cost, Sponsorship (as described in Appendix E)
(iv) EDNA.Approver, EDNA.Entered, EDNA.Indexing, EDNA.Version
(see Table E4)
(v) EULER.Record.Creator, EULER.Delivery,
EULER.Delivery.Description (see Table E5)
(vi) Cataloger’s Note (see Table E6)
(vii) GEM.Cataloging (see Table E7)
(viii) NewsAgent.Contact (see Table E8)
(ix) Source of Cataloging (see Table E9)
However, there are some local elements that could not fit into any of the two
categories. Such elements were applied specifically for evaluative purposes or for
important and useful description tailored to a particular subject area, for example
education. Some elements used for such purposes are:
(i) EDNA.Audience, EDNA.Review, EDNA.Reviewer (see Table E1 and
Table E4)
(ii) Target (as described in Appendix E)
(iii) GEM.Audience, GEM.Grade, GEM.Pedagogy, GEM.Quality,
GEM.Standards (see Table E7)
(iv) Safari.TargetGroup (see Table E10)
51
The above analysis suggested strongly that projects that deployed “third part metadata
model” or “view filter model” (see Table 4.7.7) and made use of more sophisticated or
complex database programs or software (see Table 4.7.5) were inclined to add more
local elements, especially metadata elements of extrinsic characteristics, in order to
provide information on the metadata itself. These projects are AVEL, BEP, BIBLINK,
CISMeF, EdNA, EULER, FIU DL, GEM, NewsAgt and SAFARI.
Last, but not least, the benefits of using Dublin Core to describe networked
electronic resources were indicated clearly in Table 4.7.9. The reasons for and benefits
of the use of Dublin Core metadata standard by DC projects to describe networked
electronic resources are clearly stated as follows:
(i) To facilitate searching and retrieval
(ii) To improve resource discovery
(iii) To help in the management of resources, and
(iv) For interoperability and / or crosswalk between different metadata
formats.
These reasons are in fact all the characteristics and uses of any metadata standards, not
just limited to Dublin Core metadata standard. Thus, it can be concluded that the main
purposes and final goals for deploying any metadata standard are the same, no matter
which metadata standard was selected for implementation.
52
CHAPTER 6
SUMMARY AND CONCLUSIONS
The first part of this study has attempted to analyze in detail the metadata
schemas used in sixteen DC projects by comparing the consistency in adopting the
DCMES, and by comparing the usage of each DC element.
In terms of the usage of DCMES in general, all the sixteen projects surveyed
adopted more than 50% of the DC elements and six of the projects adopted all fifteen
DC elements. This indicated that though not all the DC elements are equally popular
among project implementors, the general trend was to adopt most of the DC elements.
In contrast, most of the projects were not as consistent in the usage of qualifiers
recommended by DCMI.
In addition, 75% of the projects surveyed was found to have adopted non-DC
metadata elements as well. The number of non-DC metadata elements used to
supplement the DC elements ranged from one to as many as ten. Moreover, the
percentage of non-DC metadata elements used as compared to the total number of
metadata elements used in a project can be as high as 45%. Moreover, most of the
local elements used by the projects were actually intended more for resource
management and other purposes, not resource description. This proved that Dublin
Core is in fact able to provide minimal resource description, with the flexibility for
project implementors to tailor its use for their local applications or specific domains.
EdNA was the only project that most consistently followed the DCMES,
including the use of DC qualifiers. However, though EdNA is the most consistent in
following the DCMES, it is also among one of the projects that employ many non-DC
elements. Thus, EdNA can be said to be exemplary in its attempt to adopt DCMES
fully and yet still able to extend its metadata schema to accommodate other more
specific requirements in resource description and management.
53
Results from analysis of each DC element revealed that eight of the DC

elements - Title, Language, Subject, Description, Publisher, Creator, Date and
Identifier - are especially popular among the DC projects. This implied that DC
elements from all three categories - content, intellectual property, and instantiation -
were deemed to be equally important for resource description. On the other hand,
Source (A2) and Relation (A7) are two DC elements that were used to a lesser extent
by the projects.
Upon further analysis of subelements used for each DC element, it was found
that most of the projects used DC subelements for Coverage, Relation and Date. In
contrast, subelements were not used by most projects for Title (A1), Description (A5)
and Format (C2). There is a strong indication that the project implementors felt that
more elaborate description is necessary for Publisher, Creator and Contributor
elements, which belong to the “Intellectual Property” category. The main subelements
used for these three DC elements were “Personal Name” and “Corporate Name”. This
bears similarity to the use of author and publisher fields with extensive descriptions in
catalog records in the MARC format.
In contrast, further analysis of schemes used for each DC element indicated that
project implementors placed more emphasis on local schemes for Source, Coverage,
Type and Date, as compared to schemes recommended by DCMI. For Subject and
Identifier, a mixture of both DCMI-recommended schemes and local schemes had
been used concurrently. Eight of the sixteen projects - AVEL, BEP, EdNA, FIU DL,
GEM, Minnesota, NewsAgt and Swedish – were found to have developed their own
local controlled vocabulary or classification schemes for the Subject element. This is
not unusual due to the fact that specific subjects limited the scope of their collections.
The abundant integration of non-DC elements, subelements and encoding

schemes (whether locally developed or using other established standards) clearly
indicated that Dublin Core is well-positioned to provide a ‘lowest common
denominator’ foundation of interoperability between network resources descriptions
across all systems, disciplines and cultures.
54
Non-DC elements used by projects were mainly “extrinsic” metadata elements

(i.e. related to administration and other non-bibliographic data), or elements
specifically used for evaluative purposes or for important and useful description
tailored to a particular subject area, for example, education. These attributes are
lacking in DCMES, as all the DC elements are “intrinsic” metadata elements meant for
resource identification and discovery.
The second part of this study revealed that Dublin Core has indeed been
applied in several countries by various communities, including (a) universities,
learning institutions, and research organizations, (b) libraries, archives and museums,
(c) publishers and other content providers, and (d) government agencies, to enhance
cross-disciplinary discovery of electronic resources, including Web pages.
The study also found that “third party metadata model” and “view filter
metadata model” were more popular for the deployment of Dublin Core, as compared
to the “embedded metadata model”. The trend of using automatic metadata creation or
indexing is also beginning to gain momentum, as more metadata tools have been
developed in the recent years. From the abundance of metadata creation and indexing
tools, it became clear that metadata creation and retrieval have not been a problem to
project implementors. However, this is only true for projects that involved
professionals from many different areas, especially from computer science. Efforts
from libraries, universities or government agencies alone, would not be able to deal
with the implementation of such complicated computer systems and structures.
Finally, the majority of the projects surveyed adopted DC metadata standard

for the following reasons to benefit the users: (a) to facilitate searching and retrieval,
(b) to improve resource discovery, (c) to help in the management and organization of
resources, and (d) for interoperability and / or crosswalk between different metadata
format. These benefits tie in perfectly with the four characteristics - which are the
strengths of Dublin Core metadata standard.
55
REFERENCES
American Library Association (ALA). Committee on Cataloging: Description and

Access (CC:DA). (2000, June 16). Task Force on Metadata. Final Report: June 2000
[Online]. Available: http://www.ala.org/alcts/organization/ccs/ccda/tf-meta6.html
[2001, June 28].
Andresen, Leif. (2000). Brief communication: 7th Dublin Core workshop. Online
Information Review, 24(1), 85-87.
Baca, Murtha (Ed.). (2000). Introduction to metadata: pathways for digital

information [Online]. Available:
http://www.getty.edu/research/institute/standards/intrometadata/index.html [2001, July
1]
BIBLINK - LB 4034 - D1.1 Metadata Formats [Online]. (1996, December 23).

Available: http://hosted.ukoln.ac.uk/biblink/wp1/ [2001, June 28].
Burnett, Kathleen, Ng, Kwong Bor, & Part, Soyeon. (1999). A comparison of the two
traditions of metadata development. Journal of the American Society for Information
Science, 50(13), 1209-1217.
Campbell, Debbie. (1999). Dubin Core metadata and the Australian MetaWeb project
[Online]. Available: http://www.nla.gov.au/nla/staffpaper/dcampbell1.html [2001,
June 29].
Crosswalks from the Alexandria Metadata Schema to Other Schemas [Online]. (1997,
January 24). Available: http://www.alexandria.ucsb.edu/public-
documents/metadata/crosswalks.html [2001, July 1]
Day, Michael. (2000, February 13). Metadata: mapping between metadata formats
[Online]. Available:
http://www.ukoln.ac.uk/metadata/interoperability/ [2001, July 1].
Dempsey, Lorcan, & Heery, Rachel. (1997, March 19). Specification for resource
description methods, part 1, a review of metadata: a survey of current resource
description formats [Online]. Available:
http://www.ukoln.ac.uk/metadata/desire/overview/ [2001, June 28].
Dempsey, Lorcan, & Weibel, Stuart L. (1996, July / August). The Warwick Metadata
Workshop: a framework for the deployment of resource description [Online]. D-Lib
Magazine. Available: http://www.dlib.org/dlib/july96/07weibel.html [2001, June 28].
Dublin Core Metadata Element Set (DCMES), version 1.1: reference description
[Online]. (1999, July 2). Available: http://dublincore.org/documents/dces/. [2001, June
28].
56
Dublin Core Metadata Initiative (DCMI): frequently asked questions [Online]. (2001).
Available: http://dublincore.org/resources/faq/#whatismetadata [2001, June 28].
Dublin Core Metadata Initiative (DCMI): projects [Online] Available:

http://dublincore.org/projects/ [2001, June 29]
Dublin Core qualifiers [Online]. (2000, July 11). Available:

http://dublincore.org/documents/dcmes-qualifiers/ [2001, June 28].
Dublin Core releases recommended qualifiers to improve access to information. (2000,

July / August). OCLC Newsletter, 26-28.
Fullerton, Karen, Greenberg, Jane, McClure, Maureen, Rasmussen, Edie, & Stewart,
Darin. (1999, April). A digital library for education: the PEN-DOR project. The
Electronic Library, 17(2), 75-82.
Heery, Rachel. (1996, October). Review of Metadata Formats. Program, 30(4), 345-
373.
Hillmann, Diane. (2001, April 12). Using Dublin Core [Online]. Available:
http://dublincore.org/documents/usageguide/ [2001, June 28].
Hodgson, Katrina. (1998, March 31). Metadata: foundations, potential and

applications [Online]. Available:
http://www.slis.ualberta.ca/538/khodgson/metadata.htm [2001, June 28].
Hudgins, Jean. (1999). Getting mileage out of metadata: applications for the library.
Chicago: American Library Association.
International Federation of Library Associations and Institution (IFLA). (2001,

February 23). Digital libraries: metadata resources [Online]. Available:
http://www.ifla.org/II/metadata.htm [2001, June 28].
Lange, Holley R., & Winkler, B. Jean. (1997). Taming the Internet: metadata, a work
in progress. In Godden, Irene (Ed.), Advances in Librarianship: Vol. 21 (pp. 47-72).
San Diego: Academic Press.
Lee-Smeltzer, Kuang-Hwei (Janet). (2000). Finding the needle: controlled

vocabularies, resource discovery, and Dublin Core. Library Collections, Acquisitions,
& Technical Services, 24(2), 205-215.
Library of Congress. Network Development and MARC Standards Office. (2001a,

March 12). Dublin Core/MARC/GILS crosswalk [Online]. Available:
http://lcweb.loc.gov/marc/dccross.html [2001, July 1]
Library of Congress. Network Development and MARC Standards Office. (2001b,

April 19). MARC standards [Online]. Available: http://www.loc.gov/marc/marc.html
[2001, July 1]
57
Qin, Jian. (1998). Computational representation of Web objects in an interdisciplinary

digital library: a survey and experiment in polymer science [Online]. In Annual Review
of OCLC Research. Available:
http://www.oclc.org/oclc/research/publications/review98/qin/computational.abstract_c
ontents.htm [2001, June 29].
Rusch-Feja, Diann. (1998). Metadata: standards for retrieving WWW documents (and
other digitized and non-digitized resources) [Online]. Available:
http://www.stsci.edu/stsci/meetings/lisa3/ruschfejad.html [2001, June 28].
State and University Library at Göttingen, Germany (SUB). (2000). Metaform:

Crosswalks, Crosscuts, & Mappings [Online]. Available: http://www2.sub.uni-
goettingen.de/metaform/crosswalks.html#Crosswalks [2001, July 1]
Taylor, A. G. (1999). The organization of information (pp. 77-101). Englewood, Colo.:

Libraries Unlimited.
Taylor, Chris. (1999, April 1). An introduction to metadata [Online]. Available:

http://www.library.uq.edu.au/iad/ctmeta4.html [2001, June 28].
Thiele, Harold. (1998, January). The Dublin core and Warwick framework: A review
of the literature, March 1995-September 1997 [Online]. D-Lib Magazine. Available:
http://www.dlib.org/dlib/january98/01thiele.html [2001, June 28].
Thornely, Jennie. (1999). The how of metadata: metadata creation and standards
[Online]. Available: http://www.slq.qld.gov.au/pub/staff/catcon99.htm [2001, June
29].
Vercoustre, Anne-Marie, & Paradis, Francois. (1999). Metadata for photographs: from
digital library to multimedia application. In Abiteboul, S. (Ed.), Research and
Advanced Technology for Digital Libraries. Lecture Notes in Computer Science (Vol.
1696, pp. 39-57). New York: Springer.
Weibel, Stuart. (1997, October / November). The Dublin Core: a simple content
description model for electronic resources. Bulletin of the American Society for
Information Science, 24(1), 9-11.
Weibel, Stuart. (1999, April). The state of the Dublin Core Metadata Initiative, April
1999 [Online]. D-Lib Magazine. Available:
http://www.dlib.org/dlib/april99/04weibel.html [2001, June 28].
Weibel, Stuart, & Hakala, Juha. (1998, February). DC-5: The Helsinki Metadata
Workshop, a report on the workshop and subsequent developments [Online]. D-Lib
Magazine. Available: http://www.dlib.org/dlib/february98/02weibel.html [2001, June
28].
Weibel, Stuart, Iannella, Renato & Cathro, Warwick. (1997, June). The 4th Dublin
Core Metadata Workshop report [Online]. D-Lib Magazine. Available:
http://www.dlib.org/dlib/june97/metadata/06weibel.html [2001, June 28].
58
Weibel, Stuart L., & Koch, Traugott. (2000, December). The Dublin Core Metadata
Initiative: mission, current activities, and future directions [Online]. D-Lib Magazine,
6(12). Available: http://www.dlib.org/dlib/december00/weibel/12weibel.html [2001,
June 28].
Weibel, Stuart L., & Lagoze, Carl. (1997). An element set to support resource
discovery: the state of Dublin Core, January 1997. International Journal of Digital
Libraries, 1, 176-186.
Zeng, Marcia Lei. (1999). Metadata elements for object description and representation:
a case report from a digitized historical fashion collection project. Journal of the
American Society for Information Science, 50(13), 1193-1208.
59
APPENDIX A
Checklist Used for Survey of Dublin Core Metadata Projects
[A] Resource Submission & Selection

1) Who submits or recommends the resources to be catalogued?
a) specified group
b) anyone
2) Is there any selection criteria? If yes, what are the selection criteria?
3) Who reviews the resources submitted or recommended?
[B] About the Collection

1) What type of materials is catalogued?
a) web pages
b) electronic resources, networked
c) electronic resources, non-networked
d) others, to elaborate
2) What is the scope or coverage of the collection?
a) geographical
b) topical
c) general
d) others, to elaborate
[C] Metadata Creation

1) Who creates the DC metadata / Who is responsible for cataloging?
a) person who creates the resource (i.e. authors / creators of web pages)
b) person responsible for the publication of the resource (i.e. publishers)
c) staff / contract librarians employed to catalog documents (i.e. non-
cataloging librarians, catalogers, metadata specialists)
d) independent intermediaries
e) others (i.e. archivists, library users, subject specialists, anyone)
2) At which stage of workflow does the metadata creation or cataloging take
place?
[D] Metadata Deployment & Retrieval

1) How will the metadata be created and stored?
a) embed in HTML of a web site
b) separate HTML document linking to a resource
c) database record linked to a resource (i.e. metadata repositories)
2) Which metadata model is used?
a) embedded model
b) third-party metadata model
c) view-filter model
3) What is the granularity (level of detail) of the metadata description? Minimal
versus full-level description?
a) collection level
b) individual item
c) groups of document
4) How can the metadata be retrieved or searched by users?
A-1
[E] Dublin Core Metadata Schema

1) Are all 15 DC elements used?
2) Which DC elements are used / not used, mandatory / optional, repeatable /
non-repeatable?
a) Content
i) Title
ii) Source
iii) Language
iv) Subject
v) Description
vi) Coverage
vii) Relation
b) Intellectual Property
i) Publisher
ii) Creator
iii) Contributor
iv) Rights
c) Instantiation
i) Type
ii) Format
iii) Date
iv) Identifier
3) For each element in 2), are sub-elements (element refinements) used? If yes,
state and indicate the number of sub-elements used for each element.
a) Content
i) Title
ii) Source
iii) Language
iv) Subject
v) Description
vi) Coverage
vii) Relation
i) Publisher
ii) Creator
iii) Contributor
iv) Rights
c) Instantiation
i) Type
ii) Format
iii) Date
iv) Identifier
4) For each element in 2), are encoding schemes used? If yes, state and indicate
the number of encoding schemes used for each element.
a) Content
i) Title
ii) Source
iii) Language
iv) Subject
v) Description
vi) Coverage
vii) Relation
i) Publisher
ii) Creator
A-2
iii) Contributor
iv) Rights
c) Instantiation
i) Type
ii) Format
iii) Date
iv) Identifier
5) Are controlled vocabulary / keywords used for any of the DC elements in 2)?
Which of the elements require use of controlled vocabulary / keywords?
6) Are there any additional local elements? If yes, what are the local elements,
and how many local elements are added? State whether sub-elements and /
or schemes are used.
7) How many elements (both DC and local) are used, in total?
8) Are there any elements that are automatically inserted?
[F] Tools & Aids for Metadata Creation

1) Are there any guidelines used for metadata creation?
a) Metadata schema
b) Guides to best practices
c) Metadata creation manual
d) Others, to specify
2) Are any cataloging tools used, especially for inputting of metadata, subject
categorization and classification?
a) Controlled vocabulary
b) AACR2
c) Thesaurus
3) Any other tools to aid the metadata creation?
a) Metadata creation templates / metadata generating software
b) Automatic metadata extraction tools (i.e. automatic harvesting by web
spiders)
c) Metadata conversion tools
[G] Project Achievements

1) How many metadata records were created?
2) What is the time frame for the project?
3) What are the future plans or development?
4) Metadata has been used to
a) Facilitate searching; better retrieval
b) Improve discovery of resources
c) Assist in the management of resources
d) Experiment with various metadata standards, i.e. crosswalk between
metadata standards
e) Other reasons, to specify
A-3
APPENDIX B
Projects’ Metadata Schemas Used for Comparison
with DCMES
ADTP
Metadata standard [Online]. (Updated: 2000, February 23) Available:
http://www.library.unsw.edu.au/thesis/adt-ADT/info/metadata.html [2000, September
5]
AVEL
Metadata manual [Online]. (Last modified: 2000, April 18). Available:
http://avel.edu.au/mdmanual/start.html [2000, September 5]
BEP
Business Entry Point metadata "How To" guide, Version 1.3 [Online]. (1998,
December 15). Available:
http://about.business.gov.au/bep/agencies/provinfo/metadata/metadata-guide.pdf
[2000, August 31]
BIBLINK
BIBLINK core field semantics (Work Package 8) [Online]. (1998, July 28). Available:
http://hosted.ukoln.ac.ul/biblink/wp8/fs/bs-semantics.html [2000, September 1]
CISMeF
The use of Dublin Core metadata in a structured health resource guide on the Internet
[Online]. (Last updated: 2000, June 20). Available: http://www.chu-
rouen.fr/cismef/cismefdc.html [2000, August 28]
Colorado
Medata matrix [Online]. (No Date). Available:
http://coloradodigital.coalliance.org/Mdmatrix.html [2000, August 28]
Metadata guidelines [Online]. (Last update: 2000, May 19). Available:

http://coloradodigital.coalliance.org/MDguidlines.html [2000, August 28]
Medata matrix [Online]. (Revised:2000, November 29) Available:

http://coloradodigital.coalliance.org/matrix.html [2001, June 12]
Metadata guidelines [Online]. (Last update: 2001, April 9). Available:

http://coloradodigital.coalliance.org/glines.html [2001, June 12]
B-1
EdNA
EdNA Metadata Standard, Version 1.1 [Online]. (Last modified: 2001, May 28).
Available: http://standards.edna.edu.au/metadata/index.html [2001, March 10]
EdNA metadata elements [Online]. (Last updated: 2001, January 10.). Available:
http://standards.edna.edu.au/metadata/elements.html [2001, March 10]
Overview table: the EdNA metadata standard [Online]. (Last updated: 2001, May 1).
Available: http://standards.edna.edu.au/metadata/overview.html [2001, March 10]
EULER
EULER metadata profile [Online]. (2000, August 26). Available:
http://euler.lub.lu.se/engine/metadata.html.en [2001, March 31]
FIU DL
Metadata model [Online]. (Last updated: 1998, December 8). Available:
http://www.fiu.edu/~diglib/metadata/model.htm [2000, August 31]
Metadata creation and maintenance manual [Online]. (Last revised: 1998, December
10). Available: http://www.fiu.edu/~diglib/metadata/index.html [2000, August 31]
GEM
GEM Developer’s WorkBench: GEM controlled vocabularies [Online]. (Last
modified: 2000, November 1). Available:
http://www.geminfo.org/Workbench/Workbench_vocabularies.html [2001, May 20]
GEM element list [Online]. (Last updated: 2001, February 13). Available:
http://www.geminfo.org/Workbench/Metadata/GEM_Element_List.html [2001, May
20]
GEMCat training manual [Online]. (Revised: 2000, November 1). Available:

http://www.geminfo.org/Workbench/training/index.htm [2001, May 20]
Minnesota
Quam, Eileen. (2000, August). Minnesota metadata guidelines for Dublin Core
metadata: training manual [Online]. Available:
http://bridges.state.mn.us/bestprac/training.pdf [2000, August 28]
Quam, Eileen, & Olson, Robert. (Version: 1999, August 8). Minnesota Metadata
Guidelines - Dublin Core (MMG - DC): user guide For Dublin Core elements
[Online]. Available: http://bridges.state.mn.us/MMG-DCUserGuide.PDF [2000,
August 28]
NewsAgt
NewsAgent metadata elements: proposed definitions for NewsAgent Version 2
[Online]. (Date modified: 1999, July 12). Available:
http://www.ukoln.ac.uk/metadata/newsagent/metadata/ [2000, August 31]
B-2
Queensld
Superceded guidelines for embedding metadata in State Library’s Web pages using
Dublin Core [Online]. (Last revised: 2001, April 30). Available:
http://www.slq.qld.gov.au/meta/guidelinesdc.htm [2001, March 30]
Superceded templates for deploying metadata (using Dublin Core Metadata Element
Set) in the State Library of Queensland [Online]. (Last revised: 2001, April 30).
Available: http://www.slq.qld.gov.au/meta/templatesdc.htm [2001, March 30]
Thornely, Jennie. (2000). Metadata and the deployment of Dublin Core at State
Library of Queensland and Education Queensland, Australia [Online]. OCLC Systems
& Services, 16(3), 118-129. Available:
http://www.slq.qld.gov.au/pub/staff/metadeploy.htm [2001, March 17]
SAFARI
SAFARI fields [Online]. (Last update: 1999, October 13). Available:
http://www.lub.lu.se/~colm/safari/elements.html [2000, August 25]
Scout
Glassel, Aimee D., & Wells, Amy Tracy. (1998). Scout Report Signpost: design and
development for access to cataloged Internet resources. Journal of Internet Cataloging,
1(3), 15-45.
Solock, Jack, Wells, & Amy Tracy. (1999). Scout Report Signpost (Signpost). In
Wells, Amy Tracy, Calcari, Susan, & Koplow, Travis (Eds.), The amazing Internet
challenge: how leading projects use library skills to organize the Web, pp. 203-222.
Chicago: American Library Association, 1999.
Swedish
Schema for Dublin Core in the Swedish EnviroNet (SMN) [Online]. (Last updated:
2000, May 31). Available: http://smn.environ.se/schema/schema.htm [2001, May 31]
B-3
APPENDIX C
Raw Data Collected for the Use of Subelements
Table C1: Use of Subelement(s) for Title Element (A1)

No. Project DC Subelement(s) Used Non-DC Subelement(s) Used
1 ADTP Nil Nil
2 AVEL R - Alternative L - Main
3 BEP Nil Nil
4 BIBLINK R - Alternative Nil
5 CISMeF Nil Nil
6 Colorado Nil Nil
7 EdNA R - Alternative Nil
8 EULER R - Alternative Nil
9 FIU DL R - Alternative Nil
10 GEM Nil Nil
11 Minnesota Nil Nil
12 NewsAgt 4 Nil Nil
(implied in Alternate Title field, not
publicly displayed though
searchable)
13 Queensld R – Alternative Nil
14 SAFARI Nil Nil
15 Scout R – Alternative Nil
16 Swedish Nil Nil
Table C2: Use of Subelement(s) for Description Element (A5)

1 ADTP R2 - Abstract Nil
2 AVEL Nil Nil
3 BEP Nil Nil
4 BIBLINK Nil Nil
5 CISMeF Nil Nil
6 Colorado R2 - Abstract L - Freetext
7 EdNA R1 - Table of Contents Nil
R2 - Abstract
8 EULER Nil Nil
9 FIU DL Nil Nil
10 GEM Nil Nil
(implied in element definition: can
be abstract or brief summary,
maximum 2000 characters)
11 Minnesota R1 - Table of Contents Nil
R2 - Abstract
12 NewsAgt 5 Nil Nil
(implied in element definition: use
this element to supply a short
abstract)
13 Queensld Nil Nil
14 SAFARI Nil Nil
15 Scout Nil Nil
16 Swedish Nil Nil
C-1
Table C3: Use of Subelement(s) for Date Element (C3)

1 ADTP 6 R2 – Valid [Completion Nil
Date]
2 AVEL R1 - Created Nil
R5 - LastModified
3 BEP R4 - Issued L - Expiry
R5 - Modified
4 BIBLINK Nil Nil
5 CISMeF R5 - LastModified Nil
6 Colorado R1 - Creation [Date Original] L - Current [Date Created]
R2 - ValidFrom, ValidTo
R5 - Modified
7 EdNA Created Nil
Valid
Available
Issued
Modified
8 EULER Nil L - x-metadata-created [Metadata
Creation Date]
9 FIU DL R1 - Created [Date of Digitization] Nil
10 GEM R1 - Creation L - Placed Online
R2 - ValidFrom, ValidTo L - RecordCreated
R5 - Modified
11 Minnesota R1 - Creation L - Current
R5 - Modified (use TagGen DC tables for full
listing)
12 NewsAgt R2 - Valid [NewsAgent Expiry Nil
Date]
13 Queensld R1 – Created L - Verified
14 SAFARI R2 - Valid L - X-MetadataLastModified
15 Scout Nil Nil
16 Swedish R1 - Creation L - X-MetadataLastModified
R2 - Valid
Table C4: Use of Subelement(s) for Format Element (C2)

1 AVEL Nil Nil
2 BEP Nil Nil
3 BIBLINK Nil Nil
(Implied in local element
BIBLINK.Extent definition)
4 CISMeF Nil Nil
5 Colorado Nil Nil
6 EdNA R1 - Extent Nil
R2 – Medium
7 EULER Nil L - x-carrier [Physical Format /
(implied in local subelement Physical Carrier]
definition)
8 FIU DL R1 - used as Nil
Source.PartNo.Instance.Format.Fi
lesize [Has Part(s): File Size]
9 GEM R1 - File Size L - Contenttype
R2 - Platform
10 Minnesota Nil Nil
(implied in element definition:
C-2
formats can include physical

media and information concerning
the size of a resource)
11 NewsAgt Nil Nil
12 Queensld Nil Nil
13 Scout Nil Nil
Table C5: Use of Subelement(s) for Relation Element (A7)

1 AVEL 7 R1 - Is Version Of isBasedOn
isBasisFor
R2 - Has Version
R5 - Is Required By
R6 - Requires
R7 - Is Part Of
R8 - Has Part
R9 - Is Referenced By
R10 - References
R11 - Is Format of
R12 - Has Format
2 BEP R1 & R2 - Version Act
R6 - Requires Regulation
See-Also
Anomaly
3 Colorado R1 - Is Version Of Has Source
R2 - Has Version IsBasedOn
R5 - Is Required By IsBasisFor
R6 - Requires
R7 - Is Part Of
R8 - Has Part
R10 - References
R11 - Is Format of
R12 - Has Format
4 EdNA R1 - Is Version Of Nil
R2 - Has Version
R3 - Is Replaced By
R4 - Replaces
R5 - Is Required By
R6 - Requires
R7 - Is Part Of
R8 - Has Part
R10 - References
R11 - Is Format of
R12 - Has Format
5 FIU DL Subelement is not used, use sub- Local Sub-subelement:
Type.Relation No (9-digit FIU
subelements:
record no.)
R7 - Type.IsPartof [Collection
Name]
R8 - Type.HasPart [Source: Part
No. / Has Part(s)]
6 GEM Nil Kind
Description
LOCSPEC
PUBLIC-ID
7 Minnesota R1 - Is Version Of IsBasisFor
R2 - Has Version IsBasedOn
R5 - Is Required By (use TagGen DC tables for full
C-3
R6 - Requires listings)
R7 - Is Part Of
R8 - Has Part
R10 - References
R11 - Is Format of
R12 - Has Format
8 Queensld Nil Nil
Table C6: Use of Subelement(s) for Coverage Element (A6)

1 AVEL R1 - PlaceName Nil
R2 - PeriodName
2 BEP Subelement “PlaceName” is not Nil
used directly, use sub-
subelement:
R1 - PlaceName.Operation,
PlaceName.Region
3 Colorado R1 - Spatial Nil
R2 - Temporal (if possible,
provide temporal information, date
range, or time period in the
subject field)
4 EdNA 8 R1 - Spatial Nil
R2 - Temporal
5 FIU DL R1 - PlaceName [Coverage, Nil
Place]
R2 - PeriodName [Coverage,
Time]
6 GEM R1 - Spatial [Location] Code
R2 - Temporal [Time Period] Text
7 Minnesota R1 - Spatial Nil
R2 - Temporal
8 NewsAgt Nil Nil
(implied in element definition:
used to supply spatial coverage)
9 Queensld R1 - PlaceName Nil
R2 - PeriodName
10 SAFARI R1 - PlaceName [Geographical Nil
Location]
11 Swedish Subelement “Spatial” not used Nil
directly, use sub-subelement:
R1 - Spatial.AreaName
Table C7: Additional DC Elements (A2, A3, A4, B1, B2, B3, B4, C1, C4) with
Subelements Not Stated in the DCMI Recommendations
Project DC Element(s) with Subelement(s) / Sub-Subelement(s) Used
Subelement(s) / Sub-
subelement(s)
ADTP B2 DC.Creator.PersonalName
DC.Creator.PersonalName.address [Email]
AVEL B1, B2, B3 PersonalName
CorporateName
C-4
BEP A4 Industry
Topic
Good Service
Occupation
Staff
Land Building
Plant Equipment
B2 CorporateName
Jurisdiction
B4 Text
URL
BIBLINK B2, B3 Organization
CISMeF A4 Keywords
Colorado B1, B2, B3 PersonalName
CorporateName
EdNA Nil Nil
EULER B2, B3 PersonalName
CorporateName
FIU DL A2 Identifier [Source Std. No.]
Date.Created [Has Part(s): Date of Source]
B2, B3 Qualifier
Role
GEM A3 Subject path
Keywords
B1 NameCorporate [OnlineProvider / Publisher]
Role
Email
Postal
Phone
Contact
Homepage
B2 NamePersonal
NameCorporate
Email
Postal
Phone
Fax
Affiliation
Homepage (URL)
Role
B4 LOCSPEC (URL)
Agent
Use
Price code
C4 LOCSPEC
SID
SDN
Public_ID
Minnesota B1, B2 Corporate Name
Personal Name
B3 Many subelements, i.e. Page Designer, Illustrator,
etc. (Use TagGen DC table for full-listing)
NewsAgt Nil Nil
Queensld A2 Date
B1 CorporateName.Address
B2, B3 PersonalName
CorporateName
SAFARI B1, B2 CorporateName
CorporateName.Address PersonalName
C-5
PersonalName.Address
Scout Nil Nil
Swedish A4 EnvObjective
EnvThreat
Sector
Nature
Chemistry
Species
General
EnvData.Program
EnvData.Medium
EnvData.Variable
B1 CorporateName
CorporateName.Address
B2 CorporateName
CorporateName.Address
PersonalName
PersonalName.Address
C-6
APPENDIX D
Raw Data Collected for the Use of Encoding Schemes
Table D1: Use of Scheme(s) for Source Element (A2)

No. Project DC Scheme(s) Used Non-DC Scheme(s) Used
1 BEP Nil Nil
2 BIBLINK Nil Nil
3 Colorado Nil L – FPI
L – ISBN
L – ISSN
4 EdNA S - URI Nil
5 FIU DL Nil L – ISBN
L – ISSN
L – Wolfsonian Accession No.
(3 local schemes for Source Standard No.)
6 Minnesota Nil L – FPI
L - SICI
L - ISSN
L - Version
7 Queensld S - URL L - ISBN
S - URN L - ISSN
Table D2: Use of Scheme(s) for Language Element (A3)

1 ADTP S2 - RFC 1766 Nil
2 AVEL S2 - RFC 1766 L - ABS1267
(for Aboriginal languages,
Australian Bureau of Statistic
Standard)
3 BEP S2 – implied, as BEP uses the L - Appendex 4.9 (S2 - implied)
AGLS recommendations, which is BEP uses the AGLS
based on RFC 1766 recommendations, which is based
on RFC 1766
4 BIBLINK S2 - RFC 1766 Nil
5 CISMeF S2 - RFC 1766 Nil
6 Colorado S2 - ISO 639-1 (2-letter code) Nil
(implied RFC 1766)
7 EdNA S1 - ISO639-2 L - ABS1267
S2 - RFC 1766 (for Aboriginal languages,
Australian Bureau of Statistic
Standard)
8 EULER S2 – ISO 639-1 (2-letter code) Nil
(implied RFC 1766)
9 FIU DL Nil L - ANSI Z39.53 (3-letter code)
10 GEM Nil L - ANSI Z39.53 (3-letter code) and
/ or Z39.53 full-spelling of the
language
11 Minnesota S2 - ISO 639-1 is the Nil
preferred scheme, see TagGen
DC table for full listing
(implied RFC 1766)
12 NewsAgt S2 - RFC 1766 (implied) Nil
13 Queensld S2 - ISO 639 (2-letter code) L - Z39.53 (3-letter code)
(implied RFC 1766)
14 SAFARI S2 – ISO 639-1 (implied RFC Nil
1766)
D-1
15 Scout S2 - RFC 1766 L - NISO Z39.53

L - ISO 3166
S - WD-DCTYP
L - Cataloging Internet Resources
16 Swedish S1 - ISO639-2 Nil
Table D3: Use of Scheme(s) for Subject Element (A4)

1 ADTP S1 - LCSH Nil
2 AVEL S1 - LCSH (used if no AVEL Thesaurus (based on Ei Thesaurus
suitable subject in AVEL and ACM Computing Classification
Thesaurus) System)
3 BEP Nil Appendix 4.2
Appendix 4.3
Appendix 4.4
4 BIBLINK S1 - LCSH Nil
S3 - DDC
S4 - LCC
S5 - UDC
5 CISMeF S2 - MeSH Nil
(also use the French
translation)
6 Colorado Established thesaurus Established thesaurus
S1 - LCSH L - TGM
S2 - MeSH L - AAT
S3 - DDC L - ICONCLASS
S4 - LCC
7 EdNA S1 - LCSH L - ASCED
S2 - MeSH L - APSDEP
S3 - DDC L - EDNA-KLA (Schools Key Learning
S4 - LCC Areas)
S5 - UDC L - SCIS
8 EULER S1 - LCSH L - MSC
S3 - DDC L - CCS
9 FIU DL Nil L - TGM I
L - AAT
L - LC AF
L - FIU Subject Coverage Terms List
[Subject Coverage]
10 GEM Nil L - GEM Subject Vocabulary for "subject
path" [GEM Subjects]
L - ERIC [Other Subjects]
L - NICEM [Other Subjects]
11 Minnesota S1 - LCSH L - LIV-MN
S2 - MeSH L - AACR2
S4 - LCC L - Keywords (rarely used)
12 NewsAgt Nil L - NATopic Classification Scheme
[NewsAgent.Topic]
13 Queensld S1 - LCSH Nil
14 SAFARI Nil L - CERIF Classification System
(developed and maintained by EU)
15 Scout S1 - LCSH L - Subject Cataloging Manual (Subject
S4 - LCC Subdivision)
16 Swedish Nil L - Environment Quality Objectives
L - Environment Threats
L - Sectors
L - Native Types
L - Chemical Substances
L - Biological Species
D-2
L - Environment Work
L - Environment Data / Statistics
L - Medium
L - Variable
Table D4: Use of Scheme(s) for Coverage Element (A6)

1 AVEL Nil L – AVEL (PlaceName)
L - ISO8601 (PeriodName)
2 BEP Nil L - Appendix 4.1 (PlaceName)
L - Appendix 4.10 (PlaceName)
3 Colorado S6 - W3C-DTF (Temporal: to L – Latitude / Longitude
enter a date / date range) Coordinates (Spatial)
L – OSGB (Spatial)
L - LCSH (Temporal: to select time
periods)
4 EdNA S1 - DCMI Point (Spatial) L - edna-spatial (Spatial)
S2 - ISO 3166 (Spatial)
S3 - DCMI Box (Spatial)
S4 – TGN (Spatial)
S5 - DCMI Period (Temporal)
S6 - W3C-DTF (Temporal)
5 FIU DL Nil L - ISO 8601 (Coverage.Time)
6 GEM Nil Nil (no information provided)
7 Minnesota Nil L – Latlong (Spatial)
L – OSGB (Spatial)
L - ANSI X3.30-1985 (Temporal)
8 NewsAgt Nil L - NA Coverage Controlled List
(Spatial Coverage)
9 Queensld Nil L – LCSH for (Spatial & Temporal)
10 SAFARI S4 - TGN (PlaceName) Nil
11 Swedish Nil L - SMN scheme (Geographic
Areas)
Table D5: Use of Scheme(s) for Relation Element (A7)

1 AVEL S - URI Nil
2 BEP Nil Nil
3 Colorado S - URL L - ISBN
S - URN L - ISSN
L - FPI
4 EdNA S - URI Nil
5 FIU DL Nil L - FIU DL 9-digit Record No. (implied in
[Relation No.])
6 GEM S -URL (for "LOCSPEC" L - GEM Relation Controlled Vocabulary
subelement) L - Scheme varies (for "Public_ID"
subelement)
7 Minnesota Nil L - FPI
L - ISBN
L - ISSN
8 Queensld S - URL L - ISBN
S - URN
Table D6: Use of Scheme(s) for DC Type Element (C1)

1 AVEL S - WD-DCTYP L - Avel Resource Type (for more specific
values)
2 BEP Nil L - Appendix 4.6
D-3
3 CISMeF Nil L - CISMeF scheme

(includes French translation)
4 Colorado S - WD-DCTYP Nil
5 EdNA S - DCMI Type Vocabulary L - edna-document
L - edna-curriculum
L - edna-event
6 EULER S - DCRT Structuralist L - EULER Specific Types
7 FIU DL Nil L - Locally developed
FIU list
(implied local scheme: Resource Types
used
for text are based on
DCRT Structuralist)
8 GEM Nil L - GEM Controlled Vocabulary
9 Minnesota Nil L - (implied local scheme: select
from enumerated list)
10 NewsAgt S - DCMI Type Vocabulary L - NA Type list
(also used in MD template)
11 Queensld S - DCRT Minimal Nil
(implied: use Structuralist if
necessary)
12 SAFARI Nil L - Locally developed
list
13 Scout S - WD-DCTYP L - LCSH
L - Subject Cataloging Manual
L - Bibliographic Formats & Standards
14 Swedish Nil L - SMN scheme
[Document Type]
Table D7: Use of Scheme(s) for DC Format Element (C2)

1 AVEL S - IMT Nil
2 BEP S - IMT L - Appendix 4.7
3 BIBLINK S - IMT Nil
4 CISMeF S - IMT Nil
5 Colorado S - IMT Nil
6 EdNA S - IMT Nil
7 EULER S - IMT L - EULER specific physical carriers draft
list [DC.format.x-carrier]
8 FIU DL Nil Nil
9 GEM S - IMT L - GEM Controlled Vocabulary
[Contenttype]
10 Minnesota S - IMT L - TagGen DC Table for full listing
11 NewsAgt S - IMT Nil
12 Queensld Nil Nil
(implied scheme in element definition: for
the sake of interoperability, FORMAT
should be selected from an enumerated
list that is under development in the
workshop series at the time of publication
of this document”
13 Scout Nil L - LCSH
L - WD-DCTYP
L - Subject Cataloging Manual (Subject
Subdivision)
D-4
Table D8: Use of Scheme(s) for Date Element (C3)

1 ADTP S2 - W3C-DTF L - ISO 8601
2 AVEL S2 - W3C-DTF L - ISO 8601
3 BEP Nil L – Appendix 4.5
4 BIBLINK Nil L - ISO 8601
5 CISMeF Nil Nil
6 Colorado S2 - W3C-DTF L - ISO 8601
7 EdNA S1 - DCMI period Nil
S2 - W3C-DTF
8 EULER Nil L - ISO 8601
9 FIU DL Nil L - ISO 8601
10 GEM Nil L - ISO 8601:1988 [Date.RecordCreated]
L - ANSI X3.30-1985
11 Minnesota Nil L - ISO 8601
L - TagGen DC Table for full listing
12 NewsAgt S2 - W3C-DTF Nil
13 Queensld S2 - W3C-DTF Nil
14 SAFARI Nil L - ISO 8601
15 Scout S2 - W3C-DTF L - AACR2R
16 Swedish Nil L - ISO 8601
Table D9: Use of Scheme(s) for Identifier Element (C4)

1 ADTP S – URI Nil
2 AVEL S – URI L - ISBN
L – ISSN
(for non-electronic resources)
3 BEP S – URL L - Appendix 4.8, includes
ISBN & ISSN (for non-electronic
resources)
4 BIBLINK S – URI, URL L - DOI
L - ISBN
L - ISSN
L - SICI
5 CISMeF S – URL (implied) Nil
6 Colorado S – URL, URN (for For other resources, use global, unique
networked resources) identifiers such as:
L - ISBN
L - ISSN
L - Accession No. (no. unique within an
institution)
7 EdNA S - URI Nil
8 EULER S – URL, URN L - ISBN
L - ISSN
L - EULER specific scheme (for "De-
duplication Identifier": generated
uniformly by automated procedure)
9 FIU DL S - URL Nil
10 GEM S - URL (for “LOCSPEC" L - GEM Consortium assigned unique site
subelement) identifier (for "SID" subelement)
L - Local site identifier schemes (for
"SDN" subelement)
L - ISSN, ISBN (for "Public_ID"
subelement)
11 Minnesota S – URL, URN L - ISBN
L - ISSN
D-5
L - PURL
12 NewsAgt S – URL (implied) Nil
13 Queensld S – URL, URN L - ISBN
L - ISSN
14 SAFARI S – URL Nil
15 Scout Nil L - Cataloging Internet Resources
16 Swedish S – URL Nil
Table D10: Additional DC Elements (A1, A5, B1, B2, B3, B4) with Scheme(s) Not
Specified in DC Schema
Project DC Element(s) with Scheme(s) Used

Scheme(s)
ADTP B4 URI
AVEL B1 AVEL [AVEL Publisher]
B4 URI
BEP A5, B4 URL
B2 BEP Appendix 4.1, for rest of the world use ISO 3166
for country codes (“jurisdiction” subelement)
BIBLINK B4 URL
CISMeF Nil Nil
Colorado A1, A5, B1, B2, B3 Follow AACR2, APPM, CDWA, VRA (or other)
established cataloging rules
B4 URL
EdNA B4 URI (Best practice)
EULER B2, B3 MARC (“PersonalName” subelement)
FIU DL B2, B3 (“Role” subelement)
AACR2
LCNAF
GEM B1 GEM controlled vocabulary ("Role" subelement)
URL ("Homepage" subelement)
B2 URL ("LOCSPEC" subelement)
B4 L - URL ("LOCSPEC" subelement)
L - GEM Price Code ("PRICECODE" subelement)
Minnesota A1, B1, B2, B3 AACR2
B4 URL (implied)
NewsAgt Nil Nil
Queensld B2, B3 LCNAF (“CorporateName" subelement)
B4 URL
SAFARI Nil Nil
Scout A1 AACR2R
Cataloging Internet Resources
Chicago Manual of Style
A5, B1 AACR2R
Cataloging Internet Resources
B2 AACR2R
Chicago Manual of Style
B3 AACR2R
Swedish B1 SMN scheme for Members / Publisher
(“CorporateName” subelement)
D-6
APPENDIX E
Use of Local / Non-DC Metadata Elements
Eight local elements were used for CISMeF, they are Institution, City, Province
/ State, Country, Target, Type of access, Cost, and Sponsorship.
Table E1: Local Element Name(s) and Definition(s) used for AVEL Project
1) AGLS.Availability
How the resource can be obtained or contact information, will be displayed to the
user as significant information regarding the availability of the resource. Primarily
used for non-electronic resources when a user needs to physically obtain copies of
the resource or provide access to the resource. Include information on registration
and authentication requirements for electronic resources, i.e. available only to staff
and student of Queensland University.
2) EdNA.Review
Functions like a book review. Reviews could be created as separate Web pages,
with the AVEL software storing the URL of the review(s) as part of the information
about a resource.
3) AC.Creator
The person responsible for creating / modifying The metadata pertaining to a
resource.
4) AC.DateCreated
Date the metadata was created or last modified.
5) AVEL.Comments
Use this element for any comments regarding The creation of The metadata,
especially to record any significant related issues. Used as a repository of
anecdotal information for future reference.
Table E2: Local Element Name(s) and Definition(s) used for BEP Project
1) AGLS.Function
The business function of the agency to which this resource is related.
2) AGLS.Availability
The point of contact from which the resource can be obtained, primarily intended
for resources, such as physical objects and services, that cannot be acquired
electronically, but instead need to be ordered in physical form.
Table E3: Local Element Name(s) and Definition(s) used for BIBLINK Project
1) BIBLINK.Checksum
A hash value computed for authentication purposes, generated from the resource.
Automatically using the checksum too.
2) BIBLINK.Edition
A text string indicating the version or edition of the resource.
3) BIBLINK.Extent (implied sub-element of DC.Format)
The ‘size’ of the resource, e.g. in bytes, number of files, or number of CD-ROMs.
4) BIBLINK.Frequency
The frequency of issue if a serial publication
E-1
5) BIBLINK.PlacePublication (implied sub-element of DC.Publisher)

Geographic location of publisher
6) BIBLINK.Price
A simple, retail price.
7) BIBLINK.SystemRequirements
Hardware or software requirements for the system needed to view the resource.
Table E4: Local Element Name(s) and Definition(s) used for EdNA Project
1) EDNA.Audience
A category of user for whom the resource is intended.
2) EDNA.Approver
E-mail of person or organization approving the item for including in EdNA. For
administrators who directly administer items in the EdNA Online database this
element is automatically assigned.
3) EDNA.CategoryCode
A numerical code derived from the database tables which support the EdNA Online
Browse Categories
4) EDNA.Entered
Data item was entered as an entry in the Online item database, used for
management purposes. Created automatically by EdNA Online database software
and should not be encoded into the metadata of source documents.
5) EDNA.Indexing
To what extent should Edna Online indexing (“spidering”) software follow links from
this page
6) EDNA.Review
A third party review of the resource. Either a short evaluative comment or a more
formal review pointed to by a URL.
7) EDNA.Reviewer
Name of person and / or organization or authority affiliated with the review
8) EDNA.Version
Version of the EdNA metadata standard applied, for administrative tracking
purposes.
Table E5: Local Element Name(s) and Definition(s) used for EULER Project
1) EULER.Identifier
An unambiguous reference to the resource within a given context: The purpose of
this field is to identify the resource in other ways than those provided by the other
fields. This can be serial name, page-, issue- or volume-numbers for journal
articles or similar. (Can be used differently in different databases, e.g. ISO 4-1984).
2) EULER.Fulltext = Full text
The fulltext of web-pages and other resources available as a whole
3) EULER.Event.Location = Event location
For Conference proceedings, location of event for/at which the resource described
in the record was created
4) EULER.Event.Date = Event Date
For Conference proceedings, date of event for/at which the resource described in
the record was created
E-2
5) EULER.Event.Name = Event name

For Conference proceedings, name of event where document was created
6) EULER.Record.Source = Record source
The source for the record i.e. describes which information provider has delivered
the record
7) EULER.Record.Sourceidentifier = Record source URL
Identifier of source record for the description delivered in EULER. URL pointing
back to the original record at information providers' site
8) EULER.Record.Creator = Record creator
Creator of the record (describing the resource), e.g. a reviewer
9) EULER.Delivery = Address for delivery information
Meant to give the URL to the library where the resource described in the record
can be acquired. (Pointer to online-order forms etc.)
10) EULER.Delivery.Description.= Additional retrieve/delivery information
Additional information that a user and a local library need to retrieve/deliver the
resource described in the record
Table E6: Local Element Name(s) and Definition(s) used for FIU DL Project
1) Record Identifier
A unique 9 digit number assigned to each record in the Repository database. Used
to search record numbers within the FIU Digital Library and used with a cgi script
to create URL for Z39.50 gateway searches. When new metadata record is
created, the Record Identifier is the same as the 9-digit barcode no. that has been
assigned to an object (image, sound) or group of objects). Barcode can be
scanned into this field.
2) Next in Workflow (No definition provided.)
3) Public Note
To provide additional information on the resource that does not fit into any other
metadata element or to further describe an element that uses controlled terms. A
free text field for any information the cataloger thinks the patron may need to know
to understand the resource that is not already provided for in another Dublin Core
field. The Note element is used to provide any additional information needed to
assist the user in knowing about the resource being viewed. A common use for this
element is to give credit to an individual who donated the image or other resource
to the FIU Digital Library.
4) Cataloger’s Note
An internal administrative note for the person(s) creating and updating the
metadata which may be about the metadata creation and maintenance process or
some aspect on the management of the resource. Not displayed to the user and is
only searchable using the "Word(s) Anywhere" command on the search templates.
Table E7: Local Element Name(s) and Definition(s) used for GEM Project
1) GEM.Audience
Indicates the special nature or needs of the individual, class, group, etc. being
taught. Information about (1) An educational tool for whom? and (2) Who is the
ultimate beneficiary?
E-3
2) GEM.Cataloging
Cataloging Agency provides basic information about the person or agency that
created the GEM catalog record.
3) GEM.Duration
Contains a brief textual description of the duration of the activity or lesson. Time
and/or number of sessions needed to conduct the activity/lesson as specified in the
educational resource.
4) GEM.EssentialResources
Additional resources / materials needed for effective use of the resource being
cataloged
5) GEM.Grade
Specifies the grade, grade span or educational level(s) of the target audience of
the resource
6) GEM.Pedagogy
Refers to the method suggested to present the resource and to evaluate student
progress, - Teaching methods, student groupings, and assessment methods
specified in the educational resource. Prerequisites can also be noted.
7) GEM.Quality
Quality Indicators element is a means of assessing the quality of instructional
materials, - Assessment of an educational resource using a rating scale from 1
(poor) to 5 (excellent).
8) GEM.Standards
State and/or national academic standards mapped to the entity being described.
- Description of a state or national standard that has been given to the educational
resource being cataloged either by the cataloging agency, the creator of the
educational resource, or some independent person or agency.
Table E8: Local Element Name(s) and Definition(s) used for NewsAgt Project
1) NewsAgent.Contact
A contact point for further information about the resource. May be used to indicate
the supplier or help-desk for a product. Use a name, an email address or a
combination of both as the value of this element.
Table E9: Local Element Name(s) and Definition(s) used for Queensld Project
1) Keywords
Web authors to provide a series of keywords or phrases about the contents of the
page separated by commas(,).
2) Description
Web authors to give a freetext description or abstract of the contents of the page.
Giving a good description of the content of the page in this element is important as
most search engines do index Web pages with metadata using information from
the description element.
E-4
Table E10: Local Element Name(s) and Definition(s) used for SAFARI Project
1) Safari.TargetGroup
Primary target group for the resource. One way of classifying the information in
SAFARI therefore, is to specify which target group the information is intended for.
Today, there are four pre-defined alternatives when metadata-labelling research
information: General/schools, Companies/organisations, Students of higher
education, Researchers/experts.
Table E11: Local Element Name(s) and Definition(s) used for Scout Project
1) Date URL Last Verified
Refers to the last time the resource’s location was verified as working.
2) Date of Scout Report Review
Refers to the date the resource actually appeared in any scout report
3) Resource Location
Indicates the domain or affiliation of the site. Currently includes: commercial,
education, government, military, network, and organization. Based on the 6 current
top-level domains (.com, .edu, .gov, .mil, .net, and .org).
4) Source of Cataloging
Not publicly displayed. Identifies the individual responsible for cataloging a
resource.
5) Record ID
Not publicly displayed. A unique number automatically assigned at the time a
Signpost record is created.
6) Scout Report Review URL
Refers to the address of the scout report in which the resource was reviewed.
7) Scout Publication
Not publicly displayed. Serves as an in-house element that allows them to quickly
determine whether a resource is from the Scout Report or any of the subject-
specific scout reports.
E-5

Study of The Use of Metadata Standards For Cataloging Internet Resources - Thesis by NTU Student

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Study of The Use of Metadata Standards For Cataloging Internet Resources - Thesis by NTU Student

Uploaded by

Copyright:

Available Formats

ATTENTION: The Singapore Copyright Act applies to the use of this document. Nanyang Technological University Library.

NANYANG TECHNOLOGICAL UNIVERSITY

A STUDY OF THE USE OF METADATA STANDARDS FOR

Submitted in Partial Fulfillment of the Requirements

SCHOOL OF COMPUTER ENGINEERING

A variety of metatadata standards have evolved in the recent years under

management and organization of resources, and (d) for interoperability and / or

Upon the completion of my thesis, I would like to express my heartfelt

I would also like to thank the Nanyang Technological University Library

Chapter 2 Literature Review 5

Chapter 6 Summary and Conclusions 53

1.1. Background on Metadata and the Dublin Core Metadata Initiative

According to the Dublin Core Metadata Initiative (“DCMI Frequently Asked

After a study of 27 potential definitions, American Library Association (ALA)

In the context of this research, metadata would be treated as any structured

As Lee-Smeltzer (2000) aptly pointed out, the phenomenal growth of digital

Dublin Core Metadata Element Set (DCMES) is a metadata standard employed

The Dublin Core is a 15-element metadata element set intended to facilitate

1.2. Problem Statement

The study attempted to focus on the following specific objectives:

! To explore the deployment, storage and retrieval of DC metadata for

This is an exploratory study on the use of DCMES by project implementors. The

1.3. Organization of Dissertation Chapters

2.1. Metadata in General

(1) Constituency (Who is actively using this record format? Is it associated

(4) Associated Internet protocols - whether particular metadata formats can

Metadata implementors began to realize that interoperability between different

Especially of interest to the library community would be “Dublin

a) Enhancement of simple resource description record - a cataloging

b) Searching across syntaxes and databases - libraries have large systems

Another good example is the book entitled “Introduction to metadata: pathways

2.2. Dublin Core Metadata Initiative (DCMI)

(1) Embedded Metadata

embedded metadata is that no additional system must be in place to use

created within the database or extracted from another source, such as

Besides dealing with issues regarding metadata deployment, several other

2.3. Applications of Metadata Standard (with focus on Dublin Core)

A large amount of information and documentation, both in print and on the

Zeng (1999) reported on a project that applied existing metadata formats to

States MAchine-Readable Cataloging (USMARC) format, and the Visual Resources

In another research paper, Fullerton, Greenberg, McClure, Rasmussen, and

This implied that scenarios where a second generation of metadata standards

Although only a handful of DC projects, limited to those in scientific domains,

With more and more organizations, disciplines, industries and businesses

becomes mature, an increase in non-information professional metadata creation could

3.1. Selection of Dublin Core Projects

The following sixteen projects were selected:

1) Australian Digital Theses Program (ADTP)

3.2. Data Collection

In view of that, I have decided to carry out an exploratory survey of DC

After studying the results of an earlier survey conducted for thirty-two DC

Each of the above section was made up of a mixture of open-ended and

Table 3.1: Summary of DCMES and Qualifiers

3.3. Presentation of Data

4.1. Consistency with the Use of Dublin Core Elements

Dublin Core Elements Used

Besides the usage of DC elements in the projects surveyed, many of them

4.2. Consistency with the Use of DC Qualifiers – Element Refinements

Title (A1) 100

Language (A3) 100

Subject and Keywords

Description (A5) 100

Publisher (B1) 100