Archaeology Data Service

Resource Discovery Workshops:

Final report from the
Archaeology Data Service

prepared in accordance with guidelines from the Arts & Humanities Data Service (AHDS) and United Kingdom Office for Library & Information Networking (UKOLN) Resource Discovery Workshop series by
Paul Miller & Alicia Wise

This document is http://ads.ahds.ac.uk/project/metadata/workshop1_final_report.html
Last modified: 4 August 1997

Executive Summary

This report summarises the findings of a workshop organised by the Archaeology Data Service, and held in York in March of 1997. The workshop formed part of a series organised under the auspices of the Humanities Data Service and the UK Office for Library & Information Networking, and details [1] — including links to the other workshop reports — are available on this series for those who are interested.

The workshop gathered representatives from various sub–fields of archaeology together in order to explore issues relating to the description and discovery of electronic archaeological resources, both in general terms and within the context of an Archaeology Data Service integrating with the broader holdings of the AHDS. The Dublin Core [2] initiative was explored as a possible means by which disparate archaeological data types might be described for the purpose of initial resource discovery and — with some provisos — this solution was felt to be satisfactory.

The Dublin Core elements CREATOR, SUBJECT, DESCRIPTION, PUBLISHER, CONTRIBUTORS, DATE, TYPE and COVERAGE were identified as particularly contentious or ill–defined and were explored in detail, with some of the recommended solutions outlined below.

Major issues addressed were those related to confusion over the use and storage of Personal and Place names within the Dublin Core structure, as well as an almost inevitable blurring of the distinction between describing archaeology and describing data which just happen to be archaeological in nature. The importance of dealing adequately with spatial and temporal information was stressed repeatedly.

Consultation Process

This document represents the final report on the deliberations of the Archaeology Data Service's Resource Discovery Workshop.

It is based upon the workshop itself, and comments received during June and July of 1997 on a widely circulated draft report. Those organisations and individuals who commented on the report are listed in Annex 2, and many thanks are due both to them and to the workshop participants — listed in Annex 1 — for making this work possible.

The guidance laid down in this report is itself part of a wider process being undertaken within the Arts & Humanities Data Service, which is due to conclude in the release of an integrated report in October 1997 that will outline integrated AHDS policy. As such, minor alterations to the ADS proposals contained herein may be required, and readers should refer to the AHDS–wide document for definitive advice. Details on this publication will be available from the Arts & Humanities Data Service web site [4] by the beginning of October 1997.

Feedback on this report, its implications, and the work of the Archaeology Data Service in general should be directed to the Archaeology Data Service.

Comments should be submitted by e–mail to email or in writing to:

Resource Discovery Workshop Report
Archaeology Data Service
The King's Manor
YORK
YO1 2EP

Issues arising from this report — and other aspects of the Archaeology Data Service's work — may also be raised on the public electronic discussion forum, ads-all. To join this list, send an e–mail message to mailbase@mailbase.ac.uk with contents

join ads–all your name
stop
e.g.
join ads–all Mortimer Wheeler
stop

Table of Contents

Introduction

The processes employed in undertaking archaeological research have, by their very nature, a tendency to generate vast quantities of data, whether physical objects, paper project records, or results stored on computer. In many cases — excavation or intrusive building recording, for example — the very act of gathering these data is in itself destructive, making the information collected during this process of destruction especially important.

Traditionally, these data have been either deposited in regional or national archives, or simply stored locally. Whilst much of this material is available for scrutiny and reuse by other members of the wider archaeological community, it can be difficult for researchers to find out what is available in a given archive prior to either visiting it in person or requesting access to particular data. This has the unfortunate result that potentially useful data are effectively inaccessible to the archaeological community, often despite the helpfulness and approachability of archive staff on site. As no one is aware that potentially useful data are available, no one makes the effort to contact the archives for further details.

Digital data stored on computer are especially suited to wider reuse, both because of their portability and as a result of the great flexibility offered by many modern computer programs. Digital data, however, face some of the greatest threats from prolonged storage in a moribund state as a consequence both of the rapid development of new computer software and data formats which potentially render existing data files unreadable and with respect to the volatile nature of the magnetic disks upon which much of this information is stored.

The Archaeology Data Service

The Archaeology Data Service (ADS) [3] was established in October 1996 as a Service of the United Kingdom's Arts & Humanities Data Service (AHDS) [4], joining similar services covering the performing arts, visual arts, electronic text and historical data.

The role of the ADS is to collect, describe, catalogue, preserve, and provide user support for digital resources that are created as a product of archaeological research. The ADS also has a responsibility for promoting standards and guidelines for best practice in the creation, description, preservation and use of spatial information across the AHDS as a whole. For those classes of archaeological data where there are existing archival bodies the role of the ADS is to collaborate with the appropriate national and local agencies to promote greater use of existing services. In cases where no existing agency has an obvious responsibility, the ADS will act as an archive of last resort, and accession the data directly.

In effect, the ADS is creating an archive. This archive, however, is one for the twenty–first rather than the twentieth century and differs from existing archives in several important respects;

AHDS/ UKOLN Resource Discovery Workshops

If the ADS' vision of a distributed digital archive is to become reality, it is important that a means is found by which researchers can gain access to information currently held in very different databases all around the world. This problem often appears insurmountable, given the difficulties inherent in tackling different computer systems, software packages, coding schema, reasons for initial data collection, etc. ADS, however, believes that the solution lies in reducing each of the many extremely complex data holdings that are available to a 'core' description of their most important details. It is felt that if this core description is expressed in a standardised manner across all potential data sets, then the process of discovering resources and deciding whether or not they are of value will become significantly more straightforward. In all cases, the original data set itself remains unaltered, although information will necessarily be made available along with the data set in order that it may be effectively reused by people not conversant with the coding schemes etc employed in its creation.

This issue is, of course, relevant to a wider community than just archaeology. Within the Arts & Humanities Data Service, there is a requirement to create a single catalogue providing access to the holdings of all five Service Providers. Rather than merely requiring a degree of interoperability between different archaeological databases, this initiative requires a similar degree of interoperability to be created between the holdings, say, of the Archaeology Data Service and the Performing Arts Data Service.

In an effort to explore the issues behind such interoperability, the AHDS and the UK Office of Library & Information Networking (UKOLN) located funding to pay for a series of domain–specific workshops to address resource discovery needs in each of the AHDS' constituent domains [1]. A synthetic report to be released in October 1997 will build upon the conclusions of each workshop and provide a model for the AHDS' integrated catalogue.

This document reports on the outcomes of the ADS' workshop, held within this series.

Resource Discovery for Archaeologists

Archaeologists already undertake many of the processes involved in resource discovery and, indeed, often do so almost unconsciously as part of the larger process of archaeological research. In considering the needs of an Arts & Humanities–spanning resource, however, it is necessary to identify the important processes undertaken by archaeologists, and to discover the types of information considered important in both locating resources of potential value and in describing existing resources.

Requirements of Resource Discovery

In discovering archaeological information of value, there is an important distinction to be made between locating collections of data (the context records for the excavation of Maiden Castle, perhaps) — or even collections of collections such as a Sites and Monuments Record (SMR) or National Monuments Record (NMR) — and locating individual records (information on artefact F1862 from the Coppergate excavation in York). Archaeologists have a need to find information at each of these — and other — levels, but from a practical standpoint it is easier for information to be provided initially for the less detailed resource levels (by submission of just one metadata catalogue entry to ADS), such that a first attempt at creating a catalogue may consist of no more than information on the NMRs, SMRs and similar repositories within the UK. Greater detail may then be added to describe the collections held in these repositories in a fashion suitable for enabling decisions to be made as to their potential value Figure 1.

In most cases, information need not necessarily be held in this resource–locating catalogue on individual records from a database or individual images in a photographic collection. Rather, it is envisaged that at this level users would be interacting directly with the resource itself, rather than with some simplified abstraction thereof. There is, of course, no reason why the model could not encompass individual items in future, should this prove desirable or necessary.

The information utilised in enabling this process of resource discovery is labelled metadata, a term from the world of computing used to describe the elements of information that are required to describe data or objects. Metadata means many things to many people [5], although it may be as simple as a record of the name of an excavation director (a piece of metadata about the excavation and its archive) or as complex as a detailed description of the equipment, software and mathematical algorithms used in processing a satellite image of the Earth. Metadata is seen as key to the effective functioning of the ADS catalogue, and the specific methods of implementing this will be discussed further.

Current Approaches to Resource Description

The UK archaeological community has not adopted a single set of standards for the description of resources. No single documentation standard has proved flexible enough for all applications. Instead each has been designed for a specific purpose, for example the detailed cataloguing of specialised museum collections, and requires a significant investment of time to learn. These standards are very good for their specific purposes, but their number and variety do not facilitate quick and easy resource discovery by non–specialist users nor do they facilitate generic resource discovery across disciplines.

The Dublin Core, a general metadata structure discussed in detail below, is useful for these resource discovery tasks. Specialist documentation standards continue to be important, in conjunction with the Dublin Core, in systematising the way metadata records are created and recorded.

Very few formal standards have been widely adopted by archaeologists for a variety of deep–set cultural reasons. There are a large number of informal standards, guidelines and practices within and outside the archaeological community. These need to be considered by the ADS in approaching a discipline–wide solution to the problem of locating extant resources. In the last 5 years a widespread reassessment and renewed appreciation for standardised approaches to documentation has been growing, largely due to the efforts of CIDOC, the Data Standards Unit at the Royal Commission on the Historical Monuments of England, and the Museums Documentation Association. Formal standards are being created by these and other bodies, disseminated, and adopted by archaeological organisations.

Sincere thanks to Edmund Lee (RCHME), Gillian Quine (RCHME), and Louise Smith (MDA) for bringing many of the standards reviewed here to our attention.

Several good introductions to standards relevant to archaeologists are available over the World Wide Web. The following examples act as good starting places:

