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_guideAbstract: 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_manualAbstract: 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
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 TextExamples:
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*, LCNAFNotes: 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.AddressIncludes 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, LCNAFNotes: 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 TextNotes: 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 TextNotes: 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, EmailExamples:
DC.Publisher Oxford University Press
DC.Publisher NSW National Parks and Wildlife ServiceDC.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*, LCNAFNotes: 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, EmailExamples:
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 TextSub-elements of DC.Date, as listed below, may be used as required for more specific information
Optional, Non-repeatable, ISO 8601*, Free TextResource Origination:
DC.Date.Created
DC.Date.DataGatheredDC.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 ListNotes: 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 ListNotes: 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*, AATScheme: 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*, KbytesNotes: 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 TextNotes: 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 TextNotes: 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 TextExample: 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, ISBNSchemes:
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-DDMSchemes: 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, BPSchemes: 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 TextNote: 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 TextScheme: 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 500Notes: 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 TextNotes: 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 TextExample:
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, URNExamples:
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_TeamsScheme: 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_ThemesScheme: 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 textNotes: 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:
- No restrictions. All data in the dataset can be displayed and/or downloaded;
- 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;
- 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_TypeNotes:
- 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;
- Synthesis. Typically a significant web site which synthesises information about a topic. For example, the TimeMap Project home page;
- Links. A site which is primarily characterised as a jumping-off point to other sites of interest. For example, the ECAI home page;
- 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 TextNotes: 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 TextNotes: 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