ECAI Metadata Manual

Version 1.1, March 1999

Adapted from Dublin Core by Helen Jarvis & Nereida Cross
School of Information, Library and Archive Studies
The University of New South Wales

Edited & final revisions by Ian Johnson
School of Archaeology
The University of Sydney

with the assistance of members of ECAI and the ECAI Technical committee, including: Lou Burnard, Royol Chittradon, T. Matthew Ciolek, Lawrence Crissman, Nereida Cross, Jim Dowling, Maggie Exon, Karen Fredricksen, Janice Glowski, John Huntington, John Lehmann, Marilyn Levine, Helen Jarvis, Ian Johnson, Peter Moloney, Ruth Mostern, Andrew Wilson, Eric Yen, Jeanette Zerneke


Background

The ECAI meeting in Heidelberg in June 1998 decided to adopt the Dublin Core metadata standard, and to appoint a Metadata Sub-Committee, chaired by Helen Jarvis, to recommend the specifics of this standard, with guidelines for use by ECAI.

This draft was revised following the Australian ECAITech Meetings 29th August and 6th November, 1998, and the ECAITech meeting in Taipei in January 1999, when it was approved by the ECAI Business meeting for a testing period prior to consideration for adoption as the ECAI standard at the following ECAI meeting (June 1999).

The ECAI metadata standard was materialised in the ECAI Metadata Clearinghouse between January - March 1999 by Ian Johnson, with programming by Jesse Sweeney and Matthew Bruce.

What is metadata?

Metadata is data which describes the content of datasets. Metadata allows one to search for relevant datasets without having to search the whole of every dataset..

ECAI stores metadata on ECAI datasets in a centralised Internet-accessible database, known as the ECAI Metadata Clearinghouse. The Clearinghouse can be updated and searched through a web browser interface. The web interface controls entry of the metadata to ensure that it conforms with the standards defined by ECAI, which are laid out in the following pages.

Contributing datasets to ECAI

To contribute a dataset to the ECAI resource base, you must register your metadata with the ECAI Metadata Clearinghouse. You may copy existing metadata from your web page or create the required metadata using the TimeMap Metadata Editing software (see ECAI/TimeMap Metadata Clearinghouse User Guide Vsn 1.0).

The ECAI Metadata Clearinghouse also stores information required to locate your resource (such as a URL or server details). The software automatically assigns an ECAI Dataset ID which will uniquely identify your dataset.

Related documentation

Operation of the metadata search and entry tools is described in:

ECAI/TimeMap Metadata Clearinghouse User Guide Vsn 1.0
Ian Johnson, Jan. 1999
http://www.ecai.org/metadata/user_guide

Abstract: This document details the use of web-based and PC-based software for editing metadata to controlled ECAI standards, and registration of datasets with the ECAI Metadata Clearinghouse.

Preparation of datasets for inclusion in the clearinghouse is discussed in:

TimeMap/ECAI Data Preparation Manual Vsn 1.0
Ian Johnson, Jan. 1999
http://www.timemap.net/dataprep_manual

Abstract: This document provides an overview and detailed set of instructions for creating cultural databases and making them accessible to the TimeMapo viewer software (TMView) both locally and across the Internet through the ECAI Metadata Clearinghouse.


Notes

  1. Elements and Sub-elements have been derived from the Dublin Core and the latest available reports from various Element Working Groups. Several Elements and Sub-elements have been added to meet ECAI’s specific needs, and are flagged accordingly;
  2. Certain Elements are defined by ECAI as mandatory and must occur at least once in the description of a dataset for acceptance by the ECAI Metadata Clearinghouse.
  3. Users are encouraged to supply data for all Elements in the default set of metadata elements (which the software inserts automatically for new datasets), whether mandatory or not;
  4. A set of appropriate Schemes is defined for each Element. An asterisk (*) indicates the default/preferred value selected when an Element is added through the TimeMap Metadata Editor software. Where no scheme is specified in the examples, it is taken as Free Text.
  5. Most Elements are repeatable except dc.Title, dc.date and sub-elements of dc.coverage. Repeated entries should be used where more than one value applies, or for very long textual description. Non-repeatable entries are flagged in this text;
  6. ECAI dataset providers are advised also to insert their ECAI metadata into the <HEAD> section of their HTML web pages to assist retrieval by WWW search engines such as Alta Vista or Google. The metadata required may be exported in HTML 4 format from the ECAI/TimeMap Metadata Clearinghouse using the metadata editing software.