Bower and Roberts' Developments in museum and cultural heritage information standards [6]

The Museum Documentation Association's HOARD [7] is a goldmine of information including a fine bibliography and short descriptions of many standards. This is also a good site for information about constructing your own thesaurus or controlled vocabulary list.

Visual Arts, Museums and Cultural Heritage Information Standards: A domain–specific review of relevant standards for networked information discovery [8] by Tony Gill, Catherine Grout and Louise Smith was commissioned especially for the Visual Arts and Cultural Heritage Resource Discovery workshop, and contains much of relevance to archaeologists.

The National Geospatial Data Framework's map of related initiatives [9] includes a discussion of the main spatially relevant standards, and serves to illustrate how the NGDF might fit into the broader picture of standards and application development.

Also extremely informative is the MDA's 1996 Survey of Terminology Used in UK Museums [10].

Geospatial Data Standards

Standards geared specifically towards the handling of map–like information are as numerous and diverse as those for other areas and, given the ADS responsibility for geospatial data standards across the whole Arts & Humanities Data Service, they are addressed seperately here.

Most of the standards discussed below are recent, although each has a basis in earlier work. As a rule geospatial standards have not been adopted by archaeologists, with most developing their own procedures for handling these data.

National Geospatial Data Framework (NGDF) — This important co–operative initiative is aiming to provide effective means of access to geospatial data collected and held by government and the public and private sectors following a model potentially similar to that of the AHDS. NGDF is addressing issues such as metadata standardisation and is looking to greatly increase the market for existing and new data. Figure 2(from the NGDF web site) illustrates the NGDF view of the relationship between the major relevant standards and initiatives, including those covered below. [28]

BS 7666 — British Standard 7666 specifies the manner in which address information should be specified, and is likely to prove extremely important within Local Government and the Utilities. Archaeologically, it may prove most useful in the consistent provision of address information for Listed Buildings, etc.

CEN prEN 287009 — This draft standard from the European Standards Organisation (Comité Européen de Normalisation) Technical Committee TC/287 addresses standards related to geospatial data including the definition of a reference model, geometry guidelines, data description structures and data transfer issues. It is due to be published in 1998.

FGDC — the United States' Federal Geographic Data Committee's Content Standard for Digital Geospatial Metadata is, perhaps, the best known and established of geospatial data standards, the current version having been released in 1994. This standard underpins much of the US Federal Government's work with geospatial data, and is also used by other collectors of spatial data, although there do not appear to be examples of its use within the UK archaeological community. The standard was recently enhanced with the release of a draft revision in April 1997. [33]

GIS Guide to Good Practice — The Archaeology Data Service is scheduled to produce this guide in January 1998. Written by a working party of GIS practitioners, and widely peer reviewed, this guide deals with all aspects of creating, documenting and archiving archaeological Geographic Information Systems. The creation of Dublin Core–style metadata records for these data is also described, and examples are provided.

ISO 15046 — This draft standard from the International Standards Organisation Technical Committee TC/211 addresses geographic information and geomatics. The draft standard appears modelled upon current FGDC practice, and offers powerful options for extensibility and modification within the wider standards framework. It is due to be published from 1998.

OGIS — The Open Geodata Interoperability Specification (OGIS) is an initiative of the vendor–led Open GIS Consortium (OGC). OGC is looking to increase the ease with which geospatial information may be passed between products, and OGIS is one important aspect of this work. [45]

SABE — The Seamless Administrative Boundaries of Europe (SABE) project is an initiative of the MEGRIN Project Team, looking to establish a single uniform set of administrative boundaries for the European Union. If successful, this could form an important underpinning to any AHDS spatially driven search interface. [46]

UK Standard Geographic Base — The UK Standard Geographic Base is a proposal from the Office for National Statistics to develop a single framework by which spatial units within the UK may be uniformly described. This proposal is currently at the stage of having a sound business case developed before work proceeds.

TGN — The Thesaurus of Geographic Names is a project of the Getty Information Institute, aiming to create a powerful resource holding information on names of inhabited places, regions and geographic features both now and in the past. Importantly, TGN is holding these names within a hierarchy, such that it may be determined that a town lies within a country, that country within a continent, etc. TGN is due for release late in 1997. [38]

Data Content Standards

Formal Standards
Art and Architecture Thesaurus — The Getty Information Institute produced this useful thesaurus in 1990 and has recently made it searchable over the World Wide Web. It's an invaluable tool for standardised description of material culture, architecture, and art in the Western World from prehistory to the present. Vocabulary is controlled through a hierarchical structure of broader/narrower terms, synonym control, and other helpful tools. [11]

British Archaeological Thesaurus — Written by Cherry Lavell and published by the Council for British Archaeology in 1989, this was one of the earliest thesauri for British archaeology. It remains a useful companion to back issues of the British and Irish Archaeological Bibliography (and its predecessors, British Archaeological Bibliography and British Archaeological Abstracts), but is now out–of–print. [12]

International Guidelines for Museum Object Information: CIDOC Information Categories — CIDOC, the International Documentation Committee of the International Council of Museums has developed these guidelines about what information should be recorded for museum objects, how it should be recorded, and the terminology with which this information should be recorded. This standard is particularly useful for archaeologists working in a museums setting. [13]

Management of Archaeological Projects (MAP2) — English Heritage's guide to the management of all phases of archaeological projects. Includes guidelines for planning, fieldwork, assessment of potential, analysis, report preparation, and archiving. [14]

Multilingual Egyptological Thesaurus — The International Association of Egyptologists (IAE), Comité International pour l'Égyptologie (CIPEG) and the International Council of Museums (ICOM) joined forces to create this thesaurus useful for anyone working on or interested in Egyptology. This thesaurus covers a variety of topics including present location, provenance, dating, material, preservation, description, text, divine names, and royal names. Includes entries in English, French, and German. Arabic, Italian, and Spanish additions are planned. [15]

Recording England's Past: A Data Standard for the Extended National Archaeological Record — Produced by the Royal Commission on the Historical Monuments of England and the Association of County Archaeological Officers (ACAO, now the Association of Local Government Archaeological Officers, ALGAO) in 1993, this standard is a data dictionary specifically designed for recording information within England's Sites and Monuments Records. See also the Thesaurus of Monument Types and the draft SMR Standard. [16]

Rules for the Construction of Personal, Place and Corporate Names — The National Council on Archives' 1997 guide to the recording of name information in archives. These rules include guidance on the use of non–current place names, and other issues of relevance to the archaeological community. [47]

Social History and Industrial Classification, 2nd edition (SHIC2) — The MDA's standard for classifying the subject matter of museum collections. A simple sub–set of SHIC2 is provided by the less formal Simple Subject Headings system, although SHIC2 should be used where possible. [17]

SPECTRUM: The UK Documentation Standard — Created by the MDA in 1994 as a standard for documenting museum collections, its use is required for registration with the Museum and Galleries Commission. A condensed version called SPECTRUM Essentials is available. The MDA provides a team of subject specialists, including an archaeologist, who are available to advise about the use of SPECTRUM. [18]

Thesaurus of Archaeological Site Types — This 1992 thesaurus has been superceded by the RCHME Thesaurus of Monument Types.

Thesaurus of Architectural Terms — This 1989 thesaurus has been superceded by the RCHME Thesaurus of Monument Types.

Thesaurus of Building Materials: A Standard for Use in Architectural and Archaeological Records — An unpublished standard from the Royal Commission on the Historical Monuments of England, this thesaurus deals explicitly with the stuff of which buildings are composed: animal, vegetable, or mineral. Like the Thesaurus of Monument Types, terms are organised hierarchically and terminology control is provided. Users can nominate terms to be included in this thesaurus by returning a form within the thesaurus to the RCHME Data Standards Unit. [19]

Thesaurus of Monument Types: A Data Standard for Use in Archaeological and Architectural Records — Produced by the Royal Commission on the Historical Monuments of England (RCHME) in 1995, this is a standard for use with both archaeological and architectural information. This thesaurus is actively updated by the Data Standards Unit at the RCHME. The purpose of this thesaurus is to standardise the terms used to describe archaeological sites or standing buildings by, for example, listing terms hierarchically and relating the levels of this hierarchy to one another or indicating preferred terms in the case of synonyms. For example, the hierarchical structure means that RELIGIOUS monuments include the subset of MONASTERYs and that there is a further sub–division into BENEDICTINE MONASTERY or CISTERCIAN MONASTERY depending on the particular monument being described. Synonyms are dealt with by pointing the user to a preferred term (e.g. for 'tribunal' use COURT HOUSE). This is one of the most widely used documentation standards in UK archaeology, and is a useful source of subject terms. [20]

Towards an Accessible Archaeological Archive. The Transfer of Archaeological Archives to Museums: Guidelines for Use in England, Northern Ireland, Scotland and Wales — The Society of Museum Archaeologists 1995 guide, edited by Janet Owen, provides detailed information about all aspects of preparing an archive for deposit in a museum. Does not cover digital archiving explicitly. [21]

Union List of Artist Names — Another useful standard from the Getty Information Institute available online, the ULAN offers a way to control the recoding of names for over 100,000 artists and architects. Although of limited use to archaeologists, some prehistoric and medieval artists are included. This standard is very helpful for those involved in the recording of standing buildings, helping to keep your 'Lloyd Wright's straight (whether it's Frank or Eric that you're interested in). [22]

Draft Standards
Aerial Photography and Remote Sensing Guide to Good Practice — The Archaeology Data Service is scheduled to produce this guide in January 1998. Written by a working party of A/P and remote sensing specialists, and widely peer reviewed, this guide deals with all aspects of creating, documenting, and archiving images and interpretations. The creation of Dublin Core–style metadata records for these data is also described, and examples are provided.

