Roger Clarke's 'Beyond the Dublin Core'

The Metadata Guide for the BEP Information Service is available (in 232KB of PDF), at http://about.business.gov.au/bep/agencies/provinfo/metadata/metadata_guide.pdf (I provided design and authorship assistance to that exercise)

The Australian Government Locator Service (AGLS), which is the Australian Governments' implementation of Dublin Core, is at http://www.naa.gov.au/govserv/agls/default.htm

This document is at http://www.rogerclarke.com/II/DublinCore.html

Abstract

This paper has been prepared by a non-librarian and non-specialist in data modelling. It is a reaction against what the author perceives as the dangerous simplicity of the Dublin Core. It explains the author's disquiet, and proposes ways in which that scheme's proponents can achieve their aims without creating something that we'll all shortly regret.

Introduction

Meta-data is information about data. For example, some of the things that are useful to know about this document are its title, its author, its version-identification, rights information, location(s), and topic.

Librarians deal in meta-data, although terms like 'catalogue data' may have been more commonly used in the past. The term 'meta-data' originated in the computing and information systems disciplines and professions, particularly in the data modelling and database specialisations; so its adoption by librarians may signify a degree of drawing together of the two fields. This paper argues that, unfortunately, the term has been adopted without a sufficient appreciation of the important substantive capabilities that should travel with it.

Some day, artificial intelligence may make it easy to find information; but that is decades or millenia away, depending on how confident you are about the uniqueness of human intelligence. In the meantime, a means of achieving reasonably consistent descriptions of content-providing objects of various kinds is critical to our usage of libraries, both physical and electronic.

Several initiatives are in train to address the need. A very recent one of especial interest is a 'Meta Content Framework using XML' (MCF), a proposal from Apple and Netscape submitted to W3C in June 1997.

One activity has been in train since 1995, and is attracting considerable interest among librarians and some other groups. The Dublin Core is a set of 'core' data-elements that were first discussed in a meeting in Dublin (Ohio, not Ireland). The Dublin Core is relatively simple; in fact it is extremely simple. This is being touted as a great advantage. Unfortunately this simplicity is also the achilles heel of the whole undertaking.

The purposes of this paper are:

to establish that meta-data for objects that are intrinsically complex needs to have a rich structure;
to show that this richness does not necessarily imply that user interfaces must be unwieldy; and
to point the way towards a solution that is superior to the present Dublin Core proposal in regard to data structures, and capable of being easy to use.

Introduction

The Need

The Dublin Core

Serious Weaknesses in the Dublin Core

Appendix 1: Some Test-Cases for Meta-Data

Appendix 2: An Intuitive, Partial Data Structure

The Need

As a result of tremendous advances in literacy, knowledge and relevant technologies during the present century, vast number of items are being published. The scope provided by the world-wide web has resulted in yet more people publishing yet more items. In addition to text, many other formats have become increasingly amenable to creation and dissemination.

It is highly desirable that some degree of order be maintained among the tumult, and that these publications be able to be discovered by people who would like to access them.

In order to achieve these aims, information is needed about each publication. The term commonly used for such information is 'meta-data', because it exists at a level once removed from the object itself.

A variety of forms of meta-data exist. The profession of librarianship and the discipline of information science concern themselves with the matter. So too do data modelling specialists within the computer science and information systems disciplines.

An important example of a meta-data arrangement is the MARC (MAchine Readable Catalogue) scheme, which is a powerful language for cataloguing books and other publications, established and administered by the U.S. Library of Congress.

Many specialised cataloguing schemes exist, targeted at particular types of publication, or particular formats; for example, standards abound in the area of geographical information systems / land information systems.

With power comes complexity. After a couple of decades of struggling with MARC, and similar large-scale sets of rules, there is a desire felt by many librarians for a simpler approach.

The drift towards an alternative meta-data scheme has gathered momentum during recent years, because cataloguing the vast volumes of publications that are exploding onto the world-wide web simply is not practical using powerful-but-complex mechanisms like MARC. There are too many documents; and too large a proportion of them are ephemeral, or are modified and replicated in ways that, from the perspective of conventional publishing, is too undisciplined. There is a need for a blend of self-cataloguing by originators, and automation.

"Why doesn't somebody do something?!", they all said. A group of people has set about addressing the need, and their efforts have attracted a great deal of support.

The Dublin Core

