1 Introduction
This document describes the way the Emblem Project Utrecht has implemented the
Open Archives Initiative, a protocol for Metadata Harvesting.
Our implementation is experimental, and is meant as a first step towards exposing our
emblem data to the wider world. More specifically, we tries to integrate our data
with those of other emblem digitisation projects, most notably the
German Emblem Book Database at the University of Illinois, Urbana-Champaign.
This document does not discuss the Open Archives Initiative or the OAI-PMH protocol.
More about the protocol can be found on the
OAI website
.
The document also does not discuss the Dublin Core Initiative’s set of metadata. More about
Dublin Core Metadata Initiative (DCMI) can be found at the
DCMI website.
THe EPU’s implementation of AOI-PMH uses unqualified Dublin Core metadata. This is
just a first step towards a more structured exchange of metadata. An XML Schema, which will facilitate
OAI-PMH compliant exchange of detailed emblem metadata, is under development
at the Herzog August Bibliothek in Wolfenbüttel. The Emblem Project Utrecht is a partner in the
'Open Emblem' Initiative which coordinates the emblem metadata integration efforts being done in
individual emblem digitisation projects.
The main problem in implementation is that it never clearly chooses between providing
metadata for the emblem, or for the modern version. We provide, for instance, two
publisher elements: a publisher for the original book, and a publisher of our own edition.
There may even be a third publisher element, if
our own version is based on a modern edition of the book (as in the case of
Cats or Hooft).
The first section of this document discusses how we use the 15 Dublin Core elements. The
second section discusses the technical implementation.
Table of contents
2 Dublin Core Elements
2.1 General Remarks
The form of the personal names occurring in the Dublin Core (DC) elements is the one used in the
EPU bibliography.
Dates given, use the contents of the value attribute of the date-element,
if present, or else the element’s text content.
Where multiple DC elements of the same type were needed, multiple corresponding XML elements
to hold the information, were used.
This was done, rather than use a single XML element as well as comma’s or semi-colons
to distinguish the individual DC elements.
2.2 Title
We filled the DC title-element with the list of titles for the
emblems and preliminary texts, this is discussed inTitles. This
list generally contains a lower-case version of the motto.
2.3 Creator
We created a DC creator-element for each of the original authors of the book.
We do not distingiush
between the primary author (such as Vaenius), the secondary author (such as, Alonso de Ledesma,
Amoris divini emblemata), or the artist
of the pictura. These elements are created for each of the texts in a book, even if they are
not emblem texts. We may refine this procedure in the future.
For the liminary texts, an additional creator-element is used to hold the contents of the
signed or docAuthor-elements, if present.
2.4 Subject
At present, the only DC subject-elements that we created are those for the pictorial motifs.
2.5 Description
A DC description-element is created for each of the emblem texts. Each quotation, epigram, or
motto is represented in a separate description-element. At present, we have ignored the bibliographical
references given by the emblem author or by the modern editors. Each description-element
carries a xml:lang attribute to represent the language of the text. The language codes
are based on ISO 639-1.
2.6 Publisher
A DC publisher-element is created for each of the publishers relevant to the emblem, as
represented on the EPU site. So the original publisher, the EPU itself, and possibly
the publisher of a modern edition on which the EPU has been based, all have elements.
2.7 Contributor
At present, the DC contributor-element is used to acknowledge the
contribution of modern translators (Dutch or English). For 17th century translators, we
use the creator-element.
2.8 Date
The way we use the DC date-element corresponds to the way we use the
publisher-element. The date of publication of each of the relevant editions is given.
2.9 Type
We created DC type-elements with values for text and image, this was taken from:
).
2.11 Identifier
The emblem URL is used as contents for the DC identifier-element.
2.12 Source
We created two types of DC source-element. One is filled using just the call number of
the copies, which form the basis for our editions. The second form contains a very simple
bibliographic description.
2.13 Language
For each language used in the text, a DC language-element is created
(using ISO 639-1 codes).
2.14 Relation
We created DC relation-elements to relate the emblem to the full book,
for each image file (facsimile) related to the
present emblem, and for each related emblem. URL’s are used to identify related emblems,
which may be from the same book, from elsewehere on the EPU site or from elsewhere on the
Internet.
We are still discussing the feasability of adding relation-elements for other
sources, such as, quotations from the Bible or Ovid.
2.15 Coverage
Not in use.
3 Technical Implementation
The EPU’s technical implementation of OAI is very simple. For each emblem or liminary text,
a file
is generated which contains the metadata for that text. We use the
XMLFile OAI software written by
Hussein Suleman at Virginia Polytechnic Institute and State University,
to provide the Open Archive data provider functionality. XMLFile uses the
generated files as the metadata source. The generated files are stored in directories whose names
correspond to the book abbreviations we use at EPU (ca1627, va1608, etc). The directory names double
as OAI set names.