The Aquarelle project is in the process of developing several standards of relevance to archaeologists and museum specialists. This project is run by a consortium of technical partners and national heritage managers in England, France, Greece, and Italy. Of particular interest is their work with SGML and multilingual thesauri. [23]

Archaeological Object Name Thesaurus — The MDA is in the final review process for this new archaeological standard. The thesaurus has been developed to provide guidance and common principles for the recording of object names within the archaeological profession and related disciplines, and to provide an interface with other national and international standards. The goal of this thesaurus is to encourage the use of, and access to, collections, archives and record systems and facilitate co-operation and data exchange between all individuals and institutions involved in the retrieval, research and curation of archaeological objects. [24]

European Bronze Age Monuments: A Multi–lingual Glossary of Archaeological Terminology — Created in 1995 by a multinational working party for the Council of Europe, this multilingual thesaurus pilot project is designed to assist in the recording of Bronze Age archaeological sites and monuments in Danish, Dutch, English, and French. Though the terms within the glossary are listed in all four of these languages, the glossary itself is currently available only in English and French. When this glossary makes its public debut, it should be a very helpful resource for prehistorians throughout Europe.

Geophysics Guide to Good Practice — Another guide in a series by the Archaeology Data Service, this standard is scheduled for publication in January 1998. Written in close collaboration with the creators of the English Heritage AML Geophysics Database, this volume complements the existing English Heritage guide to geophysical surveying. Topics covered include georeferencing survey grids, data formats, data documentation, and the archiving of survey data.

International Core Data Standard for Archaeological Sites and Monuments (Draft) — Produced in 1995 by CIDOC, the International Documentation Committee of the International Council of Museums this document guides the user in documenting archaeological sites and monuments. The goal of this standard is to facilitate international exchange of information by encouraging standardised approaches to database structure. Useful information about naming, describing, cross–referencing, and spatially referencing sites and monuments is provided. Working examples from Denmark, England, France, and the Netherlands are provided. Contributors come from these countries and Albania, Canada, Poland, Romania, Russia, and the United States. [25]

SMR'97 (Draft) Currently being developed by the Association of Local Government Archaeological Officers (ALGAO), English Heritage, and the Royal Commission on the Historical Monuments of England this data standard is designed to unify the structure of Sites and Monuments Records databases throughout England.

Informal Standards
Geophysical Survey Database — This database, created by the Ancient Monument's Laboratory of English Heritage, is a well–crafted recording structure for geophysical survey data. Terminology is controlled in all fields describing the survey techniques or the archaeological site itself. The RCHME Thesaurus of Monument Types, in particular, is incorporated to control subject and period terms. [26]

IFA codes — The Institute of Field Archaeologists (IFA) provides a Code of Conduct with which members are meant to comply. This Code — and other IFA guidelines — lay down minimum standards for work in many areas of archaeological endeavour, including the deposition of archival material.

Simple Subject HeadingsDesigned by the MDA for use in small museums, this tool helps control terminology used to classify museum collections. Four broad categories are included: community life, domestic and family life, personal life, and working life. This is a simplified subset of the MDA's Social History and Industrial Classification. [27]

Recently the Archaeology Data Service conducted an informal survey of coding forms used by archaeologists in the UK. Results indicate that many archaeological contractors and units use modified versions of coding forms by the Central Archaeology Service and the Museum of London Archaeology Service (MOLAS).

Many organisations are also likely to have internal thesaurii and authority lists of potential use to the wider community. For example, the British Museum maintains thesauri for manufacture materials, manufacturing techniques, material culture/period, form and design. The Museum of London maintains authority lists for periods (e.g. prehistoric, Roman, medieval, post–medieval, and later) which are linked to the Art and Architecture Thesaurus where appropriate. RCHME's Data Standards Unit has a wide range of internal thesauri and wordlists, which the Unit reviews and develops, e.g. evidence and maritime thesauri; county, unitary authority, district and parish lists; condition schemes; associated roles (people and organisations) lists etc.

A range of resources exist for environmental archaeologists and others interested in the scientific names of animals, insects, and plants. Information about many of these is available through the MDA's wordHOARD website. This includes details for SPECIES 2000, the Smithsonian Institution's World List of Insect Families, and the Vascular Plant Familes and Genera databases from the Royal Botanic Gardens.

Other Relevant Standards
There are a number of specialised standards which are useful in archaeology, but which are too specialised to address here. These include standards for recording coastal and underwater archaeology sites (e.g. the National Register of Historic Vessels, the NMR/SMR Maritime Type Standards, the Shipwreck Identification Thesaurus by A. M. Elkerton, the Scottish Institute of Maritime Studies draft Thesaurus of Vessel Types, and the University of Wales Department of Maritime Studies and International Transport Archaic and Alternative Port and Place Names lists.) A number of standards have been developed for other archaeological specialties including industrial archaeology (the Association for Industrial Archaeology's Index Record for Industrial Sites), military archaeology (the National Army Museum's Thesaurus for Cataloguing Military Collections), and urban archaeology (the RCHME and English Heritage Data Standard for Urban Archaeological Databases). The Archaeology Data Service will rely on comments from specialists in these areas for guidance in adapting these standards for generic resource discovery purposes.

Architectural recording is an area closely related to archaeological recording which has developed its own standard practices. Examples of documentation standards include the Council of Europe's Core Data Index to Historic Buildings and Monuments of the Architectural Heritage and the Getty Information Institute's Guide to the Description of Architectural Drawings. While there is a great deal of overlap between these standards and those listed above, we suspect that a large number of standards specifically designed for architectural recording exist and that the Archaeology Data Service is not yet aware of the full range. We will be relying on comments from specialists in architectural/building surveys for assistance in identifying these standards.

Assessing the Dublin Core

Each of the initiatives discussed above is tailored — often in great detail — to a specific purpose other than resource discovery, and may well require significant investment of time in preparation of the appropriate metadata, as well as reference to weighty and expensive standards documents to aid in both the creation and interpretation of the data description.

Such standards have an undeniable role to play in facilitating the description and re–use of digital data, and the efforts of initiatives such as the UK's National Geospatial Data Framework (NGDF) [28] should be encouraged where possible in their efforts to introduce commonplace use of standards such as BS 7666, especially in local and national government. These standards are perhaps, though, overly complex — and too expensive in terms of time spent learning to understand them and money spent in purchasing their detailed descriptions — for either the casual/ occasional user or for generic resource discovery of disparate digital resources where any one standard would be insufficient.

The Arts & Humanities Data Service is proposing to adopt a multi–tiered model, where detailed standards such as those discussed above are retained for the benefits they bring in describing the specifics of individual data sets, but where a less focused approach is taken at the abstract level in order to provide descriptions of the data that are sufficiently detailed to allow a sensible decision to be made as to their potential value by the searcher whilst remaining sufficiently generic to allow a single form of description to be adopted for data of all forms.

It is proposed that the Dublin Core model [2, 29] is used as the basis for the most generic — or, in metadata parlance, high level — description across the AHDS, with the extensibility concepts enshrined in the Warwick Framework [30] utilised both to allow the addition of any extra high level information felt to be necessary but outwith the current Dublin Core model, and to enable the linking of this high level basic description to the greater detail of subject–specific standards–driven descriptions such as already held by the History Data Service [31] or Oxford Text Archive [32], or integral to initiatives such as the Federal Geographic Data Committee's Content Standards for Digital Geospatial Metadata [33].

In the ADS' Resource Discovery Workshop, Dublin Core was felt to be essentially fit for the purpose of discovering archaeological resources, although there were areas in which definitions of the elements could be clearer, and areas where archaeological needs may come into conflict with the different needs of other AHDS Service Providers. Annex 3 presents the current 'official' reference description of the 15 elements used in Dublin Core, as elucidated by Stu Weibel in December 1996. The paragraphs below represent an archaeological interpretation of the same elements, with potential confusions and conflicts flagged. ADS draft recommended usage for the element set is then laid out, derived from the workshop deliberations, earlier ADS work on a previous manifestation of the Dublin Core [34], and draft guidelines from part of the wider Dublin Core community [35], but will doubtless be modified in light of comments received. Annex 4 includes examples of this recommended usage, applied to a series of imaginary archaeological resources, and illustrates potential problems.

Throughout the simple examples presented in this section, text inside [ ] represents identification of a proposed Dublin Core SCHEME and text inside ( ) represents possible TYPEs. In both cases, the exact terms used have yet to be agreed, and the text displayed to the user will certainly be more intelligible than the internal codes actually stored in the database; [NMRE] translating into 'National Monuments Record for England', perhaps.

The element qualifiers SCHEME and TYPE are used in accordance with definitions laid out in [29]; namely that a SCHEME is a recognised controlled vocabulary, thesaurus or coding system and that a TYPE is a sub–qualification or sub–division of the Dublin Core element itself.

It should be stressed that the current collection of SCHEMEs and TYPEs is far from definitive, and merely illustrates the mode of implementation likely to be adopted by ADS. The final report will include information on an AHDS–wide registry of acceptable values, as well as the mechanisms for making local or service–wide additions.

DC.title

1  Title Label: TITLE

"The name given to the resource by the CREATOR or PUBLISHER."

Archaeologically, this element is uncontentious, simply referring to the given name of the resource, whether this be an excavation archive, a published excavation report, a fauna database, or whatever.

e.g.

Title 12 – 18 Swinegate
Title Excavations at Maiden Castle, Dorset
Title Northamptonshire Sites and Monuments Record
Title Geophysical Survey of Sutton Hoo Mound 5

As in the wider community of information science, there is an issue here in the use of prepositions — given an entry entitled 'The City of York', should the entry be coded thus, or as 'City of York, The'? A decision needs to be taken on this matter at the AHDS level, probably adopting an existing set of guidelines such as the Anglo–American Cataloguing Rules [36].

Proposed ADS definition for this element

"The name given to this resource by its CREATOR. This name need not necessarily be unique"

SCHEMEs

