But how shall we deal with the case when author and artist are different? Is the element to be
repeated? Would it not be necessary to distinguish explicitly between them? Such questions and
the scarcity of elements evolved into the development of the so-called qualified DC, an exten-
sion which was intensely debated, as it endangered the original intention of DC to provide an
easy and simple semantic format to cover all possible Web objects.While there may be an advan-
tage in using extended DC, as it is easier to generate the standard DC mandatory for OAI, there
are some drawbacks as to the flexibility of tagging and structuring.Therefore, although it might
be a solution to use expanded DC, it seems much better to adopt the second approach, namely,
to draw up an entirely new metadata set, especially designed for emblems. Only the latter solu-
tion ensures that all information required for the description of emblems is represented in the
best possible way. Standard DC could then be generated by either selecting parts of the metada-
ta set or by reducing the number of descriptive elements.
As stated, both approaches are feasible, but the latter offers significant advantages, since an espe-
cially designed emblem standard allows us to establish a category list and data model without any
formal restrictions and in accordance with the special demands posed by the description of
emblems.The scope of metadata for emblems ranges from multilingual descriptors to image clas-
sification systems like Iconclass. Because plain DC is mandatory, one nevertheless must agree on
how a sophisticated and more detailed emblem record should be mapped to a DC record, that is,
how author and artist are to be treated.
Thus, while it is apparent that OAI is best suited to transport emblem metadata, the emblem
metadata set is an indispensable prerequisite.Without it, a successful application of OAI is not
E m b l e m M e t a d a t a S e t
In developing an appropriate OAI metadata set it is reasonable to rely on Stephen Rawles'
recently updated template, or "spine,"
as it provides us with a good starting point and is the result
of lengthy discussions which have taken place in the emblem community. It is just a question of
reformatting, as it were, to transform this category list into a XML structure or XML schema,
which is necessary for an OAI-compliant emblem metadata set.The XML schema definition will
comprise all necessary information about the syntax and content of an emblem data record or, if
one prefers the term, emblem entity. Both aspects, syntactic structure and content, will be treat-
ed very briefly and are followed by some remarks about the XML schema.
The establishment of the syntactic structure includes the question of how the entities involved
are related to one another and which quantifiers are to be assigned, that is, how frequently the
various entities may occur.This could also be expressed by an entity relationship model.Accord-
ing to Stephan Rawles' template we may distinguish two main entities:
(a) Information Headings for Copies of Books,
(b) Information Headings for Individual Emblems.
The first question which arises is how both of them are related.While Rawles' "spine" does
not tell us anything about that, it is crucial for the structural design.Two approaches are possible.
Either we assume a 1:1 or a 1:N relation.A 1:1 relation, in fact, allows reducing both of the enti-
ties to one entity.This model would require that we repeat all book copy information for every
emblem. Although this method would be easier to process with regard to a database conversion,
I do not consider it adequate as it causes redundancies and is not as clear as the 1:N relation,
html/spine.htm. See the contribution
by Stephen Rawles in this volume.
DC_Emblemsbook_180204 19.02.2004 11:26 Uhr Seite 91