ECAI metadata elements and values in the <HEAD> section of an HTML page look like the following examples:

a) for an unqualified Element:

<META NAME="DC.Title" CONTENT="ECAI - Berkeley Home Page">

b) for a qualified Element:

HTML 2.0/3.2 syntax

<META NAME="DC.Date.Created" CONTENT="(SCHEME=ISO8601) 1998-11-23">

HTML 4.0 syntax

<META NAME="DC.Date.Created"

SCHEME="ISO8601"

CONTENT="1998-11-23">


1. DC.Title

DC.Title*

The name given to the resource by the CREATOR or PUBLISHER
Mandatory, Not Repeatable, Free Text

Examples:

DC.Title ECAI - Berkeley Home Page

DC.Title Buddhist Studies - Schools of Zen Buddhism

DC.Title County-level Administrative Boundaries of China

Notes: If the resource does not appear to have been given a Title by the Creator or Publisher, then construct a brief title indicating the scope of the resource being described.

DC.Title.Alternative

Use for subtitles and variant titles, including parallel titles in different languages.
Optional, Free Text


2. DC.Creator

DC.Creator.PersonalName *

DC.Creator.CorporateName

Creator or Author. The person or organization primarily responsible for creating 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.
Mandatory (PersonalName) / Optional (CorporateName), Free Text*, LCNAF

Notes: Use the format Family Name, Given Name for Western style personal names: eg Smith, Jan ; Lin, Simon. Only use the comma to show inversion. Use the accepted local format for non-Western names i.e. direct order (without comma) for Vietnamese, Chinese, Japanese, Thai and Malay names, but inverted for most Indonesian names. Refer to Anglo-American Cataloging Rules for guidance.

Enter workgroup, department, session or workshop name under PersonalName if no single individual is responsible. Use CorporateName for conference names.

In cases of lesser responsibility, other than creation, use Contributor.

Where the creator is unknown, enter "Unknown".

Schemes: The schemes are Free Text or LCNAF (Library of Congress Name Authority File), which could be helpful for formulating corporate names.

DC.Creator.PersonalName.Address
DC.Creator.CorporateName.Address

Includes any type of address including email. Email address should be included. Although optional, use of these elements is strongly encouraged.
Optional, Free Text*, URL, Email

Examples:

DC.Creator.PersonalName Lin, Simon
DC.Creator.PersonalName Zhu Liang-feng
DC.Creator.PersonalName Dang Ngoc Dinh
DC.Creator.PersonalName Ciolek, T.Matthew
DC.Creator.PersonalName.Address tmciolek@coombs.anu.edu.au [Email]
DC.Creator.PersonalName.Address http://ciolek.com.au [Scheme URL]


3. DC.Subject

DC.Subject

The topic of the resource - keywords or phrases.
Mandatory, Free Text*, LCSH, AAT, LCNAF

Notes: Provide keywords or phrases (generally no more than six) that describe the subject or content of the resource. You may also assign LCSH to be monitored by ECAI, or other thesaurus or controlled vocabulary such as AAT of relevance to the subject area of the resource being described. For convenience of data entry, use pipe symbol {|} to separate subject entries on a single line.

Schemes: Free Text use for keywords - single words or phrases; LCSH (Library of Congress Subject Headings); AAT (Art and Architecture Thesaurus); LCNAF (Library of Congress Name Authority File) – particularly useful for corporate names used as subjects, as in the case of organisational web sites.

Examples of Free Text keywords or phrases:

DC.Subject Cambodia

DC.Subject Genocide

DC.Subject GPS

DC.Subject Human rights

Example of LCSH:

DC.Subject Cambodia—History, Democratic Kampuchea 1975-1979 [LCSH]


4. DC.Description

DC.Description

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.
Mandatory, Free Text

Notes: Descriptive information can be taken from the item itself (in the introductory or front matter, or the first few paragraphs) or from an abstract or other structured description. Normally, if a Description cannot be found it should be constructed by the metadata provider. Description should be limited to a few brief sentences. Try to provide a clear indication of contents and, where possible, concrete figures indicating the extent. Avoid repetition. No need to duplicate subject keywords.

Approximately 100 words, absolute maximum 500 words.

Note: The maximum text which can be stored against one entry in the metadata clearinghouse is 250 characters. Repeat the keyword for longer descriptions (the software will automatically split longer descriptions into repeated elements, or you can carry out the split yourself – inserting a pipe symbol (|) in the text will split it into separate elements at that point).

Example:

DC. Description The Cambodian Genocide Program Documentation Project at the University of New South Wales highlights the documentary activities of the CGP in Australia and presents the Cambodian Genocide Data Bases (CGDB), an archive of biographic, bibliographic, photographic and geographic data pertaining to war crimes, genocide and other crimes against humanity during the Democratic Kampuchea regime, 1975-1979.


5. DC.Publisher

DC.Publisher *

The entity responsible for making the resource available in its present form, such as a publishing house, a university department, or a corporate entity. Identifies the entity that provides access to the resource.
Mandatory, Free Text

Notes: If the nature of the responsibility is ambiguous, the recommended practice is to use Publisher for organizations, and Creator for individuals. In cases of lesser responsibility, other than creation, use Contributor.

DC.Publisher.Address

The address of the publisher. Includes any type of address. An email address or URL is preferred and should always be included if possible.
Optional, Free Text*, URL, Email

Examples:

DC.Publisher Oxford University Press
DC.Publisher NSW National Parks and Wildlife Service

DC.Publisher MapInfo Corporation

DC Publisher Cambodian Genocide Program

DC.Publisher.Address cgp@yale.edu [Email]

DC.Publisher.Address http://cgp.harvard.edu [URL]


6. DC.Contributor

DC.Contributor.PersonalName *

DC. Contributor.CorporateName

Person(s) or organization(s), in addition to those specified in the CREATOR element, who have made significant though secondary intellectual contributions to the resource eg. editors, transcribers, illustrators, and convenors.
Optional, Free Text*, LCNAF

Notes: Use the format Family Name, Given Name for Western style personal names: eg Smith, Jan ; Lin, Simon. Only use the comma to show inversion. Use the accepted local format for non-Western names i.e. direct order (without comma) for Vietnamese, Chinese, Japanese, Thai and Malay names, but inverted for most Indonesian names. Refer to Anglo-American Cataloging Rules for guidance.

Schemes: The schemes are Free Text or LCNAF (Library of Congress Name Authority File), which could be helpful for formulating corporate names.

DC.Contributor.PersonalName.Address
DC.Contributor.CorporateName.Address

Addresses of contributors. Includes any type of address. An email address or URL is preferred and should always be included if possible.
Optional, Free Text*, URL, Email

Examples:

DC.Contributor.PersonalName Jarvis, Helen
DC.Contributor.PersonalName.Address h.jarvis@unsw.edu.au [Email]
DC.Contributor.PersonalName.Address http://www.unsw.edu.au/~jarvis [URL]


7. DC.Date

DC.Date *

Date of creation or availability of the resource.
Mandatory, Non-repeatable, ISO 8601*, Free Text

Sub-elements of DC.Date, as listed below, may be used as required for more specific information
Optional, Non-repeatable, ISO 8601*, Free Text

Resource Origination:

DC.Date.Created
DC.Date.DataGathered

DC.Date.Valid (includes verification)

DC.Date.LastModified

Resource Release:

DC.Date.Issued

DC.Date.Available

Resource Transfer:

DC.Date.Accepted

DC.Date.Acquired

Notes:

Provide all significant dates associated with the creation of the resource, or its being made available in its present form. Use slash ( / ) to specify a range of dates (e.g. 1992 / 1996).

Use DC.Coverage.t.min, DC.Coverage.t.max or DC.Coverage.PeriodName for dates relating to the content of the resource (i.e. the historical time period covered by the information within the resource).

The date can be a single date or a range of dates. ISO 8601 uses the format YYYY-MM-DD. Show a range by using ‘/ ’.

Examples:

DC.Date 1997-12-03 [ISO8601]
DC.Date 1975/1979 [ISO8601]


8. DC.Type

DC.Type

The type of resource, used to categorise the resource being described. Repeat for all types included in the resource.
Mandatory, DC.Type List

Notes: The resource must be classified according to one of the major types listed below. Additional values specifying the type in more detail may be entered as repeats of the DC.Type entry, using Free Text.

List of allowable values for DC.Type:

Dataset: Alphanumeric collections of data. Examples include spatial data, bibliographic records, statistics, and remotely sensed spectral data. We anticipate that most ECAI datasets will fall into this category.

Text: A work that is mostly textual in nature, but may include images, maps, tables or other formats. Examples include books, articles, pamphlets, essays, email messages, theses, and technical reports.

Image: Examples: photograph, graphic, animation, video.

Sound: All sound types. Examples include speech, music, and ambient.

Software: Binary executables and source code. For software that exists only to create an interactive environment use Interactive instead.

Interactive: A setting designed for interactive involvement with one or more users. Examples: games, chat services and virtual reality.

Event: Non-persistent, time-based occurrence.

Physical Object: Objects or substances.

Examples:

DC.Type Dataset [DC.Type list]
DC.Type Text [DC.Type list]

DC.Type.Specific

A more detailed breakdown of type, using sub-categories such as Dataset.Spatial, Dataset.Numeric, Dataset.Spectral, Dataset.Statistical, Text.Homepage.Organizational
Optional, Free Text (?? Is there an authoritative list on WWW??)

Examples:

DC.Type.Specific Dataset.Spatial
DC.Type.Specific Text.Homepage.Organizational


9. DC.Format

DC.Format

The data representation of the resource. e.g. text, image, application
Mandatory, DC.Format List

Notes: There is some overlap in terms used for DC.Format and DC.Type. DC.Type describes the general nature or genre of the resource (e.g. textual ("text"), data ("dataset"), picture ("image")) while DC.Format describes the actual format in which it is stored (e.g. text file ("text"), image file ("image"), software application ("application")). Other categories which are first level terms in the IMT (Internet Media Types) list include multipart, message, audio, video and model. Additional entries added by ECAI are WWW pages (static), WWW pages (database/dynamic), TimeMap dataset, other spatial datasets and SQL server datasets.

Example: DC.Format text [DC.Format List]

DC.Format.Specific

A more detailed specification of the format of the resource, down to specific image formats, software applications etc.
Optional, IMT*, AAT

Scheme: The IMT scheme is a standardised list of Internet Media Types (formerly MIME types). An authoritative list can be downloaded from:

ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/media-types

Notes: 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 (for example what hardware and software might be required to display or execute it).

Example: DC.Format.Specific text/html [IMT]

DC.Format.Size

The approximate size of the resource expressed in storage units or item/record count.
Optional, Itemcount*, Kbytes

Notes: This element is used as a general indication of dataset size. Itemcount (rdataset records) is the preferred scheme because storage size is highly dependant on resolution of images and on storage method - a substantial database of textual data can be smaller than a single high-resolution image.

Example:

DC.Format.Size 17000 [Itemcount]


10. DC.Identifier

DC.Identifier

String or number used to uniquely identify the resource
Optional, URL *, URN, ISBN, ISSN, SICI, FPI, Free Text