not applicable to this element

TYPEs

TYPEs useful to the ADS interpretation of this element might, provisionally, include;
mainThe title most commonly associated with the resource. Where no TYPE is specified, main is assumed. A main title is required for every resource.
subtitleAncillary title information for the resource. A main title is required before a subtitle may be used.
alternateWhere a resource is known by more than one name, or where it has a formal name and a name in common usage — 'Green back' is used as a common name for the statutory gazetteer of Listed Buildings, for example — the alternate or common usage name may be recorded here. The full and formal name must also be recorded as a main title.
seriesWhere the resource is part of an established series (CBA Research Reports, etc), the series name may be recorded here.

DC.creator

2  Author or Creator Label: CREATOR

"The person(s) or organisation(s) primarily responsible for the intellectual content of the resource. For example, authors in the case of written documents, artists, photographers, or illustrators in the case of visual resources."

Responsibility for the intellectual content of an archaeological resource is often unclear. Where the metadata record describes an entry in a Sites & Monuments Record, is the SMR Officer 'responsible'? Is the fieldworker who actually uncovered/ surveyed/ excavated/ photographed the site so that it became known to the SMR in the first place? Is the SMR itself — or its host local authority — the correct entry here? More confusingly, if an excavation director is assumed to ultimately be the 'creator' of the excavation archive, is he/she also then the creator logged against each individual element of that archive, including excavation plans etc that he/she had no direct involvement in drawing? If, long after the excavation, a paper plan is subsequently digitised onto a computer, does the name of the creator change to become the person responsible for digitisation?

Difficulty in accepting the notion of primary intellectual responsibility for the vast majority of archaeological resources emerged as a fundamental issue at the workshop. Our conclusion was that the contents of DC.creator and DC.contributors might usefully all be stored in DC.creator simply tagged with the role played by each name via the TYPE qualifier in Dublin Core.

e.g.

NamesWheeler, Mortimer (excavation director)
Sorrell, Alan (site recording)
Speed, John (cartography)

As in many other aspects of the drive towards inter–disciplinary interoperability, there is a conflict here between specifying roles in sufficient detail for them to make sense archaeologically ('excavation director') and using suitably generic terms for them to achieve widespread applicability ('project leader', perhaps?). The definition of these terms should be agreed at an AHDS level, in consultation with those outwith the AHDS who are also moving towards the use of Dublin Core.

Where more than one DC.creator is listed, it is suggested that the various attributes associated with each individual are grouped by means of a numeric identifier appended to the element name, thus;

NamesDC.creator.personalName.1  Wheeler, Mortimer
DC.creator.personalName.2  Speed, John
DC.creator.role.1  projectLeader.excavationDirector
DC.creator.role.2  otherContributor.cartography
etc.

Proposed ADS definition for this element

"The person(s) or organisation(s) responsible for creation of the original resource, its source, surrogates, or metadata pertaining to the above, whose involvement is considered as worthy of inclusion for the purposes of discovering said resource."

SCHEMEs

not applicable to this element

TYPEs

TYPEs useful to the ADS interpretation of this element might, provisionally, include;
personalNameThe name of an individual. Where no TYPE is specified, personalName is assumed. A personalName or corporateName is required for every resource.
corporateNameThe name of an organisation or corporation associated with creation of the resource. corporateName is useful in situations where no one individual or small group of individuals within an organisation is identified with the resource. RCHME, for example, might be cited as the creator of the National Monuments Record using this TYPE. A personalName or corporateName is required for every resource.
affiliationThe organisation with which an individual is associated for the purposes of dealing with this resource. A personalName is required before affiliation may be used, and use of affiliation (defining the affiliation of a named individual to an organisation) should not be confused with use of corporateName (assigning corporate authorship or responsibility to a resource).
roleThe role played by the individual or organisation with respect to this resource. Each individual's actual function may, optionally, be appended to the generic role label, thus; DC.creator.role = projectLeader.excavationDirector.

roles must be selected from this controlled list;

contactDetails for a contact within the depositing organisation capable of taking notional responsibility for the deposition of the resource. Where no ROLE is specified, contact is assumed. A contact name is required for every resource.
metadataThe individual(s) or organisation responsible for providing metadata on this resource to the ADS catalogue. A metadata name is required for every resource.
projectLeaderThe individual(s) or organisation primarily responsible for preparation of the resource, whether as excavation director, surveyor, report author or whatever.
majorContributorAny individual(s) or organisations considered to have made a major contribution to preparation of the resource.
otherContributorAny individual(s) or organisations which, while not responsible for the resource in a major fashion, is still considered worthy of inclusion in this list for the purpose of resource discovery.
emailThe electronic mail address for the individual or organisation being referred to.
postalA standard postal address for the individual or organisation being referred to. Where possible, this address should be BS 7666–compliant.
townThe postal town for the individual or organisation being referred to.
countryThe country in which the individual or organisation being referred to is located. For the purposes of this service, country should be coded as Scotland, England, Wales, etc, rather than United Kingdom.
postcodeThe postal code or Zip code for the individual or organisation being referred to.
phoneThe full international telephone number for the individual or organisation being referred to. This number should take the form +country–code local–area–code telephone–number; i.e. +44 1904 433954 rather than 01904 433954.
faxThe full international facsimile number for the individual or organisation being referred to. This number should take the form +country–code local–area–code facsimile–number; i.e. +44 1904 433939 rather than 01904 433939.
URLA World Wide Web URL (or equivalent) for the home page of the individual or organisation being referred to.

DC.subject

3  Subject and Keywords Label: SUBJECT

"The topic of the resource, or keywords or phrases that describe the subject or content of the resource. The intent of the specification of this element is to promote the use of controlled vocabularies and keywords. This element might well include scheme–qualified classification data (for example, Library of Congress Classification Numbers or Dewey Decimal numbers) or scheme–qualified controlled vocabularies (such as MEdical Subject Headings or Art and Architecture Thesaurus descriptors) as well."

The DC.subject element has the potential to be greatly overloaded in day–to–day usage of the Dublin Core, especially in provision of a service such as that envisaged by the AHDS where this element may be perceived as the only place likely to hold discipline–specific terminology in sufficient detail for the subject specialist.

Evident confusion between the usage of DC.subject and DC.coverage or DC.contributors — and even DC.format and DC.source — is likely to cause problems, and the usage of each of these therefore needs better definition both in ADS terminology and across the AHDS as a whole.

It is assumed that, even more so than the majority of other elements, SUBJECT entries will be qualified by the use of SCHEME tags, identifying the acceptable controlled word list from which terms have been drawn. Obvious thesauri to use initially include the Getty's Art & Architecture Thesaurus [11], RCHME/ EH Thesaurus of Monument Types [20] and the MDA's Archaeological Object Name Thesaurus [24]. Other thesauri will also be examined for their suitability on this list, and acceptable — unique across AHDS — abbreviations need to be defined for each in order that they may be easily identified within the metadata record.

e.g.

Subject[TMT] canal lock

Proposed ADS definition for this element

standard Dublin Core definition is fine.

SCHEMEs

SCHEMEs useful to the ADS interpretation of this element might, provisionally, include;
AACR2Anglo–American Cataloguing Rules [36].
AATArt & Architecture Thesaurus [11].
AONTMuseums Documentation Association Archaeological Object Name Thesaurus [24].
BATBritish Archaeological Thesaurus [12].
DDCDewey Decimal Classification.
EBAMEuropean Bronze Age Monuments Glossary.
LCSHLibrary of Congress Subject Headings [37].
SHIC2Social History & Industrial Classification [17].
SSHSimple Subject Headings [26].
TBMThesaurus of Building Materials [19].
TGNThesaurus of Geographic Names [38].
TMTThesaurus of Monument Types [20].
ULANUnion List of Artists' Names [22].

TYPEs

not applicable to this element, except where drawn from a SCHEME?

DC.description

4  Description Label: DESCRIPTION

"A textual description of the content of the resource, including abstracts in the case of document–like objects or content descriptions in the case of visual resources. Future metadata collections might well include computational content description (spectral analysis of a visual resource, for example) that may not be embeddable in current network systems. In such a case this field might contain a link to such a description rather than the description itself."

As defined more widely within the Dublin Core community, this element holds a free–text description of the resource in question.

The main issue related to this element is that of length; just how detailed should descriptions be before it is more logical to relegate the information to the next — more detailed — level of metadata?

Importantly, DC.description must hold sufficient information to enable the user to reach an informed decision as to whether or not to proceed further with the resource being described, whilst remaining concise enough for the user to read this and other descriptions in a reasonable period of time.

Proposed ADS definition for this element

standard Dublin Core definition is fine.

SCHEMEs

SCHEMEs useful to the ADS interpretation of this element might, provisionally, include;
URLWhere the description is stored elsewhere and referred to by means of a URL, the address should be included here.

TYPEs

not applicable to this element, except where drawn from a SCHEME?

DC.publisher

5  Publisher Label: PUBLISHER

"The entity responsible for making the resource available in its present form, such as a publisher, a university department, or a corporate entity. The intent of specifying this field is to identify the entity that provides access to the resource."

With archaeological datasets accessioned by the Archaeology Data Service, the ADS itself may be considered, in some fashion, to be the entity responsible for making the data available. However, rather than complicate the notion of publication, it is suggested that the ADS' role in this be handled through the DC.relation element, reserving DC.publisher for information on the entity(s) responsible for either mounting the data for distribution or for making the digital data available in the first place.

e.g.

DC.publisherCity of York Council

In order to allow sensible comparison and searching of records from the same place, the names used here should follow an agreed and definitive system like the Office of National Statistics' list of local authority names, such that the local authority for York is consistently referred to as City of York Council, rather than York or York City Council, for example.

Proposed ADS definition for this element

standard Dublin Core definition is fine.

SCHEMEs

not applicable to this element

TYPEs