The Dublin Core 's purpose is to enable searching in a more sophisticated manner than mere free-text indexing and search engines can support, without requiring professional cataloguing effort to be invested. In the home-page's own words: it specifies "a simple resource description record that has the potential to provide a foundation for electronic bibliographic description that may improve structured access to information on the Internet and promote interoperability among disparate description models".

The intention is that meta-data should be capable of being generated automatically, or from the conventional document-description details available in word-processing packages, or through completion of a simple submission form by the originator. A more comprehensive introduction is provided by Miller (1996).

The Core contains only 15 data-elements, which are defined in the the Dublin Core Reference Description. They are:

document title;
author or creator;
subject and keywords;
description;
publisher;
other contributers;
date;
resource type;
format;
resource identifier;
source;
language;
relation;
coverage;
rights management.

Each element can be used multiple times for each document, to enable various pieces of information to be expressed. This is achieved through the use of qualifiers within the 15 defined data-elements. The key (only?) qualifers are:

the Scheme qualifier. This allows items to be stated to be based on a specific externally-defined domain (such as a United Nations coding scheme for language, or MIME-types for formats); and
the Type qualifier. This allows the meaning of the particular item to be more closely described, e.g. the Element called Publisher could be used once to contain 'name' and then additional times to contain 'email-address', 'street-address', etc.

Combining the Scheme and Type qualifiers, the element Language could occur multiple times in the meta-data for a document, e.g.:

Type=Main-Language, Schema= ISO 639, Code=en;
Type=Main-Language, Schema= ISO 639-2, Code=eng;
Type=Main-Language, Schema= Z39.53, Code=ENG;
Type=Other-Language, Schema= ISO 639, Code=sw;
Type=Other-Language, Schema= ISO 639-2, Code=swa;
Type=Other-Language, Schema= Z39.53, Code=SWA;
Type=Main-Language, Schema=Free Text, Code=Mostly English, with some quotations in Swahili.

The storage of meta-data is not directly addressed by the Dublin Core proposal, but it could be approached in a number of ways. In particular:

as part of the publication itself;
somewhere else, but associated in some manner with the publication.

A subsequent, related proposal as to how this could be done is referred to as the Warwick Framework. Its authors describe this as "a container architecture for aggregating logically, and perhaps physically, distinct packages of metadata".

The primary specific proposal for implementation of the scheme is by way of HTML meta-tags, within the header of a web-page. The Warwick Framework paper also considers implementation:

in MIME;
in DTDs of SGML other than HTML (Standard Generalised Markup Language - SGML - is a meta-language for specifying . A particular specification written in SGML is called a Document Type Definition - DTD. A DTD exists for HTML. For the standard, see SGML, 1986; and for an introduction, see Marchal, 1995-); and
as objects using an infrastructure such as CORBA.

The development process for the Dublin Core has occurred within a collaborative environment, through a series of workshops during 1996-97, most recently the 4th workshop at the Australian National Library in Canberra. The meetings have not been directly under the auspices of any formal standards body, but the undertaking has been supported, and to a considerable extent driven, by the Online Computer Library Centre (OCLC) Inc., of Dublin, Ohio, which describes itself as "a nonprofit, membership, library computer service and research organization".

The proponents of the Dublin Core have focused very heavily on electronic documents, particularly those designed to be accessed using the Internet, and with particular reference to the HTTP (web), FTP and MIME protocols.

The proponents' priorities have been expressly oriented towards simplicity, and away from sophisticated structures. It is implicit in their approach that the two are incompatible. The following section sets out to demonstrate how the desire for simplicity has resulted in a mechanism that is incapable of representing the richness of the real-world challenges that present themselves. Subsequent sections argue that a richer, more sophisticated model need not be uncomfortable or inconvenient.

Serious Weaknesses in the Dublin Core
1. 'Simple to a Fault'

As the authors of the Warwick Framework expressed it, "The authors of the Dublin Core readily admit that the definition is extremely loose. With no definition of syntax, and the principles that 'everything is optional, everything is extensible, everything is modifiable' the Dublin Core definition does not even approach the requirements of a standard for interoperability. The specification provides no guidance for system designers and implementers of web crawlers and spiders that may use the Dublin Core as the source for resource discovery and indexing. Achieving this level of precision and concreteness was beyond the scope of the Dublin workshop but is essential for further progress".