Notes: Examples for networked resources include URLs and URNs (when implemented), and other globally unique identifiers, such as ISBN.

Schemes: URL (Uniform Resource Locator) ; URN (Uniform Resource Name) ; ISBN (International Standard Book Number) ; ISSN (International Standard Serial Number); SICI (Serial Item and Contribution Identifier) ; FPI (Formal Public Identifier) ; and Free Text (For local number; Publisher’s number, Series etc.).

Example:

DC.Identifier http://www.ias.berkeley.edu/ecai/ [URL]


11. DC.Source

DC.Source

The work, either print or electronic, from which this resource is derived.
Optional, Free Text

Notes: For example, an html encoding of a Shakespearean sonnet might identify the paper version of the sonnet from which the electronic version was transcribed. This element should be repeated for the original source.

Example:

DC.Source Shakespeare, William. The Tempest. London : N. Blackall & Sons, 1937.

DC.Source Shakespeare, William. The Tempest. London: Ian Laggart & Ed Blount, 1623.


12. DC.Language

DC.Language

Language of the intellectual content of the resource
Mandatory, ISO 639-2B-Subset*, ISO 639-2B, Free Text

Example: DC.Language eng [ISO639-2]

Notes: We have defined a subset of around 20 languages most likely to be used by ECAI members in the creation of databases as ISO639-2B-Subset. This subset will be added to as required. If the language used is not in the subset, change the scheme to ISO639-2B and enter the appropriate 3-letter code.


13. DC.Relation

DC.Relation.Type
DC.Relation.Identifier

Provides a means to express relationships among resources that have formal relationships, but exist as discrete resources themselves, such as images in a document, chapters in a book, or items in a collection. ALWAYS USE TOGETHER.
Optional, DC.Relation.Type List
Optional, Free Text*, URL, URN, ISBN

Schemes:

Standard relationship types:

IsPartOf, HasPart, IsVersionOf, HasVersion, IsFormatOf, HasFormat, References, IsReferencedBy, IsBasedOn, IsBasisFor, Requires, IsRequiredBy

Notes:

Relationships include::

Historical:

Creative (translation, annotation)
Mechanical (copy, format change, mirror copy)
Versions (edition, draft)

Part/Whole:

Inclusions (collection, part)

References:

Citations (bibliographic citations, acknowledges)

Dependency:

Physical (software or hardware dependency)

Ideotypical

Example:

DC.Relation.Type IsPartOf
DC.Relation.Identifier http://www.yale.edu/cgp/


14. DC.Coverage

ECAI requires the extent of the resource or dataset to be defined by a bounding box (or "space-time cube") consisting of minimum and maximum longitude (x) and latitude (y) values, and a minimum and maximum time/date (t).

If the resource is of worldwide coverage with no date limitation, then assign the values –180 to 180 for the longitude and –90 to 90 for the latitude extent of coverage. For place names or countries, consult the web search databases of the Getty Thesaurus of Geographic Names, German Space Operations Centre or list of country bounding boxes.

In order to simplify searching, ECAI limits the coverage metadata to a single bounding box by making these elements non-repeatable. If the dataset covers an irregular area which cannot be adequately represented by a bounding box (e.g. the coastline of China) or more than one distinct geographic area (e.g. the British Commonwealth), you may wish to register more than one record in the Metadata Clearinghouse. For example, where a dataset covers both South and Southeast Asia, you may either register separate records for each area, or you may give the inclusive bounding box for both regions in one record.

Dublin Core defines DC.Coverage.z, polygon, line & 3D elements to allow a more precise definition of the space-time extent of a dataset, but these are felt to be unnecessary for ECAI at present.

DC.Coverage.x.min (Longitude of W edge)
DC.Coverage.x.max
(Longitude of E edge)
DC.Coverage.y.min (Latitude of S edge)
DC.Coverage.y.max (Latitude of N edge)

Limits of bounding box on the earth’s surface which circumscribes the dataset
Mandatory, Non-repeatable, LatLong*, WGS84-DDM