TYPEs useful to the ADS interpretation of this element might, provisionally, include those discussed for CREATOR. The TYPE of role will require modification, perhaps to reflect different kinds of 'publication', from formal publication to the archive–as–publisher for making a resource available to users, etc. These TYPEs will follow AHDS–wide recommendations to be published in October 1997.

DC.contributors

6  Other Contributors Label: CONTRIBUTORS

"Person(s) or organisation(s) in addition to those specified in the CREATOR element who have made significant intellectual contributions to the resource but whose contribution is secondary to the individuals or entities specified in the CREATOR element (for example, editors, transcribers, illustrators, and convenors)."

As discussed for the DC.creator element, it is difficult to adequately define the division between those creating a resource and those contributing to its creation. It is therefore proposed, instead, that the elements be merged into a single repository (DC.creator) for all names associated with a resource, each tagged with their appropriate function(s).

DC.date

7  Date Label: DATE

"The date the resource was made available in its present form. The recommended best practice is an 8 digit number in the form YYYYMMDD as defined by ANSI X3.30–1985. In this scheme, the date element for the day this is written would be 19961203, or December 3, 1996. Many other schema are possible, but if used, they should be identified in an unambiguous manner."

Other than an immediate problem with the recommendation of an American ANSI standard rather than its international equivalent, ISO 8601, there was a feeling that the definition of DC.date was too narrow for sensible use within an ADS context.

Whilst archaeological dating information is obviously stored within the DC.coverage element, there is a need for several pieces of temporal information relating to creation and management of the resource itself including, perhaps, the start and end dates for the project — such as an excavation — directly associated with the data; the date the data were accessioned by ADS, and the date of the most recent modification to the catalogue record itself.

Where data mounted on the web for dissemination represent some form of snapshot from a 'live' database held off–line, there also needs to be scope for recording the date of the last snapshot and/or the expected date for the next snapshot to be made available in its place.

e.g.

Date[ISO8601] 1973–05–20  (project start)
[ISO8601] 1977–09–22  (projectEnd)
[ISO8601] 1997–06–02  (accessioned)
[ISO8601] 1997–06–03  (metadataLastModified)

Proposed ADS definition for this element

"Dates associated with the creation and dissemination of the resource. These dates should not be confused with those related to the content of the resource (AD 43 in a database of artefacts from the Roman invasion of Britain) which are dealt with by DC.coverage or its subject (1812 in relation to Tchaikovsky's eponymous overture) which are dealt with by DC.subject."

SCHEMEs

SCHEMEs useful to the ADS interpretation of this element might, provisionally, include;
ISO8601ISO 8601 — "Data elements and interchange formats — Information interchange — Representation of dates and times". Where the option is available, this is the preferred SCHEME for citation of dates, and takes the form YYYY or YYYY–MM–DD. It is also capable of handling time if required.

TYPEs

TYPEs useful to the ADS interpretation of this element might, provisionally, include;
accessionedthe date this resource was accessioned by the Archaeology Data Service. Where no TYPE is specified, accessioned is assumed. An accessioned date is required for every resource.
projectStartthe start date for the project/ resource being described.
projectEndthe completion date of the project/ resource being described.
lastUpdatewhere the catalogue entry describes a 'snap–shot' from a live database, last update records the date on which the most recent snap–shot was uploaded for access.
nextUpdatewhere the catalogue entry describes a 'snap–shot' from a regularly updated live database, next update records the date on which the next snap–shot is expected to be available for access.
metadataLastModifiedthe date on which the metadata/ catalogue record was last altered.

DC.type

8  Resource Type Label: TYPE

"The category of the resource, such as home page, novel, poem, working paper, technical report, essay, dictionary. It is expected that RESOURCE TYPE will be chosen from an enumerated list of types. A preliminary set of such types can be found at the following URL:

http://www.roads.lut.ac.uk/Metadata/DC-ObjectTypes.html"

Although the list of potential TYPEs prepared by Knight et al forms a useful example of the types of information that could be stored in this element, they are insufficient for the requirements of an AHDS catalogue. There is also a blurring of the divisions between genre style information and other forms of DC.type which perhaps requires clarification.

Archaeologically, this element is required to hold information on what form of resource is being described, such as excavation, corpus, geophysical survey, etc. As with other elements, it will be necessary to carefully define the DC.type list in order that it prove sufficiently detailed for archaeological use and sufficiently generalised for inter–disciplinary application.

As well as agreeing upon a suitably concise yet detailed list of archaeologically relevant resource DC.types, it might prove useful to extend the four levels of excavation archive defined in the Cunliffe Report [39]. These levels are;

Level 1raw resource — the excavation site itself
Level 2raw data — the excavation records
Level 3interpretation — phase diagrams, etc, and the entire archive in the state it should be left
Level 4publication
Similarly, MAP2 [14] defines a five level hierarchy for the deliverables associated with archaeological fieldwork, where Cunliffe's Level 3 is split to become MAP2's Phase 3 and 4;
Phase/ Level 1project design specification
Phase/ Level 2site records
Phase/ Level 3assessment report, stating academic potential of the archive
Phase/ Level 4research archive
Phase/ Level 5publication
The interpretation and meaning of each of these might be sufficiently generalised for all archaeological data to produce a five–part model;
Level 1Resourcethe field before it is excavated, the pot before it is studied in detail, etc
Level 2Observationexcavation context records, Geophysical survey raw data, basic measurements of a pot
Level 3Processstratigraphic matrix, typological series, processed Geophysical survey data
Level 4Interpretationfeatures identified on a Geophysical survey plot, a GIS viewshed analysis, a database of Anglo–Saxon brooches
Level 5Disseminationa published report, a finished CAD model, or other resource in sufficient shape to be freely and widely disseminated as an object in its own right
Such a model could — if accepted — be used as a required input for the DC.type element, as well as the more generalised textual descriptions of excavation, corpus, geophysical survey, etc.

Proposed ADS definition for this element

"The general form of a resource, such as text, image etc. Where greater precision is required, the form may be refined hierarchically; for example text.thesis.

Unless a SCHEME is specified, it is assumed that DC.type values are drawn from the evolving list at http://sunsite.Berkeley.EDU/Metadata/types.html."

SCHEMEs

SCHEMEs useful to the ADS interpretation of this element might, provisionally, include;
AACR2Anglo–American Cataloguing Rules general material designations [36].
ADSthe ADS generic coding schema, outlined above. An ADS code is required for each resource.

TYPEs

TYPEs are, perhaps, not applicable to this element, as all values conceivably suitable for inclusion in the qualifier, TYPE, are also suitable for inclusion as entries in the content of the element, DC.type.

DC.format

9  Format Label: FORMAT

"The data representation of the resource, such as text/html, ASCII, Postscript file, executable application, or JPEG image. The intent of specifying this element is to provide information necessary to allow people or machines to make decisions about the usability of the encoded data (what hardware and software might be required to display or execute it, for example). As with RESOURCE TYPE, FORMAT will be assigned from enumerated lists such as registered Internet Media Types (MIME types). In principal, formats can include physical media such as books, serials, or other non-electronic media."

At a basic level, use of DC.format is uncontentious, with Internet Media Types [40] being used where available to define file formats.

Discussion also ranged around the use of DC.format to hold details of file size — whether a size in Mb, a number of records, a duration in seconds for a video, a number of words for a book or whatever.

e.g.

Format[IMT] application/postscript [fileType]
[SI] 12300 (fileSize)
134 pages (length)

Proposed ADS definition for this element

standard Dublin Core definition is fine.

SCHEMEs

SCHEMEs useful to the ADS interpretation of this element might, provisionally, include;
IMTInternet Media Types, such as text/html for a web page, application/postscript for a Postscript file, etc [40].
SISystème International d'Unités, the internationally agreed set of units for measurement; metres for length, seconds for time, kilobytes (Kb) for computer file size, etc [41].

TYPEs

TYPEs useful to the ADS interpretation of this element might, provisionally, include;
fileSizethe size of a computer file, in Kb.
fileTypethe file format of a digital expression of the resource. fileType must use the IMT SCHEME, is required for every record of a digital resource, and is the default where no TYPE is specified.
lengththe length of a book–like resource (in pages) if printed. Potentially also (in conjunction with a SCHEME of SI) the shelf space occupied by an archive, in metres.
mediumThe medium on which a resource is held; Compact Disc, vellum, etc.

DC.identifier

10  Resource Identifier Label: IDENTIFIER

"String or number used to uniquely identify the resource. Examples for networked resources include URLs and URNs (when implemented). Other globally-unique identifiers,such as International Standard Book Numbers (ISBN) or other formal names would also be candidates for this element."

Use of DC.identifier is uncontentious, and should be required for all records in the collection. Each record will need an internal ADS identifier, as well as any number of identifiers that uniquely define it within the host resource. Agreed SCHEME names need to be defined in order to allow the provenance of any DC.identifier to be established.

e.g.

Identifier[ADS] 154
[NYCC_SMR] 145643C
[NMRE] ny64sw72

Proposed ADS definition for this element

standard Dublin Core definition is fine.

SCHEMEs

SCHEMEs useful to the ADS interpretation of this element might, provisionally, include;
ADSADS internal identification number, uniquely identifying any resource within the catalogue. Where no SCHEME is specified, ADS is assumed. An ADS identifier is required for every resource, along with at least one other identifier.
ISBNInternational Standard Book Number.
ISSNInternational Standard Serial Number.
NMRSNational Monuments Record for Scotland site identifier, drawn from the NMRS NUMLINK field.
URLA Uniform Resource Locator (WWW address) for the resource.

TYPEs

not applicable to this element, except where drawn from a SCHEME?

DC.source

11  Source Label: SOURCE

"The work, either print or electronic, from which this resource is derived, if applicable. For example, an html encoding of a Shakespearean sonnet might identify the paper version of the sonnet from which the electronic version was transcribed."