2. Incomplete List of Data-Items

Simplicity has been sought and achieved at the expense of omitting quite basic data-items; or alternatively of incorporating quite basic data-items within one of the 15 core elements.

Examples include:

the combining of logical-identifier and physical-location into a single element called Resource Identifier;
the failure to distinguish the Originator from the Owner;
explicit recognition of only one Date (the date the resource was made available in its present form);
the existence of 'elements' that are actually large groups of data-items, such as Publisher and Rights Management; and
the failure to allow for successive versions of the meta-data, as a result of the omission of Date-Created and Date-Last-Amended elements.

The specification is incomplete and preliminary, in that, even for data-items that clearly need to be tightly defined on a particular domain, little guidance is provided; in particular, the Scheme qualifier enables a domain-definition to be nominated, but the values that the qualifier can take appear to be as yet undefined.

3. Lack of Structure

The model fails to capture even the most basic structural information. It does not reflect the relationships among the data-elements. The only apparent means of expressing relationships among different objects is the Relation element, which suggests that the proponents of the scheme believe that relationships within and among meta-data can be expressed as a list of (as yet unspecified) data-items.

One of the most serious concerns that arises in this regard is the failure to reflect the existence of multiple versions of objects (e.g. in different languages, and in different formats), successive versions of objects, and multiple instances of objects (commonly referred to as replication or mirroring).

4. Unclear Scope of Applicability to Data Formats

Although the proposal refers to 'resources', its origins are in text-documents, or perhaps text-plus-raster-image-(bit-map)-documents; for example, the element Author or Creator refers to "authors in the case of written documents; artists, photographers, or illustrators in the case of visual resources".

It is vital that a meta-data standard encompass all foreseeable forms that objects may take, including vector-graphics, sound, video and multi-media. It is not clear that it does so.

5. Failure to Analyse Rights Management Issues

The proposal includes a single, essentially undefined data-item for rights management.

There appears to be an implicit presumption that objects will be generally accessible gratis. Free-to-air and sponsored access have been the norm during the first few years of Internet explosion; but commercialisation is inevitable, and is arriving already. It is essential that a meta-data standard encompass a sufficiently rich set of alternative charging models, including pay-per-view and subscription / membership-fee approaches.

Some of the complexities that need to be confronted, and for which data structures need to be provided, include:

'public domain' versus 'gratis-licence' versus 'charged-licence' items;
embedded rights (or, more correctly, cascades of rights); and
reference to tariffs and remittance information.

6. Failure to Address Object-Identity

At some time in the distant future, it will be unnecessary to use explicit identifiers, because every object will be satisfactorily discoverable, and distinguishable from other objects, on the basis of content and context. Until that stage is reached, however, identifiers are highly valuable means of both finding and referring to documents and other objects.

The core elements do not provide clear guidance regarding:

how to express versions of an object;
how to distinguish between logical and physical document identifiers;
how to map from logical to physical identifiers;
how to map from physical to logical identifiers;
how to map from one physical identifier to other instances of the same logical object;
how to go about computing the net-nearest instance of a particular object, in order to achieve quick service for the user, and minimise unnecessary use of bandwidth.

7. Failure to Allow for Multiple Instances of Meta-Data

The proposal omits what might be referred to as 'meta-(meta-data)'. By this I mean data about the origination of the meta-data, such as the identity and affiliation of the author of the meta-data (as distinct from the originator of the object itself), its location, and its dates of creation and last amendment.

Without such information:

the end-user is left uninformed about the source of the meta-data, and hence cannot make a judgement about its reliability;
there is no ability to distinguish between multiple instances of meta-data about the same object; and
there is no ability to choose among alternative instances of meta-data about the same object.

Note that the World-Wide Web Consortium's PICS specification already addresses this matter fairly comprehensively.

8. Failure to Address Ephemeral Objects

The proposal does not seem to contemplate the generation of documents 'on the fly', in response to user requests. In some contexts, such objects will have impacts far longer than their short existence, and will have evidentiary importance.

It may be that the generator and the recipient will have to bear the responsibility to maintain audit trails of such objects; but the proposal should at least discuss the matter, and make clear what approach is being adopted.

9. Failure to Address Instrumental Uses of Meta-Data