Schemes: LatLong is a decimal degrees latitude/longitude value whose parameters are unspecified. WGS84-DDM is a standard Dublin Core scheme for latitude/longitude recorded to the WGS84 ellipsoid in decimal degrees. In practice, differences in ellipsoid are so small as to be generally irrelevant for the kinds of regional datasets indexed by ECAI. Note that values must be in decimal degrees, not minutes and seconds.

DC.Coverage.t.early (Earliest date)
DC.Coverage.t.late
(Latest date – closest to present)

Limits of temporal coverage of the dataset
Mandatory, Non-repeatable, CE*, BCE, BP

Schemes: CE (Common Era), BCE (Before Common Era), BP (Before Present)

Notes: Give your best estimate if the precise dates are not known.

Example (The Roman Empire):

DC.Coverage.x.Min -10 DC.Coverage.x.Max 42 DC.Coverage.y.Min 20 DC.Coverage.y.Max 60
DC.Coverage.t.Min 753 [BCE]
DC.Coverage.t.Max 476 [CE]

DC.Coverage.PeriodName

Historical or archaeological period(s) represented in the resource.
Optional, Free Text

Note: ECAI will declare preferred systems of periodisation to make this element more useful for searches. In the meantime its use is encouraged, using conventional nomenclature accepted by the majority of workers in a particular field.

DC.Coverage.PlaceName

Areal coverage or major locations covered in the dataset, for example regions, countries or cities.
Optional, TGN*, Free Text

Scheme: TGN (Getty Thesaurus of Geographic Names)

Notes: Please try to find the most appropriate geographic name(s) for your resource from the TGN web site (Error! Reference source not found.). Give Free Text forms for variant names which might be relevant to researchers familiar with the area.


DC.Coverage Extensions

ECAI has added the following Sub-elements to the DC.Coverage element to allow a more precise definition of the nature of the spatial and temporal data in the resource, and the mode of its collection.

DC.Coverage.Spatial.Resolution

Resolution of a map or digital position recording (e.g. GPS) is the ground-distance between points or features which can be distinguished, recorded in metres.
Optional, Numeric value (in metres)

For directly recorded coordinates, such as GPS, resolution simply reflects the minimum coordinate difference which can be consistently recorded (often 1m for backpack units, 2 - 5m for medium grade handhelds and 15m for budget hand-helds).

On a printed map, resolution is roughly the size/width of the smallest symbol/line on the map, normally about 0.1mm - typical resolutions for different map scales, based on this, are listed below:

Printed map scale Resolution (metres)
1:10,000 1
25,000 2.5
50,000 5
63,360 (1"/mile) 6
100,000 10
250,000 25
1,000,000 100
5,000,000 500

Notes: Scale/resolution indicates the amount of detail that is contained within a map. The larger the scale at which a map is constructed, the higher the resolution and the more detail which can be recorded. The intended use of a map often determines its scale. Inaccurate locational information is obtained if one zooms a digital map to a scale larger than that at which the map was composed/digitised.

Note that resolution does not necessarily relate to accuracy. A map at 1:10,000 may show objects which are a metre apart, but the geographic location, and even the relative positions, of the symbols may be wildly innacurate.

Example:

DC.Coverage.Spatial.Resolution 2.5 (1:25K map)
DC.Coverage.Spatial.Resolution 1 (High-grade GPS)

DC.Coverage.Spatial.Aggregation

The geography by which the data is aggregated, for example U.S. Census Bureau data is aggregated by census tract. Another example - data that indicates the population of each Chinese province would have the aggregation value of ‘Province’.
Optional, Spatial_Units

Examples:

DC.Coverage.Spatial.Aggregation Census tract
DC.Coverage. Spatial.Aggregation Province
DC.Coverage. Spatial.Aggregation Zipcode

DC.Coverage.Spatial.Georeference

The geography(ies) by which individual data records are tagged indicating the granularity of the data. For example, places of worship may be tagged by the state, province, county, and/or census tract in which they are located. A specific example - if a dataset of Chinese and Indian temples contains a field which indicates which of these two countries the temples are located, the georeference would be ‘Country’.
Optional, Spatial_Units

Examples:

DC.Coverage.Spatial.Georeference Census tract
DC.Coverage.
Spatial.Georeference Province
DC.Coverage
.Spatial.Georeference Country

DC.Coverage.Temporal.Resolution

Resolution of temporal data (date values) is the smallest interval between two events/features/dates which can be distinguished, recorded in years.
Optional, Numeric value (years)

Notes: For many historical datasets, temporal resolution will be by year, but more recent data could have resolutions down to days, hours or even minutes for specific events. At this stage we have decided to allow fractional years rather than defining additional schemes. It is suggested that for convenience, months be recorded as 0.1 years, days as 0.01 years, hours as 0.0001 years and minutes as 0.000001 (it is unlikely that all data in a dataset will be recorded with identical resolution and these values are close-enough estimates for the purpose of searching).

DC.Coverage.Temporal.Interval

The time interval at which the data is collected. For example, U.S. Census data is collected every decade. This sub-element does not indicate whether the dataset represents a snapshot in time or whether it is a count or average for a specific time period. The DC.Coverage.Scale.Temporal.Aggregation sub-element described below addresses the issue of time period for which data is aggregated.
Optional, Numeric value (years)

DC.Coverage.Scale.Temporal.Interval 1 (Annual figures)
DC.Coverage.Scale.Temporal.Interval 10 (Figures by decade)

Notes: This sub-element has been proposed because it helps to define the relationship of the dataset to others in a series. See notes under DC.Coverage.Temporal.Resolution for treatment of intervals less than 1 year.

DC.Coverage.Temporal.Aggregation

The temporal scale at which the data is aggregated. For example, a dataset may contain a count of births for a year or a count for a decade.
Optional, Numeric value (years)

DC.Coverage.Scale.Temporal.Aggregation 1 (Annual figures)
DC.Coverage.Scale.Temporal.Aggregation 10 (Figures by decade)

Notes: If a datasets represents averages by time periods versus counts, this sub-element also applies. See notes under DC.Coverage.Temporal.Resolution for treatment of intervals less than 1 year.

DC.Coverage.AlternativeMetadata

The web address where a more detailed metadata report, such as an FGDC report, related to the dataset may be found or the email address to which users can email requests for additional metadata.
Optional, URL*, Free Text

Notes: This sub-element will provide access to the more detailed metadata required by some data users.

Examples:

DC.Coverage.OtherMetadata http://www.xpcgeo.edu/metadata/ds1.html
DC.Coverage.OtherMetadata kfrederi@iupui.edu

DC.Coverage.Notes

Additional information related to the coverage characteristics and development history of the data.
Optional, Free Text

Example:

DC.Coverage.Notes The information in this dataset was ….


15. DC.Rights

DC.Rights

Rights management. The terms and conditions or copyright statements for the resource or collection of resource. Provides textual information or a link to a copyright notice, a rights-management statement, or a server that provides such information in a dynamic way.
Optional, Free Text*, URL, URN

Examples:

DC.Rights Public domain
DC.Rights http://www.yale.edu/cgp/copy.htm [URL]


ECAI-Specific Metadata Elements


16. ECAI.Team

ECAI.Team

The ECAI team responsible for collecting the dataset or overseeing its incorporation into ECAI.
Mandatory, Ecai_Teams

Scheme: Controlled list of ECAI teams (China, Silk Road, Korea, … see metadata clearinghouse and ECAI web site for authoritative list).

Examples:

ECAI.Team Silk Road


17. ECAI.Theme

The ECAI theme is used as an overall classification of datasets, particularly when browsing for resources of interest. A dataset may fall into more than one theme.

ECAI.Theme

The thematic domain(s) covered by the dataset.
Mandatory, Ecai_Themes

Scheme: Controlled list of ECAI themes (Archaeology, Art, Religion, … see metadata clearinghouse for authoritative list).

Examples:

ECAI.Theme Religion
ECAI.Theme Art


18. ECAI.Notes

This Element has been added by ECAI as Dublin Core provides no satisfactory elements for a general description of background information about the resource.

ECAI.Notes

Additional information about the resource being described.
Optional, Free text

Notes: DO NOT use as a replacement for recording adequate information in other more specific metadata elements.

Examples:

ECAI.Notes This dataset is under construction. It is envisaged that it will be fully available by February 1999.


19. ECAI.UseRestrictions

ECAI.UseRestrictions <<Not yet implemented in clearinghouse>>

Defines the level of access permitted to the data through the ECAI data browser
Optional, Use_categories

Notes:

    1. No restrictions. All data in the dataset can be displayed and/or downloaded;
    2. Licensed. A sample of the data can be displayed and/or downloaded. Full download requires payment of a licence fee and supply of an unlocking code by the data owners;
    3. Restricted. Only the dataset structure and record count can be shown. Access to the data will require supply of an unlocking code by the data owners.


20. ECAI.Content

ECAI.ContentType <<Not yet implemented in clearinghouse>>

Describes the nature of the material available in the dataset.
Optional, Content_Type

Notes:

    1. Data rich. Typically direct access to a database or searchable database-driven web site. For example, the Chinese Biographical Database web site and any directly-accessed TimeMap datasets;
    2. Synthesis. Typically a significant web site which synthesises information about a topic. For example, the TimeMap Project home page;
    3. Links. A site which is primarily characterised as a jumping-off point to other sites of interest. For example, the ECAI home page;
    4. Other. Any site not falling into the above categories. In practice we do not expect that datasets falling into this category will be indexed by ECAI.


21. ECAI.Expert

ECAI.Expert.Commentary

Authoritative comments for public viewing written by the ECAI team editor or other ECAI expert on the quality, validity, usefulness etc. of the resource.
Optional, Free Text

Notes: Data can only be entered/altered by the ECAI team editors or their delegates.

Examples:

ECAI.Expert.Commentary This is an outstanding resource of the highest quality, which will be of interest to all serious scholars of Buddhist texts

ECAI.Expert.InternalNotes

Authoritative notes from the ECAI team editor or other ECAI expert on the quality, validity, usefulness etc. of the resource. For internal use only.
Optional, Free Text

Notes: Data can only be entered/altered by the ECAI team editors or their delegates and is not visible to public searching of the metadata clearinghouse.

Examples:

ECAI.Expert.InternalNotes This is a crank dataset - do not publish.


References

This document contains ideas, extracts and summaries from the following:

Dublin Core qualifiers/substructure / R. Guenther - 15 Oct 97
<http:/www.loc.gov/marc/dcqualif.html>

Dublin Core Resource Types Minimalist DRAFT: July 17, 1997
< http://sunsite.Berkeley.edu/Metadata/minimalist.html>

Resource Types for Simple Dublin Core. WD-DCTYP-981023

<http://www.agcrc.csiro.au/3018CO/metadata/DC-tf/type_simple.html>

A user guide for simple Dublin Core - Draft version 5 - 1 June 98
<http://128.253.70.110/dc5/userguide5.html>

User Guidelines for Dublin Core Creation / Nordic Metadata Project
Version 1.0 1997-05-29, Last update : 1998-01-16.
<http://linnea.helsinki.fi/meta/>


School of Archaeology Home Top of this page

School of Archaeology, University of Sydney NSW 2006, Australia. +61-2-9351-2364/6394/fax 6392
Web site maintained on the
Archaeological Computing Laboratory server +61-2-9351-3142
Content of web pages developed by individuals in their home directories is outside the control of the School of Archaeology and no responsibility is taken for this material.
Copyright 1997, 1998 School of Archaeology, University of Sydney, except for individual user pages, or where indicated.
Developed by
Ian Johnson assisted by Elizabeth Black & Fiona Lim