Where, for example, a digital version of a paper archive or report has been created, this field might refer back to the original. Digital resources derived from (rather than transcribed from) other resources — whether paper or digital — will be described in DC.relation rather than here.

Proposed ADS definition for this element

standard Dublin Core definition is fine?

SCHEMEs

SCHEMEs useful to the ADS interpretation of this element might, provisionally, include;
SPAn identification of the AHDS Service Provider making access to the resource possible. An SP is required for every resource. SPs must be selected from this controlled list;
ADSArchaeology Data Service
HDSHistory Data Service
OTAOxford Text Archive
PADSPerfoming Arts Data Service
VADSVisual Arts Data Service
ISBNInternational Standard Book Number.
ISSNInternational Standard Serial Number.
URLA Uniform Resource Locator (WWW address) for the resource.

TYPEs

not applicable to this element, except where drawn from a SCHEME?

DC.language

12  Language Label: LANGUAGE

"Language(s) of the intellectual content of the resource. Where practical, the content of this field should coincide with the Z39.53 three character codes for written languages.

See: http://www.sil.org/sgml/nisoLang3-1994.html"

As with DC.date, it is preferred that this element is specified using an international rather than American standard. International standards such as ISO 639 (names of languages), perhaps used in conjunction with ISO 3166 (names of countries), might be recommended.

DC.language refers to human–readable language, and is not intended to cover computer languages such as C++ or Pascal.

Proposed ADS definition for this element

standard Dublin Core definition is fine.

SCHEMEs

SCHEMEs useful to the ADS interpretation of this element might, provisionally, include;
ISO639ISO 639, the international standard for naming human languages.
ISO3166ISO 3166, the international standard for naming nations of the Earth.

TYPEs

not applicable to this element, except where drawn from a SCHEME?

DC.relation

13  Relation Label: RELATION

"Relationship to other resources. The intent of specifying this element is to provide a means to express relationships among resources that have formal relationships to others, but exist as discrete resources themselves. For example, images in a document, chapters in a book, or items in a collection. A formal specification of RELATION is currently under development. Users and developers should understand that use of this element should be currently considered experimental."

This element is used to define links to obviously related resources and also as a core part of the method by which hierarchical relationships may be established between the individually described elements of a collection such as a large excavation project or a Sites & Monuments Record.

In these cases, it is felt that the collection itself may be allocated a catalogue entry and that each part of the collection would be linked to this by means of a DC.relation link. One obvious example of this is the way in which all catalogue records have a DC.relation to the record describing the ADS catalogue itself, with the ADS catalogue (and those of the other Service Providers) linked to a description of the AHDS catalogue using the same mechanism.

It appears infeasible to include relationships pointing in the opposite direction (from catalogue to catalogue component), and it may also be difficult to justify including 'sibling' relationships between components of a single catalogue. Thought needs to be given to the requirement (if any) for an easy ability to identify components of a single catalogue at the time of searching; is the current proposal sufficient, where catalogue records will show their relationship to their parent collection but not to their siblings?

Proposed ADS definition for this element

standard Dublin Core definition is fine.

SCHEMEs

SCHEMEs useful to the ADS interpretation of this element might, provisionally, include;
ADSADS internal catalogue number.
ISBNInternational Standard Book Number.
ISSNInternational Standard Serial Number.
URLA Uniform Resource Locator (WWW address) for the resource.

TYPEs

TYPEs useful to the ADS interpretation of this element might, provisionally, include;
IsParentOfThe resource being described is hierarchically above the resource to which this DC.relation points. i.e. the resource being described is the collection of which the related resource is a part.
IsChildOfThe resource being described is hierarchically below the resource to which this DC.relation points. i.e. the resource being described is a part of the collection to which it is being related.
IsSiblingOfThe resource being described is hierarchically adjacent to the resource to which this DC.relation points. i.e. the resource being described is another part of the same collection, whose relationship is for some reason worthy of being made explicit.

DC.coverage

14  Coverage Label: COVERAGE

"The spatial locations and temporal durations characteristic of the resource. Formal specification of COVERAGE is currently under development. Users and developers should understand that use of this element should be currently considered experimental."

Notions of spatial and temporal location are central to archaeological resource discovery and, as such, this element will have a key role to play in providing access to the holdings of the Archaeology Data Service. Usage guidelines for the DC.coverage element itself are still evolving within the wider Dublin Core community, with a Working Party [42] specifically tasked to examine the issues involved. ADS is represented on this Working Party, and hopes to largely adopt its recommendations when they are complete.

It is important to retain the possibility of defining both spatial and temporal coverage in a variety of fashions, including one or more co–ordinate systems, place names, numeric dates and temporal periods. As such, the ADS may put forward recommendations for the use of, for example, full 12–figure (or 13 in the north of Scotland) Ordnance Survey grid references for the lower left and top right corners of a 'bounding box' around the resource being described, as well as a relevant place name drawn from a controlled list such as the Thesaurus of Geographic Names [38] or Ordnance Survey's 1:50,000 place name gazetteer, but it may well prove necessary to continue to accept locational information in other formats for the foreseeable future.

A great deal of confusion was felt as to which aspects of spatial and temporal location could be usefully recorded in DC.coverage. Whilst clarification of the role of DC.date in recording such details as the date of an archaeological excavation helped to explain temporal coverage, the spatial problems remained unresolved for many participants.

With differing notions as to the important spatial characteristics of a resource, DC.coverage for an artefact or group of artefacts could potentially encompass the location of discovery (the most obvious), the location of creation, and the present location. A Samian bowl excavated in York, for example, could be recorded as having a DC.coverage of 'York' (or, more precisely, a grid reference for the find spot/ excavation), southern France (where it was made) or even the whole Roman Empire (the cultural unit to which it is, perhaps, most closely affiliated). Each of these is important to one aspect of archaeology, but it is infeasible to record every possible DC.coverage for every possible resource, and the location of discovery is assumed to be the most valuable single attribute to record.

The example of the Roman empire illustrates a different — but equally pressing — problem with the use of cultural or period labels. Whilst the concept of 'Roman' appears clear, it is in fact extremely confusing, with the 'Roman period' having different durations throughout Europe (and, accordingly, the 'Roman Empire' being a different size at different periods of time). 'Roman' artefacts are to be found well outside the boundaries of the Empire, as well as within, and many artefacts, sites and concepts continue in use well after the demise of the Empire. Indeed, Roman–inspired art and architecture may still be seen today; is it 'Roman'?

The notion of terms such as 'Roman' or 'Georgian' as loose cultural labels as well as racial/ nationalistic/ temporal signifiers adds further confusion to the use of textual labels for spatial and temporal coverage, as such terms may also, conceivably, be placed in DC.subject, where their meaning may be very different, and also temporally or spatially defined, but in a different manner to the definition given to the term in DC.coverage. As such, it may prove important to develop means by which terms utilised in DC.subject may be tied to specific instances of the use of the DC.coverage element, but a satisfactory solution to this is not currently forthcoming.

Proposed ADS definition for this element

standard Dublin Core definition is fine.

SCHEMEs

SCHEMEs useful to the ADS interpretation of this element might, provisionally, include;
AATArt & Architecture Thesaurus, which includes period/ cultural names [11].
DDLatitude and Longitude expressed in decimal degrees, in the form DD.XXXX, where XXXX represents decimal portions of a degree. The number is preceded by a minus sign (-) for locations south or west of meridian.
DMSLatitude and Longitude expressed in degrees minutes and seconds, in the form DDD–MM–SSX, where X is a direction, north, south, east or west of meridian.
ISO31International Standard, ISO31, detailing the expression of dates and times.
OS10KOrdnance Survey of Great Britain 1:10,000 scale map sheet code. Many UK archaeological records use this as the basis of site identification. The reference will locate most sites to within approximately 5 kilometres, and is felt to be both sufficiently accurate for most resource discovery purposes and sufficiently vague to address many concerns over site security.
NGROrdnance Survey of Great Britain National Grid Reference. A full (12–13 figure) grid reference based upon the Ordnance Survey grid. References should be fully numeric, with the two–letter code for the 100km grid square converted to leading numbers on the reference, and will take the form xxxxxx[.xx] [y]yyyyyy[.yy], where [.xx] and [.yy] allow for the optional expression of centimetres in the reference, and [y] is for use in the far north of Scotland, where northings are greater than 999999 metres north of origin. Where metre precision is not available, zeroes should be added to the end of both easting and northing to create a 12–figure reference. Units of measure are metres for measurements of x, y and z.
TGNThesaurus of Geographic Names [38].
UTMXXUniversal Transverse Mercator, with XX signifying the appropriate UTM zone. Units of measure are metres.

TYPEs

