Resource Discovery Network

RDN cataloguing guidelines

Michael Day and Peter Cliff, UKOLN, University of Bath
Version 1.1

1. Introduction

Cataloguing guidelines ensure that there is a minimum level of consistency between descriptions that need to be cross-searched; records which are exported to other services; and in the interest of wider interoperability. These guidelines are not meant to replace the fuller guidelines in place at the Hubs, rather they represent a pragmatic step towards increasing the value of the records at those points where interoperability is important - cross searching/browsing, unified presentation, sharing records, etc. It is also hoped they will provide some guidance to new Hubs.

This version of the RDN Cataloguing Guidelines is based on three separate documents:

This revision also takes into account existing guidelines at SOSIG [4] and BIOME [5] and comments from the RDN Interoperablity WG.

For each Dublin Core element, the authoritative definitions and comments from the Dublin Core v. 1.1 reference description have been included, together with basic mappings from the SERVICE, DOCUMENT and RESOURCE template-types used by ROADS.

The Dublin Core described here is essentially the unqualified Dublin Core sometimes known as DC Simple. However, it has not been possible to omit completely any mention of DC qualifiers. A variety of DC working groups - the work of some of which are mentioned here - are addressing issues relating to qualifiers and much of their (on going) discussion will be relevant in this context.

It is important to realise that in the RDN context, it may be more important to ensure consistency across a defined sub-set of the Dublin Core elements rather than over all fifteen elements. This should primarily be related to ensuring consistent searching and browsing, and with the format of information displayed to users. For example, cross-searches of the RDN hubs might typically only retrieve the values of Title, Description, Subject (for keywords) and Identifier (or URI).

Finally, it is envisaged that a later version of these guidelines might include information about sources of information, and enumerated lists of relevant element qualifiers, value qualifiers and their interpretation.

Hubs are strongly recommended to support following minimal set identified by the RDN Interoperablility WG:

Internal RDN record sharing: RDN hubs should use the RDN OAI rdn_dc XML schema(s) [6] to encode metadata records for exchange between RDN partners using the OAI-PMH.

RDN4FE: RDN records targetted at FE should also conform to the FE Addendum to these guidelines [7].

RDN/LTSN partnerships: for RDN/LTSN partnership activities, RDN hubs should also conform to the RDN/LTSN LOM application profile [8].

Admin metadata: in order to maintain and share consistent metadata about RDN records, RDN hubs should conform to the RDN admin metadata guidelines [9].

Z39.50: Note that the Bath Profile Release 1.0 [10] (Functional Area C - Cross-Domain Search and Retrieval - Levels 0 and 1) requires cross-domain searches on Creator, Title and Subject attributes. However, because Creator is not part of the minimal element set, RDN Z39.50 targets may be configured to always return zero results for Creator searches.


2. The Elements

* indicates that an element is part of the minimal set.

Title *

Transcribe the title preserving the original wording, order and spelling. Either only capitalize proper nouns or: Capitalize titles. The former is in accordance with AACR2 [11] and is preferred. The latter is to ensure conformance of existing records. Punctuation need not reflect the usage of the original. Subtitles should be separated from the title by <space>colon<space>, e.g.:

Hungary's revolution : forty years on

DC Label:

Title

DC Name:

dc:title

DC Definition:

A name given to the resource.

DC Comment

Typically, a Title will be a name by which the resource is formally known.

ROADS RESOURCE:

Title:

ROADS SERVICE:

Title:

ROADS DOCUMENT:

Title:

Creator

Enter personal names, where possible, in the order suggested by AACR2 [11] chapter 22 for headings of persons, i.e. the entry element should be that part of the name under which the person would normally be listed in authoritative alphabetic lists in his or her language or country of residence or activity (rule 22.4A). Separate other elements with a comma, e.g.:

Collinson, Patrick
Gould, Stephen Jay
Hoskins, W.G.
Ng, Tze Beng

Enter corporate names, where possible, in the order suggested by AACR2 [11] chapters 24 for headingds for corporate bodies. In general (rule 24.1) this means entering a corporate body under the name by which it is commonly identified, except when the rules provide for entering it under the name of a higher or related body or the name of a government, e.g.:

Bodleian Library
British Broadcasting Corporation
Loughborough University. Department of Computer Science
United Kingdom. Department for Education and Employment

The inclusion of personal and corporate name headings from authority lists constructed according to AACR2, e.g. the Library of Congress Name Authority File (LCNA), is also acceptable.

DC Label:

Creator

DC Name:

dc:creator

DC Definition:

An entity primarily responsible for making the content of the resource.

DC Comment:

Examples of a Creator include a person, an organisation, or a service. Typically, the name of a Creator should be used to indicate the entity.

ROADS RESOURCE:

Author-Name-v*:
Author-Email-v*:

ROADS SERVICE:

[No equivalent]

ROADS DOCUMENT:

Author-Name-v*:

Subject *

For keywords either enter terms as free-text with a semi-colon separating each keyword; or as multiple (repeating/variant) fields. There are no requirements regarding the capitalization of keywords though internal (within Hub) consistancy is recommended. The RDNC can provide scripts to convert records that use alternate separators, eg. commas.

Where terms are taken from a standard subject scheme: enter a shortened version of the scheme used as a value qualifier and then enter the term/s. The shortened version of the scheme used should be taken from this enumerated list

The value(s) consist(s) of the subject term(s).

Transcribe complete subject descriptor according to the relevant scheme. Use the punctuation and capitalisation used in the original scheme, for example:

LCSH: World War, 1939-1945 - Germany
LCSH: Germany - History - 1933-1945
LCSH: Hitler, Adolf, 1889-45
DDC21: 940.43

DC Label:

Subject and Keywords

DC Name:

dc:subject

DC Definition:

The topic of the content of the resource.

DC Comment:

Typically, a Subject will be expressed as keywords, key phrases or classification codes that describe a topic of the resource.
Recommended best practice is to select a value from a controlled vocabulary or formal classification scheme.

ROADS RESOURCE:

Keywords:
Subject-Descriptor-v*:
Subject-Descriptor-Scheme-v*:

ROADS SERVICE:

Keywords:
Subject-Descriptor-v*:
Subject-Descriptor-Scheme-v*:

ROADS DOCUMENT:

Keywords:
Subject-Descriptor-v*:
Subject-Descriptor-Scheme-v*:

Description *

Free-text description of resource in the context of the describing Hub.

We recommend the following description structure:

  • Describe the nature of the resource e.g. an electronic journal, collection of reports, etc.
  • If appropriate, describe who is providing the resource - author, organization, etc.
  • Describe the subject coverage / content of the resource
  • Describe any geographical or temporal limits
  • Describe any form or process of use - is there a charge? do you need to register? are there any software requirements?
  • Describe if the resource is available in other languages

[18]

DC Label:

Description

DC Name:

dc:description

DC Definition:

An account of the content of the resource.

DC Comment:

Description may include but is not limited to: an abstract, table of contents, reference to a graphical representation of content or a free-text account of the content

ROADS RESOURCE:

Description:

ROADS SERVICE:

Description:

ROADS DOCUMENT:

Description:

Publisher

Enter personal names, where possible, in the order suggested by AACR2 [11] chapter 22 for headings of persons, i.e. the entry element should be that part of the name under which the person would normally be listed in authoritative alphabetic lists in his or her language or country of residence or activity (rule 22.4A). Separate other elements with a comma, e.g.:

Collinson, Patrick
Gould, Stephen Jay
Hoskins, W.G.
Ng, Tze Beng

Enter corporate names, where possible, in the order suggested by AACR2 [11] chapters 24 for headingds for corporate bodies. In general (rule 24.1) this means entering a corporate body under the name by which it is commonly identified, except when the rules provide for entering it under the name of a higher or related body or the name of a government, e.g.:

Bodleian Library
British Broadcasting Corporation
Loughborough University. Department of Computer Science
United Kingdom. Department for Education and Employment

The inclusion of personal and corporate name headings from authority lists constructed according to AACR2, e.g. the Library of Congress Name Authority File (LCNA), is also acceptable.

DC Label:

Publisher

DC Name:

dc:publisher

DC Definition:

An entity responsible for making the resource available.

DC Comment:

Examples of a Publisher include a person, an organisation, or a service.
Typically, the name of a Publisher should be used to indicate the entity.

ROADS RESOURCE:

Publisher-Name-v*:

ROADS SERVICE:

Publisher-Name-v*:

ROADS DOCUMENT:

Publisher-Name-v*:


Contributor

Enter personal names, where possible, in the order suggested by AACR2 [11] chapter 22 for headings of persons, i.e. the entry element should be that part of the name under which the person would normally be listed in authoritative alphabetic lists in his or her language or country of residence or activity (rule 22.4A). Separate other elements with a comma, e.g.:

Collinson, Patrick
Gould, Stephen Jay
Hoskins, W.G.
Ng, Tze Beng

Enter corporate names, where possible, in the order suggested by AACR2 [11] chapters 24 for headingds for corporate bodies. In general (rule 24.1) this means entering a corporate body under the name by which it is commonly identified, except when the rules provide for entering it under the name of a higher or related body or the name of a government, e.g.:

Bodleian Library
British Broadcasting Corporation
Loughborough University. Department of Computer Science
United Kingdom. Department for Education and Employment

The inclusion of personal and corporate name headings from authority lists constructed according to AACR2, e.g. the Library of Congress Name Authority File (LCNA), is also acceptable.

DC Label:

Contributor

DC Name:

dc:contributor

DC Definition:

An entity responsible for making contributions to the content of the resource.

DC Comment:

Examples of a Contributor include a person, an organisation, or a service.
Typically, the name of a Contributor should be used to indicate the entity

ROADS RESOURCE:

Contributor-Name-v*:

ROADS SERVICE:

Admin-Name-v*:
Owner-Name-v*:
Sponsoring-Name-v*:

ROADS DOCUMENT:

Admin-Name-v*:


Date

Either: Dates should be entered in ISO 8601:1988 [12] format. The following examples are all valid dates:

1999
1999-12-25
1999-12-25T19:20:30.45+01:00

Or: Dates should be entered in a consistent format that can quickly and easily be converted for external (cross-searching, etc.) presentation.

DC Label:

Date

DC Name:

dc:date

DC Definition:

A date associated with an event in the life cycle of the resource.

DC Comment:

Typically, Date will be associated with the creation or availability of the resource. Recommended best practice for encoding the date value is defined in a profile of ISO 8601 [12] and follows the YYYY-MM-DD format.

ROADS RESOURCE:

[No direct quivalent]

ROADS SERVICE:

[No direct equivalent]

ROADS DOCUMENT:

[No direct equivalent]

Note:

The RDNC could provide the conversion tools to facilitate data exchange between: IAFA [13],ISO 8601 [12] and proprietry formats where possible.

Type *

Resource type should be a value selected from either DCMIType or RDNType[14]. Multiple terms should be separated by a semi-colon ';' or be put in repeated attributes.

DC Label:

Resource Type

DC Name:

dc:type

DC Definition:

The nature or genre of the content of the resource.

DC Comment:

Type includes terms describing general categories, functions, genres, or aggregation levels for content. Recommended best practice is to select a value from a controlled vocabulary (for example, the working draft list of DCMI Type Vocabulary [15]. To describe the physical or digital manifestation of the resource, use the FORMAT element.

ROADS RESOURCE:

Category:

ROADS SERVICE:

Category:

ROADS DOCUMENT:

Category:

Note:

As with "subject" it would be useful to maintain a Web site that records Hub Type Lists.

Format

Recommended best practice is to select a term from IANA [16] registered list of Internet Media Types (or MIME types).

DC Label:

Format

DC Name:

dc:format

DC Definition:

The physical or digital manifestation of the resource.

DC Comment:

Typically, Format may include the media-type or dimensions of the resource. Format may be used to determine the software, hardware or other equipment needed to display or operate the resource. Examples of dimensions include size and duration Recommended best practice is to select a value from a controlled vocabulary (for example, the list of Internet Media Types (MIME) defining computer media formats (IANA [16]).

ROADS RESOURCE:

Format-v*:

ROADS SERVICE:

[No equivalent]

ROADS DOCUMENT:

Format-v*:
Character-Set-v*:


Identifier (URI*)

When the resource has an URI, enter the complete string with regard to correct spelling, punctuation and capitalisation. For example:

http://www.lib.cam.ac.uk/Taylor-Schechter/

Where other identifiers are present, their presence should be noted using a DC value qualifier (scheme), possibly taken from an enumerated list.

DC Label:

Resource Identifier

DC Name:

dc:identifier

DC Definition:

An unambiguous reference to the resource within a given context.

DC Comment:

Recommended best practice is to identify the resource by means of a string or number conforming to a formal identification system.
Example formal identification systems include the Uniform Resource Identifier (URI) (including the Uniform Resource Locator (URL), the Digital Object Identifier (DOI) and the International Standard Book Number (ISBN)).

ROADS RESOURCE:

URI-v*:

ROADS SERVICE:

URI-v*:
ISBN-v*:
ISSN-v*:

ROADS DOCUMENT:

URI-v*:
ISBN-v*:
ISSN-v*:


Source

Free-text description of the original version of a resource.

DC Label:

Source

DC Name:

dc:source

DC Definition:

A Reference to a resource from which the present resource is derived.

DC Comment:

The present resource may be derived from the Source resource in whole or in part. Recommended best practice is to reference the resource by means of a string or number conforming to a formal identification system

ROADS RESOURCE:

Source:

ROADS SERVICE:

Source:

ROADS DOCUMENT:

Source:


Language *

Use the language codes defined in RFC 3066 [17], for example: 

<dc:language>en-GB</dc:language>

DC Label:

Language

DC Name:

dc:language

DC Definition:

A language of the intellectual content of the resource.

DC Comment:

Recommended best practice is to use RFC 3066 [17] which, in conjunction with ISO639 [18]), defines two- and three primary language tags with optional subtags. Examples include "en" or "eng" for English, "akk" for Akkadian", and "en-GB" for English used in the United Kingdom.

ROADS RESOURCE:

Language-v*:

ROADS SERVICE:

Language:

ROADS DOCUMENT:

Language-v*:

Note:

The RDNC could provide tools to convert records that use other formats to ISO 639-2:1998.

Relation

Where the resource being described is a JISC collection or is part of a JISC collection, enter the following URI:

http://www.jisc.ac.uk/collections/

DC Label:

Relation

DC Name:

dc:relation

DC Definition:

A reference to a related resource.

DC Comment:

Recommended best practice is to reference the resource by means of a string or number conforming to a formal identification system.

ROADS RESOURCE:

Relation:

ROADS SERVICE:

[No equivalent]

ROADS DOCUMENT:

[No equivalent]


Coverage

The coverage of the content of the resource or a term taken from an existing controlled vocabulary has been used (e.g. the Getty Thesaurus of Geographic Names [22]), enter a shortened version of the scheme used as a value qualifier (e.g. TGN) and then enter the term/s. Where more than one term is used, a new element should be used for each one. The shortened version of the scheme used should be taken from an enumerated list.

Either: free-text field, or: selected from a list.

DC Label:

Coverage

DC Name:

dc:coverage

DC Definition:

The extent or scope of the content of the resource.

DC Comment:

Coverage will typically include spatial location (a place name or geographic co-ordinates), temporal period (a period label, date, or date range) or jurisdiction (such as a named administrative entity).
Recommended best practice is to select a value from a controlled vocabulary (for example, the Getty Thesaurus of Geographic Names [22] or TGN) and that, where appropriate, named places or time periods be used in preference to numeric identifiers such as sets of co-ordinates or date ranges.

ROADS RESOURCE:

Coverage:

ROADS SERVICE:

[No equivalent]

ROADS DOCUMENT:

[No equivalent]


Rights

A free-text statement about the rights held in and over the resource or the URI of such a statement.

DC Label:

Rights Management

DC Name:

dc:rights

DC Definition:

Information about rights held in and over the resource.

DC Comment:

Typically, a Rights element will contain a rights management statement for the resource, or reference a service providing such information. Rights information often encompasses Intellectual Property Rights (IPR), Copyright, and various Property Rights.
If the Rights element is absent, no assumptions can be made about the status of these and other rights with respect to the resource.

ROADS RESOURCE:

Copyright:

ROADS SERVICE:

Access-Policy:

ROADS DOCUMENT:

Copyright:


Maintainer

The email address (encoded as a mailto: URI) or Web page of the administrator of the site or resource being described.

RDN Label:

Maintainer

RDN Name:

rdnterms:maintainer

RDN Definition:

The email address (encoded as a mailto: URI) or Web page of the administrator of the site or resource being described.

RDN Comment:

 

ROADS RESOURCE:

 

ROADS SERVICE:

 

ROADS DOCUMENT:

 

References

  1. Dublin Core Metadata Initiative, 1999, Dublin Core Metadata Element Set, Version 1.1: Reference Description. Dublin Core Metadata Initiative.
    <http://dublincore.org/documents/dces/>

  2. Day, M., 1997, Mapping Dublin Core to ROADS templates. Bath: UKOLN: The UK Office for Library and Information Networking.
    <http://www.ukoln.ac.uk/metadata/interoperability/dc_iafa.html>

  3. Day, M., 1999, ROADS Cataloguing Guidelines, v. 1.0. Bath: UKOLN: The UK Office for Library and Information Networking.
    < http://www.ukoln.ac.uk/metadata/roads/cataloguing/cataloguing-rules.html>

  4. Hiom, D., 1999, SOSIG Cataloguing Rules.
    <http://www.sosig.ac.uk/about_us/docs/catrule.html>

  5. Gray, L., Cataloguing Rules for the BIOME Service: a Procedural Manual.
    <http://biome.ac.uk/guidelines/cat/>

  6. Powell, A., 2003, RDN OAI rdn_dc XML schema(s).
    <http://www.rdn.ac.uk/oai/rdn_dc/>

  7. Powell, A., 2003, RDN cataloguing guidelines - FE addendum.
    <http://www.intute.ac.uk/publications/cat-guide/fe-addendum/>

  8. Powell, A., 2003, RDN/LTSN LOM application profile.
    <http://www.intute.ac.uk/publications/rdn-ltsn-ap/>

  9. Powell, A., 2003, RDN admin metadata.
    <http://www.intute.ac.uk/publications/cat-guide/admin/>

  10. Lanau, Miller, Moen, (eds), 1999, The Bath Profile: An International Z39.50 Specification for Library Applications and Resource Discovery.
    < http://www.ukoln.ac.uk/interop-focus/activities/z3950/int_profile/bath/draft/stable1.html>

  11. AACR2 1998 rev., Anglo-American Cataloguing Rules, 1998 rev. Ottawa: Canadian Library Association; London: Library Association Publishing; Chicago, Ill.: American Library Association.

  12. ISO 8601:1988, Data elements and interchange formats - Information interchange - Representation of dates and times. Geneva: International Organization for Standardization (ISO).

  13. Deutsch, P., Emtage, A., Koster, M. and Stumpf, M., 1994, Publishing information on the Internet with Anonymous FTP. Internet-Draft.
    <http://aliweb.emnet.co.uk/iafa.txt>

  14. Cliff, P., 2000, RDN Resource Types (RDNType).
    <http://www.intute.ac.uk/publications/cat-guide/types/>

  15. DCMI Usage Board, 2003, DCMI Type Vocabulary.
    <http://dublincore.org/documents/dcmi-type-vocabulary/>

  16. Internet Assigned Numbers Authority, IANA registered Media Types [MIME types].
    < http://www.isi.edu/in-notes/iana/assignments/media-types/media-types>

  17. RFC 3066 Tags for the Identification of Languages
    <http://www.ietf.org/rfc/rfc3066.txt>

  18. ISO 639-2:1998, Codes for representation of names of languages -- Part 2: Alpha-3 code. Geneva: International Organization for Standardization (ISO).

  19. RFC 1766 Tags for the identification of languages.
    <http://www.ietf.org/rfc/rfc1766.txt>

  20. ISO 3166:1993, Codes for the representation of names of countries. Geneva: International Organization for Standardization (ISO).
    <http://www.oasis-open.org/cover/country3166.html>

  21. ISO 639:1988, Code for the representation of names of languages. Geneva: International Organization for Standardization (ISO).
    <http://www.oasis-open.org/cover/iso639a.html>

  22. Getty Research Institute, 1999a, Getty Thesaurus of Geographic Names, version 2.0 Web.
    <http://www.getty.edu/research/tools/vocabulary/tgn/>

Maintained by rdnc@rdn.ac.uk | Credits | Feedback
Copyright © 2003
Last updated: 10-Jul-2009