Once meta-data standards are established, they can be used as a means of causing desired objects to be produced. For example, a broadcast along the lines of 'I'd be pleased to pay money for a document with the following characteristics ...' could stimulate negotiations between an information-seeker and appropriate researchers. If it was provided in structured form, using an appropriate meta-data specification, it could be processed by a script to generate an object from a database.

This may not have been a foreground concern in 1995-96; but the proposal should not overlook what seems certain to be an early and important usage of a meta-data standard.

Interim Conclusions

It is only natural to focus on a constrained problem, that appears to be amenable to analysis and solution. Unfortunately, 'the devil is in the detail', and the apparent usefulness of the emergent standard will be seriously limited by the failure to address these issues at the outset.

Back to Theory

The people who have worked on the Dublin Core and related initiatives have sought simplicity as an antidote to complexity, on the eminently reasonable grounds that semi-automated self-cataloguing of net-objects will not happen if existing, complex schemes are applied. In order to achieve the desired simplicity-of-use, the proponents implicitly assume that simplicity-of-structure is an essential requirement.

A central contention of this paper is, on the other hand, that a sophisticated model does not have to be difficult to use, i.e. that complexity of the underlying model does not necessarily prevent simplicity of use. This section expands on that argument.

During the 1960s, the modelling of data was undertaken in an ad hoc manner. During the following decade, a succession of more disciplined approaches was trialled. The lessons learnt culminated in a number of important insights.

Critical among these is the use of three levels of abstraction in data models:

at the first (conventionally, the bottom-most) level, is a 'physical data model'. This is structured in order to reflect the characteristics of the recording medium being used;
at the second level is a 'logical data model'. This reflects the perspective of the systems analyst and designer. It expresses how the data and their inter-relationships are to be understood. It is a comprehensive and authoritative model, covering all aspects of the data. For this reason, it is also sometimes referred to as the 'canonical' data schema;
at the highest level are 'user views'. These are multiple perspectives on the logical data model, that suit the needs of particular users, in particular circumstances. Each is a sub-set of the full model, omitting logical complexities that, in the particular circumstances, the particular user has no need to deal with.

A second important body of expertise is relational data modelling. There are many ways in which a data schema can be expressed; for example, between the 1960s and the 1980s, the computer industry used hierarchical and then network models. Relational data modelling is both theoretically superior to them, and eminently teachable and usable. All mainstream database software now supports it, from the level of standalone PCs (e.g. Foxpro, MS Access) to mainframes (e.g. Oracle, IBM DB2).

Associated with the relational model is a set of techniques for establishing reliable models at the logical level. A series of rules express a 'normalisation' process, whereby the relationships among data elements can be identified. Given this information, the elements can be grouped into data structures that are 'stable', in the sense of being reliable and robust, and resistant to anomalies that could otherwise arise during updates to the data.

The Way Ahead

By applying the three-level abstraction notion, the relational data model, and normalisation, a model of meta-data can be derived that is rich enough to represent a wide variety of publication-types, without over-loading users.

To satisfy the desire for simplicity of use, the 'user views' notion could be applied to produce a tiered set of cataloguing mechanisms, along the following lines:

establish a very simple form of meta-data generator based on the existing windows that word processors provide for capturing author information. This could be supplemented by the generation of default keywords from titles, headings, and the document summary or abstract. The user interface would therefore be a modified version of windows already familiar to document authors;
establish similar tools for describing objects other than textual documents, such as images and interviews;
provide a utility that gathers information from an object-originator, and generates a set of meta-data from the data provided. This may involve:
- a fixed form;
- a conversation or interaction, with a variable sequence of questions depending on the data provided in response to the early questions; or
- a mix of prompted and inferred processing; and
provide a set of complex forms and interactions whereby a cataloguer has access to the full sophistication of the meta-data data structures (together with, of course, an appropriate help-mechanism).

The benfits of such a rich palette of alternatives are that:

content-originators who are untrained in cataloguing can be presented with convenient interfaces that hide the (to them) irrelevant complexities;
cataloguing programs can be designed to extract meta-data from document content;
search engines can be designed to use defaults when meta-data items are missing, but to use them when they are present; and
professional cataloguers can have access to the full power of a sophisticated data structure; but only need to do so on those occasions when the situation demands it.

If it is appreciated that simple user interfaces can be produced, irrespective of the complexity of the underlying data structures, then the focus of effort can be changed from simplification towards modelling of the kinds of content-providing objects that net-users are interested in.