TYPEs useful to the ADS interpretation of this element might, provisionally, include;
xThe X co–ordinate, or 'easting' element of a grid reference.
minThe minimum value of X.
maxThe maximum value of X.
yThe Y co–ordinate, or 'northing' element of a grid reference.
minThe minimum value of Y.
maxThe maximum value of Y.
zThe Z co–ordinate or elevation.
minThe minimum value of Z.
maxThe maximum value of Z.
tA temporal descriptor.
minThe minimum value of T.
maxThe maximum value of T.
pointA single point, expressed as a pair of X and Y co–ordinates of form xxxxxx yyyyyy.
lineA linear feature, expressed as a string of X and Y co–ordinates of form xxxxxx yyyyyy xxxxxx yyyyyy ...
polygonA polygon, expressed as a string of X and Y co–ordinates.
excludeUsed in conjunction with include to define 'holes' or gaps in a distribution or feature.
includeUsed in conjunction with exclude to define areas where a particular feature or distribution is to be found.
placeNameThe name of a place, preferably drawn from a controlled SCHEME such as those outlined above.
This — and other — subtype may be further refined to, for example, allow DC.coverage.placeName.authority = name of a local authority, DC.coverage.placeName.authority.1974 = name of a post–1974 UK local authority or even DC.coverage.placeName.authority.1974.region = name of a post–1974 Scottish regional council. As can be seen, a great deal of precision can be offered where necessary, but the detail can be removed where less capable search engines are used. i.e. the highly precise DC.coverage.placeName.authority.1974.region = Strathclyde can be used and understood by search systems designed to handle it, allowing both search engine and user to know that 'Strathclyde' must be a post–1974 Scottish regional council. Where the level of detail is not required, or where a more generic search engine which doesn't understand this detail is used, the 'authority.1974.region' may be ignored or removed, and both user and search engine will still know that 'Strathclyde' is the name of a place.
periodNameThe name of a temporal period, preferably drawn from a controlled SCHEME such as those outlined above.
locationalPrecisionA measure of the precision with which x and y have been recorded, using the same units of measure as the locational elements themselves. Where one is recorded less precisely than the other, the coarsest precision is given.
Rather than recording exact values (e.g. 23.5), ranges might more usefully be given of the form 1–10 (metres) = locationalPrecision 10 [i.e. precision better than 10], 10–100 (metres) = locationalPrecision 100, etc.
To allow both temporal and spatial discontinuity, a number may be appended to element names in order to allow the logical repeating of elements, as discussed for DC.creator.

DC.rights

15  Rights Management Label: RIGHTS

"The content of this element is intended to be a link (a URL or other suitable URI as appropriate) to a copyright notice, a rights-management statement, or perhaps a server that would provide such information in a dynamic way. The intent of specifying this field is to allow providers a means to associate terms and conditions or copyright statements with a resource or collection of resources. No assumptions should be made by users if such a field is empty or not present."

Under ADS usage, this element would always contain a link to an ADS statement of rights management, as well as (optional) links to similar statements from the data depositor, where relevant.

As well as these links to legal statements of control, a simple coding scheme should also be developed, whereby users can quickly discover both whether they will be allowed to access the data at all (some data may be for UK Higher Education use only, for example) and what they may be allowed to do with it once they have it (some data may be freely useable and re–distributable, whilst others might be controlled in some fashion). This coding scheme need not cover the intricacies of individual data use conditions, but rather is intended as another aspect of initial resource discovery in that it helps the user to know whether or not it is worth their while proceeding further; the data may be perfect for their needs, but if they are not allowed access, there is no point in their continuing further.

Proposed ADS definition for this element

standard Dublin Core definition is fine.

SCHEMEs

SCHEMEs useful to the ADS interpretation of this element might, provisionally, include;
URLA Uniform Resource Locator (WWW address) for the resource.
AHDSA basic expression of usage restrictions for the resource. An AHDS code is required for all resources, along with a URL for detailed rights definitions, and should be drawn from a list based upon the following. The exact terms and definitions await completion of the AHDS–wide Rights Management Framework;
freeThe resource may be freely used, providing that adequate citation is included. See the web page providing a statement of rights for this resource to discover any special wordings for the citation.
NotProfitThe resource may only be utilised for legitimate not–for–profit purposes. See the web page providing a statement of rights for this resource to discover the details of allowable usage and citation.
educationThe resource may only be used by members of educational establishments for legitimate not–for–profit use. See the web page providing a statement of rights for this resource to discover the details of allowable usage and citation.
UK_HEThe resource may only be used by members of the UK's Higher Education community. See the web page providing a statement of rights for this resource to discover the details of allowable usage and citation.
restrictedUse of the resource is restricted in some other fashion. See the web page providing a statement of rights for this resource to discover the details of allowable usage and citation.

TYPEs

not applicable to this element, except where drawn from a SCHEME?

A Model for Implementation

It is obvious that Dublin Core–style metadata based on a structure such as that discussed above is inadequate for describing the detailed contents or structure of archaeological resources, and it should be stressed once more that this is not the intention of this aspect of the ADS metadata strategy. Rather, this Dublin Core metadata structure is intended merely to facilitate the discovery of diverse distributed resources by;
Ideally, of course, all descriptions of the resources on offer could be controlled by reference to a limited number of agreed SCHEMEs. In the short term, though, data providers face other constraints including funding, established internal practices and external organisational pressures which perhaps prevent them from altering internal data structures in order to comply fully with this resource discovery model. The model offered therefore accepts this fact, and is the sum of a series of compromises between ease of use, ease of deposit and functionality. Pilots such as the Archaeology Data Service/ Royal Commission on the Ancient and Historical Monuments of Scotland (RCAHMS) joint project, Accessing Scotland's Past, will serve to demonstrate the usefulness of this model over the next few months, and will identify areas in which refinement of the model might be required.

Resource Discovery in Context

Adopting a similar model to that proposed independently within the National Geospatial Data Framework's [28] metadata working party , ADS is advocating a flexible, distributed, model for both data and metadata.

Rather than hold all archaeological data in a single location, the ADS is exploring state of the art technical solutions such as Z39.50/ ISO 23950 [43], whereby the ADS may act as a broker directing potential users directly to 'live' databases on web servers and other computers all over the country. The provision of a live link to parts of the National Monuments Record of Scotland later this year through the Accessing Scotland's Past project will explore the technical issues behind this concept.

Similarly, metadata may also be distributed downwards to those best placed to provide it in the first place and keep it up to date: the data providers themselves. While basic issues such as reducing network traffic perhaps make it sensible for the most general Dublin Core metadata to be provided at the time of data deposit and then held solely within the Archaeology Data Service, more detailed metadata may well be linked through to this high level description from the data providers' own site. Indeed, in some experimental cases, the more detailed metadata may not exist as a specific file of information at all, but may be generated on the fly from the full database itself as output from a structured query submitted by the ADS metadata system.

Various models exist within ADS and elsewhere for extremely flexible — and distributed — metadata– and data–access structures, few of which have been tested before. A number of ADS pilot projects over the next twelve months will explore the issues involved, and present a researched model for the most effective form of implementation.

First Thoughts on Interface Design

A wealth of literature exists on designing interfaces between users and data, from the generic data presentation work of Edward Tufte [44] to more detailed volumes on Human–Computer Interaction (HCI) and computer interface design. ADS will consult these works and use them to guide design of a user interface to the collections.

More relevantly to this report, a number of interface issues arose in discussion of resource discovery, and should be raised here.

Isolating 'obvious' returns

The workshop suggested that, in many cases, a number of 'obvious' resources would be identified to the user. Assuming, for example, a search for resources on Roman sites in the UK, it might be expected that every local Sites & Monuments Record and all three National Monuments Records would be included in the set of resources returned to the user.

Whilst this information may be useful to the non–expert, the repetition of basic resource holdings may prove tiresome to the expert or frequent user. Thus, it was suggested that a mechanism be offered to allow the automatic exclusion of sites of this nature from search results.

AHDS integration issues

Given that the holdings of the ADS will form but a part of the wider AHDS integrated catalogue, it will be important to remember to state certain facts that, while perhaps assumed in an archaeological context, are less intuitive for other disciplines. This might include, for example, stating in DC.subject that a resource is archaeological in nature.

Degradation of spatial data

Given some of the concerns discussed under DC.coverage, it will be vitally important to include some intuitive means of displaying the degree by which spatial information such as grid references have been degraded for security reasons. There are a number of display mechanisms that might be used, and each should be explored more fully.

Issues to be Resolved

The workshop and its aftermath have raised a number of issues that either require an AHDS–wide strategy decision or simply further study of the implications.

The main issues not covered explicitly elsewhere in this report are addressed briefly, below.

Absence of Data and 'null' Values

There is potentially a huge difference in meaning between cases in which a value is not relevant for inclusion in a metadata field, not known, zero (0), or simply not included by the metadata compiler.

The implications of each perhaps need exploration by AHDS, and it may prove necessary to explicitly specify each of the above, rather than simply leaving a blank entry in the metadata description.

Definitions of 'Collection'

The model proposed by the ADS and other Service Providers is based upon the notion of 'collections' of resources. The model appears infinitely extensible, both upwards from the Service Provider towards the notion of a single AHDS collection and beyond, and downwards within the Service Provider to increasingly detailed definition of elements within deposited collections. Thought needs to be given across the Service Providers to what the various notions of 'collection' imply, whether for Collections Management, inter–Service Provider collaboration or the future development of the model within and beyond AHDS.

Identification and Maintenance of SCHEMEs

If interoperability is to be assured, the various SCHEMEs proposed within each Service Provider will need careful vetting against one another in order to avoid conflicts of interpretation. Also, a mechanism needs to be defined within the AHDS whereby new SCHEMEs can be adopted, and abbreviations for them assigned. It will also be useful to devote time and effort to devising effective mappings between the various allowable SCHEMEs in order to allow users to continue using their favourite scheme whilst still gaining easy access to resources coded using different terminology.

The AHDS' draft integrated report introduces the concept of an AHDS registry of AHDS–wide and Service Provider–specific SCHEMEs and TYPEs, as well as providing guidance on the means by which new values may be added. This will be presented in a fuller form in the final version of the AHDS integrated report, due in October 1997.

References

[1] Trant, J., 1996, The Arts and Humanities Data Service and UK Office for Library and Information Networking: A co-ordinated strategy to identify shared metadata requirements [online]. Arts & Humanities Data Service & UK Office for Library & Information Networking. Available from: http://www.kcl.ac.uk/projects/ahds/jobs/proposal.html
[Accessed 18 May 1997].

Miller, P., 1997. Resource Discovery Workshops: a guide to implementation and participation [online]. AHDS/UKOLN. Available from: http://www.york.ac.uk/~apm9/focus01.html
[Accessed 22 Apr 1997].

