The Archaeology Data Service, along with a growing number of organisations around the world, advocates use of the Dublin Core for recording the information that helps potential users to find — and simply evaluate — your data. This information is known as 'resource discovery metadata'; information about your data (the 'resource') that helps people discover it.

Through more than three years of international development, the Dublin Core has evolved to become a series of fifteen broad categories, or elements. Each of these elements is optional, may be repeated as many times as required, and may be refined through the use of a developing set of sub–elements. The use of the Dublin Core within the Archaeology Data Service is discussed further elsewhere (Miller and Greenstein 1997, Wise and Miller 1997), and the current element definitions laid down across the Dublin Core community are available on the web.

The fifteen elements of the Dublin Core may be simply defined as:

• Title
The name given to this resource by its creator. The name need not necessarily be unique.
• Creator
Those persons or organisations responsible for creation of the resource being described, its source or surrogates, whose involvement is considered worthy of inclusion for the purpose of discovering said resource.
• Subject
That which the resource is about, preferably using terms drawn from a controlled vocabulary such as the Thesaurus of Monument Types.
• Description
A description of the content of the resource, such as a book abstract or a synopsis of database contents.
• Publisher
The entity(s) responsible for facilitating availability of the resource, such as a publisher, distributor, or a corporate entity.
• Contributors
his element is not used by ADS, as it causes too much confusion amongst users.
• Date
Dates associated with the creation and dissemination of the resource. These dates should not be confused with those related to the content of a resource (AD 43, in a database of artefacts from the Roman Conquest of southern Britain) or its subject (1812, in relation to Tchaikovsky's eponymous overture), both of which are dealt with in other elements.
• Type
The general form of a resource, such as text, image, etc.
• Format
The format, either physical (e.g. book, CD–ROM) or electronic (e.g. DXF file, HTML web page), of the resource being described.
• Identifier
A text string or number used as a unique identity for the resource. Examples include a resource-specific URL or ftp address, an excavation site code, or archival museum shelving number.
• Source
Any important earlier work(s) from which this resource is derived.
• Language
Language(s) of the intellectual content of the resource (i.e. English or Latin, rather than C++ or Pascal).
• Relation
Relationship to other resources. For example, the GIS resource being described might be part of an SMR or landscape study, both of which might have entries of their own to which this element could provide a link.
• Coverage
The spatial and temporal extent(s) pertaining to the resource. In both cases, coverage relates to the content of the resource, rather than to its collection or management. Likely coverages include the spatial location (whether a grid reference, place name [Skara Brae], or more ephemeral locator) and temporal period (whether a date, date range, or period label [Neolithic]) of the Skara Brae village and exclude the location of the museum in which the artefacts might now be found.
• Rights
This element is intended to be a link to a copyright notice, a rights management statement, or a software tool capable of providing such information in a dynamic fashion. The intent of specifying this field is to allow data providers a means to associate terms and conditions or copyright statements with a resource or collection of resources.

The Archaeology Data Service is working with other organisations in order to create a number of tools that will make it easier both for you to create this information, and for us to read it when you send it to us. This work is ongoing, and you should contact us before creating records for deposit with ADS in order to find out the latest developments in this work.

Until such time as these tools are available, it will be necessary for you to create these Dublin Core records manually, and send them through to us either on a computer disk or via e–mail. These options are discussed in a little more detail in Section 6.

With complex collections of computer files such as those present in most archaeological GIS, it is extremely difficult to draw up simple rules defining what you should create metadata records for (the GIS as a whole, every 'layer', every original data source, etc.). As a basic guide, it is sensible for you to create one record describing the GIS as a whole, plus one subsidiary record for each major resource 'type' stored in the system. If, for example, you created a GIS for Hampshire which recorded Neolithic burial monuments and Roman settlement patterns (well — you might!), it would seem sensible to create one record for the whole, one for the Neolithic part, and one for the Roman part, giving three records of which one (the whole GIS) is the 'parent' and two are 'children'. If in doubt, contact ADS for advice.

An important factor in ensuring that a user can sensibly compare records you create with those provided by others is the use of standardised terminologies and modes of expression. Whilst certainly not wanting to restrict all archaeologists to the use of a single standard for recording, or a single thesaurus for controlling terminology, the ADS does believe in the use of standards in general. As utilised by the ADS, the Dublin Core system allows users to identify a 'SCHEME' which controls the terms stored in any one occurrence of a Dublin Core element. Thus, a user could identify the Thesaurus of Monument Types (RCHME 1995) as a SCHEME for the Dublin Core Subject element, and describe their resource using terms drawn from this thesaurus. As all of the Dublin Core elements are repeatable, the user could then — if they wanted to — repeat the Subject element and define the Getty's Art & Architecture Thesaurus as their SCHEME. Importantly, each use of a Dublin Core element should only include terms drawn from one SCHEME. Where absolutely necessary, it is possible to enter information as 'free text', not qualified by any SCHEME, but such use of free text makes it far harder for users to search across resources meaningfully, and should thus be avoided. A non-exlusive list of relevant SCHEMEs for providing archaeologically relevant controlled terminology is discussed elsewhere (Wise and Miller 1997), and ADS staff are available to offer advice or clarification when needed.