In order to produce a comprehensive, canonical meta-dat schema, serious effort is required to:

develop a sufficiently rich set of instances or scenarios on which the analysis can be based (for some initial thoughts, see Appendix 1);
apply relational data modelling theory and normalisation to the information. Appendix 2 offers an initial, intuitively-derived model. This is intended merely to convey the kinds of complexities that are needed in the model;
prototype user interfaces that can hide the complexity from various kinds of users in various circumstances of use;
test the resulting models and prototypes; and
make the information available to commercial I.T. providers, in the expectation that they will incorporate the insights gained from the exercise into new and existing products.

Conclusions

Meta-data is being earnestly discussed by librarians during the mid-1990s. Meanwhile, that term, and a body of knowledge surrounding it, has been mainstream in the computer science and information systems (CS/IS) disciplines for a couple of decades.

This document has identified a large number of inadequacies in the Dublin Core proposal. These weaknesses can be addressed by coalescing relevant aspects of the disciplines of librarianship and CS/IS. It is entirely feasible to achieve the goal of simplicity in use, without resorting to an underlying set of data structures that are insufficiently rich to represent the important real-world complexities.

References

MARC (MAchine Readable Catalogue) (19??-) http://lcweb.loc.gov/marc/marc.html, viewed on 29 June 1997

SGML (1986) 'Information processing -- Text and office systems -- Standard Generalized Markup Language (SGML)', ISO 8879:1986, at http://www.iso.ch/cate/d16387.html, viewed on 29 June 1997

Marchal B. (1995-) 'An Introduction to SGML', at http://www.brainlink.com/~ben/sgml/, viewed on 29 June 1997

Dublin Core Home-Page (1996-), at http://purl.org/metadata/dublin_core, viewed on 29 June 1997

Miller P. (1996) 'Metadata for the masses', at http://www.ariadne.ac.uk/issue5/metadata-masses/, viewed on 29 June 1997

Seminar on International Metadata Developments (1997), Canberra, March 1997, http://www.nla.gov.au/niac/metadata.html, viewed on 29 June 1997

Dublin Core Reference Description (1996-), at http://purl.org/metadata/dublin_core_elements, viewed on 29 June 1997

Dublin Core Qualifiers (1997), at http://www.roads.lut.ac.uk/Metadata/DC-SubElements.html, viewed on 29 June 1997

Proposed Convention for Embedding Metadata in HTML (1996-) http://www.oclc.org:5046/~weibel/html-meta.html, viewed on 29 June 1997

The Warwick Framework (1996-) http://cs-tr.cs.cornell.edu:80/Dienst/UI/2.0/Describe/ncstrl.cornell/TR96-1593, viewed on 29 June 1997

Appendix 1: Some Test-Cases for Meta-Data

1. A Book

a book (without an edition number) is written by three authors, and published simultaneously on both sides of the Atlantic;
it is translated into three European languages, all of which are published by the British publisher, and into two Asian languages, which are published by the American publisher;
it is translated into three non-European languages by three other publishers, in one case with the translator's name appended to the list of authors, and in another case in breach of copyright norms;
bootleg copies are printed of both the American english-language edition and the legitimate Japanese translation;
a 2nd edition, identified as such, without the second author, but with an additional one, is published simultaneously on both sides of the Atlantic, by the same American, but a different British publisher;
the 2nd edition is made available on the web, by the American publisher, with a separate URL for each chapter and appendix;
multiple book reviews are published, some in hard-copy only, some on the web only, and some in hard-copy initially, but later made available on the web;
a dramatised version of part of the book is produced in San Francisco, filmed and made available in VHS format, and subsequently converted into MPEG, and made available for download over the web.

2. Edited Conference Proceedings

a pre-publication set of proceedings is prepared, with limited editing, by two harried co-chairs of the programme committee, with an inappropriate ISSN, and with 37 papers, some abstract-only. The hard-copy is in two volumes, and most papers are available on the web, some at a central site, and others on sites controlled by the authors;
a post-publication version is published, with an additional editor, named first (in return for all the quality assurance work she had to do), with 28 papers, 2 of which weren't in the pre-publication version, 15 of which were revised versions, and 25 of which are on the web, in various locations;
during the following 6 months, 5 authors modify the web-versions, one of them 5 times.

3. A Living Document