[2] The Dublin Core Metadata Element Set Home Page [online]. OCLC. Available from: http://www.oclc.org:5046/research/dublin_core/
[Accessed 22 Apr 1997].
[3] The Archaeology Data Service Home Page [online]. Archaeology Data Service. Available from: /
[Accessed 7 May 1997].
[4] The Arts & Humanities Data Service Home Page [online]. Arts & Humanities Data Service. Available from:http://ahds.ac.uk/
[Accessed 7 May 1997].
[5] Wise, A. & Miller, P., 1997. Why Metadata Matters in Archaeology, Internet Archaeology 2 [online]. Available from: http://intarch.ac.ukk/journal/issue2/wise_index.html
[Accessed 21 May 1997].
[6] Bower, J. & Roberts, A., (Eds.), 1996, Developments in museum and cultural heritage information standards: A joint project of the Getty Information Institute (formerly the Getty Art History Information Program) and the International Committee for Documentation of the International Council of Museums [online]. J. Paul Getty Trust & ICOM–CIDOC. Available from: http://www.cidoc.icom.org/stand1.htm
[Accessed 28 May 1997].
[7] MDA, 1997, wordHOARD [online]. Museums Documentation Association. Available from: http://www.open.gov.uk/mdocassn/wrdhrd1.htm
[Accessed 28 May 1997].
[8] Gill, T., Grout, C. & Smith, L., 1997, Visual Arts, Museums and Cultural Heritage Information Standards: a domain–specific view of relevant standards for networked information discovery [online]. Visual Arts Data Service. Available from: http://vads.ahds.ac.uk/standards.html
[Accessed 28 May 1997].
[9] NGDF, 1997, The Map of Existing NGDF Related Initiatives [online]. National Geospatial Data Framework. Available from: http://www.ngdf.org.uk/NGDF6.htm
[Accessed 28 May 1997].
[10] MDA, 1996, Survey of terminology in UK Museums, 1996 [online]. Museums Documentation Association. Available from:http://www.open.gov.uk/mdocassn/survey.htm
[Accessed 28 May 1997].
[11] GII, 1997, The Art & Architecture Thesaurus [online]. Getty Information Institute. Available from: http://www.gii.getty.edu/aat_browser/intro.html
[Accessed 28 May 1997].
[12] Lavell, C., 1989, British Archaeological Thesaurus, CBA Practical Handbook 4. Council for British Archaeology.
[13] CIDOC, 1996, International Guidelines for Museum Object Information [online]. ICOM–CIDOC. Available from: http://www.cidoc.icom.org/guide0.htm
[Accessed 28 May 1997].
[14]English Heritage, 1991, Management of Archaeological Projects (MAP2). English Heritage.
[15] van der Plas, D., (Ed.), 1996, Multilingual Egyptological Thesaurus [online]. Publications Interuniversitaires de Recherches Egyptologiques Informatisees XIi. Available from: http://www.ccer.ggl.ruu.nl/thes/default.htm
[Accessed 28 May 1997].
[16] RCHME & ACAO, 1993, Recording England's Past: a data standard for the extended National Archaeological Record. Royal Commission on the Historical Monuments of England and Association of County Archaeological Officers.
[17] MDA, 1994, Social History and Industrial Classification (SHIC): a subject classification for museum collections. Museums Documentation Association SHIC Working Party. Second Edition.
[18] MDA, 1994, SPECTRUM: the UK Museum Documentation Standard. Museums Documentation Association.
[19] RCHME, 1996, Thesaurus of Building Materials: A standard for use in Architectural and Archaeological Records. Royal Commission on the Historical Monuments of England.
[20]RCHME & EH, 1995. Thesaurus of Monument Types. Royal Commission on the Historical Monuments of England.
[21] SMA, 1995, Towards an Accessible Archaeological Archive. The Transfer of Archaeological Archives to Museums: Guidelines for Use in England, Northern Ireland, Scotland and Wales. Society of Museum Archaeologists.
[22] GII, 1997, Union List of Artists' Names [online]. Getty Information Institute. Available from: http://www.gii.getty.edu/ulan_browser/intro.html
[Accessed 28 May 1997].
[23] The Aquarelle Home Page [online]. Available from: http://aqua.inria.fr/
[Accessed 28 May 1997].
[24]MDA, forthcoming. Archaeology Object Name Thesaurus. Museums Documentation Association.
[25] CIDOC, 1995, Draft International Core Data Standard for Archaeological Sites and Monuments [online]. ICOM–CIDOC. Available from:http://www.natmus.min.dk/cidoc/archsite/coredata/arch1.htm
[Accessed 28 May 1997].
[26] English Heritage, 1995, The English Heritage Geophysical Survey Database [online]. English Heritage Ancient Monuments Laboratory. Available from: http://www.eng-h.gov.uk/SDB/
[Accessed 28 May 1997].
[27] MDA, n.d., Simple Subject Headings [online]. Museums Documentation Association. Available from: http://www.open.gov.uk/mdocassn/ssh_int.htm
[Accessed 28 May 1997].
[28] Nanson, B., Smith, N. & Davey, A., 1995. What is the British National Geospatial Database? [online] AGI'95 Conference Proceedings. Association for Geographic Information/ Ordnance Survey. Available from: http://www.ordsvy.gov.uk/about_us/moreabus/extpaper/agi95/nansmit.html
[Accessed 18 May 1997].

Davey, A., 1996, Proceedings of NGD Seminar — June 1996 [online]. Ordnance Survey. Available from: http://www.ordsvy.gov.uk/about_us/moreabus/extpaper/ngdsemin/index.html
[Accessed 18 May 1997].

National Geospatial Data Framework Home Page [online]. National Geospatial Data Framework. Available from: http://www.ngdf.org.uk/
[Accessed 18 May 1997].

[29] Miller, P., 1996. Metadata for the Masses [online] 5. UK Office of Library & Information Networking. Available from: http://www.ukoln.ac.uk/ariadne/issue5/metadata- masses/
[Accessed 18 May 1997].

Miller, P. & Gill, T., 1997, Down Under with the Dublin Core [online] Ariadne 8. UK Office of Library & Information Networking. Available from: http://www.ariadne.ac.uk/issue8/canberra-metadata/
[Accessed 18 May 1997].

[30] Lagoze, C., Lynch, C.A. & Daniel, R., 1996. The Warwick Framework: a container architecture for aggregating sets of metadata [online]. Available from: http://cs- tr.cs.cornell.edu:80/Dienst/UI/2.0/Describe/ncstrl.cornell%2fTR96- 1593?abstract=warwick
[Accessed 18 May 1997].
[31] The History Data Service Home Page [online]. History Data Service. Available from: http://hds.essex.ac.uk/
[Accessed 21 May 1997].
[32] The Oxford Text Archive Home Page [online]. Oxford Text Archive. Available from: http://sable.ox.ac.uk/ota/
[Accessed 21 May 1997].
[33] FGDC, 1994. Content Standards for Digital Geospatial Metadata [online]. Federal Geographic Data Committee. Available from: http://geochange.er.usgs.gov/pub/tools/metadata/standard/metadata.html
[Accessed 18 May 1997].
[34] Miller, P., 1996, An application of Dublin Core from the Archaeology Data Service [online]. Archaeology Data Service. Available from: /project/metadata/dublin.html
[Accessed 28 May 1997].
[35] Knight, J. & Hamilton, M., 1997, Dublin Core Qualifiers [online]. Available from: http://www.roads.lut.ac.uk/Metadata/DC-SubElements.html
[Accessed 28 May 1997].
[36] CLA, LA & ALA, 1988, Anglo–American Cataloguing Rules Second Edition. Canadian Library Association, Library Association & American Library Association.
[37] Library of Congress, 1993, Library of Congress Subject Headings Sixteenth Edition.
[38] Harpring, P., 1997, Proper Words in Proper Places: the Thesaurus of Geographic Names, MDA Information 2/3. Museums Documentation Association; pp. 5–12.
[39]Cunliffe, B.W., (Ed.), 1983, The Publication of Archaeological Excavations: the report of the Joint Working Party of the Council for British Archaeology and the Department of the Environment. Department of the Environment.
[40] RFC 2045: Multipurpose Internet Mail Extensions (MIME) [online]. Available from: http://sunsite.auc.dk/RFC/rfc/rfc2045.html
[Accessed 28 May 1997].
[41] US Department of Commerce, 1991, Interpretation of the SI for the United States and Metric Conversion Policy for Federal Agencies [online]. United States Department of Commerce & National Institute of Standards & Technology. NIST Special Publication 814. Available from: http://ts.nist.gov/ts/htdocs/200/202/pub814.htm
[Accessed 28 May 1997].
[42]Dublin Core Element: Coverage Draft [online]. Dublin Core Coverage Element Working Party. Available from: http://www.alexandria.ucsb.edu/public-documents/metadata/dc_coverage.html
[Accessed 21 May 1997].
[43]Z39.50–1995 [online]. Z39.50 Maintenance Agency/ Library of Congress. Available from: http://www.loc.gov/z3950/agency/1995doce.html
[Accessed 22 May 1997].

Z39.50 Maintenance Agency Home Page [online]. Z39.50 Maintenance Agency/ Library of Congress. Available from:http://www.loc.gov/z3950/agency/
[Accessed 22 May 1997].

ISO/DIS 23950: Information and documentation — Information retrieval (Z39.50) — Application service definition and protocol specification. International Organisation for Standardization.

[44]Tufte, E.R., 1990, Envisioning Information. Graphics Press.
[45]OpenGIS Consortium Home Page [online]. Open GIS Consortium. Available from: http://www.opengis.org/homepage.html
[Accessed 28 May 1997].
[46]SABE Index Page [online]. MEGRIN. Available from: http://www.ign.fr/megrin/sabe/sabe.html
[Accessed 27 May 1997].
[47]National Council on Archives, 1997, Rules for the Construction of Personal, Place and Corporate Names. Available from:http://www.hmc.gov.uk/rules/title.html
[Accessed 31 July 1997].
AHDS
Service Providers
Resource Discovery
Workshop Reports