Marjorie Kalashnikov writes a definitive political history of the Dublin Core, and makes it available on her (spasmodically available) home computer, via her personal web-server in HTML, and via her personal FTP-server in Word and Postscript;
this is a continually changing document, with some changes identified by a changed version number, some by a changed Date of Last Amendment. Some new versions are not identified as such;
various versions are mirrored in multiple locations around the world.

4. A Journal

a well-established learned journal maintains its existing hard-copy version, but stores all of its new materials on dispersed Lotus Domino sites, and makes them available via the web;
some of the Associate Editors change, and the Lotus servers on which various papers are stored change to reflect those developments;
during the review process, papers are stored within the same environment as already-published papers, but subject to access controls;
published papers are replicated within the Lotus Domino environment;
selected papers that have been previously published in the journal are also made available in the same manner;
a project is launched to convert all prior issues into the new format, working chronologically backwards, with some papers revised to reflect subsequent developments in the discipline;
unauthorised versions of several of the papers appear on the web, with annotations by various commentators;
several papers are re-published in collections, some of them in hard-copy only, some of them in both hard-copy and electronic form;
some of the papers are referred to in many documents. Some are conventional citations, but others are hot-links. Some of these hot-links are to the 'original' location (which is actually a virtual document, since the 'original' is on multiple Lotus Domino servers), and other hot-links are to unauthorised copies.

5. An Audio-Visual Collection

the late, great art critic, Winstanley Walpole, walks and talks you around the world's great art-collections. The materials include:
- video with audio, in slightly differing versions, in MPEG, MPEG-2 and VRML;
- TIFFs, JPEGs and GIFs;
- animated GIFs for mobiles;
- VRML for sculptures;
- an accompanying written and illustrated guide, available in slightly differing versions, in HTML, Word and PDF;
some of these materials are subject to no copyright, some are subject to a single copyright, and some are subject to cascades of copyrights (e.g. relating to the original work, an adaptation, and a representation in digital form).

Appendix 2: An Intuitive, Partial Data Structure

Object-Details:

{*Object-ID, *Object-Version-ID, *Object-Format, Originator-ID#, Owner-ID#, Publisher-ID#, Other-Credits-IDs, Title, Date of Publication, Object-Type#, Language#, Subject#, Comments, Meta-Data-Originator-ID, Date-of-Meta-Data}

Object-Keywords:

{*Object-ID, *Object-Version-ID, Keyword}

Object-Dates-of-Applicability:

{*Object-ID, *Object-Version-ID, *Object-Format, *Storage-Location, Start-Date, End-Date}

Collection-Details:

{*Object-ID, *Object-Version-ID, *Object-Format, *Constituent-Object-ID}

Object-Relationships:

{*Object-ID, *Object-Version-ID, *Related-Object-ID, Nature-of-Relationship}

Note: An asterisk denotes a primary key within that relation; and # denotes that the item is a foreign key, i.e. it is the primary key in another relation.

Personalia Photographs
Presentations
Videos Access
Statistics

The content and infrastructure for these community service pages are provided by Roger Clarke through his consultancy company, Xamax.

From the site's beginnings in August 1994 until February 2009, the infrastructure was provided by the Australian National University. During that time, the site accumulated close to 30 million hits. It passed 65 million in early 2021.

Sponsored by the Gallery, Bunhybee Grasslands, the extended Clarke Family, Knights of the Spatchcock and their drummer

Xamax Consultancy Pty Ltd
ACN: 002 360 456
78 Sidaway St, Chapman ACT 2611 AUSTRALIA
Tel: +61 2 6288 6916

Created: 4 June 1997 - Last Amended: 26 October 1997 by Roger Clarke - Site Last Verified: 15 February 2009
This document is at www.rogerclarke.com/II/DublinCore.html
Mail to Webmaster - © Xamax Consultancy Pty Ltd, 1995-2022 - Privacy Policy

Roger Clarke's Web-Site

© Xamax Consultancy Pty Ltd, 1995-2024

Introduction

The Need

The Dublin Core

Serious Weaknesses in the Dublin Core 1. 'Simple to a Fault'

Back to Theory

The Way Ahead

Conclusions

References

Appendix 1: Some Test-Cases for Meta-Data

Appendix 2: An Intuitive, Partial Data Structure

Serious Weaknesses in the Dublin Core
1. 'Simple to a Fault'