ROADS Cataloguing Guidelines

Draft (v. 0.1) by Michael Day, UK Office for Library and Information Networking (UKOLN), University of Bath.

1. Introduction

1.1 ROADS templates and interoperability

ROADS is typically used for the production of services which identify, evaluate, describe and give access to Internet resources for particular subject domains or geographical areas ROADS Templates are a metadata format based on Internet Anonymous FTP Archive (IAFA) templates which were published in an Internet-Draft in 1994 (Deutsch et al. 1994). ROADS templates are defined for different resource-types, e.g. for DOCUMENT, SERVICE or PROJECT. These templates consist of simple attribute-value pairs.

Attributes (or data-elements) used in ROADS services are listed and (briefly) defined in a ROADS Template Registry <URL:http://www.ukoln.ac.uk/roads/templates/>. The existence of this registry should mean that there will be no unnecessary proliferation of service-specific resource-types or attributes, thus helping ensure the on-going interoperability between different ROADS services.

The development of ROADS cataloguing guidelines is also connected to interoperability issues, and this relates to two specific areas:

1.1.1 Cross-searching ROADS databases

ROADS use of the WHOIS++ protocol means that (from Version 2 onwards) it will be possible to simultaneously search across more than one server. For example, a search could be made of both the Social Science Information Gateway (SOSIG) and the Organising Networked Medical Information (OMNI) servers for the term "alcohol". Some experiments with ROADS cross-searching (or Cross-ROADS) are available at: <URL:http://www.ilrt.bris.ac.uk/roads/cross/>. Adequate cross-searching between services will depend upon some common cataloguing standards, both with relation to HOW data elements are described and WHICH particular data elements are used. Cataloguing rules (or guidelines) can contribute to this process.

1.1.2 Semantic interoperability with other metadata formats.

The ROADS project is aware that it exists in an increasingly diverse metadata landscape. Different metadata formats are used (and will be used) for different resource types or subject domains. For example: the MARC family of formats are likely to continue to be important sources of metadata in library catalogues for many years to come. Although there may be some agreement on what constitutes 'core' resource-discovery metadata - the Dublin Core metadata element set fulfils this purpose admirably - it is likely that an increasing number of different metadata formats will co-exist into the foreseeable future. It will become important to facilitate semantic interoperability between these different formats. The production of mappings (or crosswalks) will have an important role in ensuring some level of interoperability between different metadata formats but the development of generic cataloguing standards will also be important. For example, preserving consistency with existing (library-based) resource-description standards like the International Standard Bibliographic Description (ISBD) or the Anglo-American Cataloguing Rules (AACR) may be one way of ensuring some form of interoperability with metadata in library catalogues.

This document is a draft version of some cataloguing guidelines (or rules) for these templates. Comments are welcomed on this version and the document (including this introduction) will be periodically updated.

1.2 Existing cataloguing rules for Internet resources

These cataloguing rules have been formulated with reference to current ROADS practice, the original IAFA document (Deutsch et al. 1994) and the following existing rules:

1.2.1 ISBD(ER)

The International Standard Bibliographic Description formats (co-ordinated by IFLA) are designed to provide a standard framework for the description of (mostly) bibliographic items: to identify sources of information; to provide a sequence of elements and relevant punctuation (Curwen 1991, p. 79). An ISBD for computer files was developed during the 1980s and a committee was appointed to revise this in 1994. The result is ISBD(ER),which was published in 1997. Descriptions using ISBD contain only descriptive data. Elements are included in one of the following areas:

• Title and statement of responsibility
• Edition
• Type and Extent of Resource
• Publication, distribution, etc.
• Physical description
• Series
• Note
• Standard number (or alternative) and terms of availability

Example: (ISBD(ER), p. 100 (slightly amended))

Electronic Beowulf [Electronic resource]. - Electronic
interactive multimedia. - [Great Britain?] : Electronic Beowulf
Project, cop. 1995.
Mode of access: World Wide Web. URL:
http://www.uky.edu/~kiernan/BL/kportico.html.
Title from title screen.
Digitised images developed by the British Library with Kevin
Kiernan and Paul Szarmach.
Summary: Introduction to the Electronic Beowulf Project including
images of the manuscript.

1.2.2 AACR2

AACR2 is probably the most widely used cataloguing code in the world. It was first published in 1978 and the descriptive part of the rules were formulated in accordance with the specifications of ISBD. In addition to this descriptive data, rules were also included for the inclusion of access points for authors (both individual and corporate) and uniform titles.

Example:

Migne, J.P. (Jacques Paul), 1800-1875

            Patrologia Latina Database / J.P. Migne. --
            Cambridge : Chadwyck-Healey, 1993. -- 2 computer
            laser optical disks ; 4 3/4 in. -- ISBN
            0-89887-113-1.

Chapter 9 of AACR2 1988 rev. gives rules for cataloguing Computer Files.

1.2.3 Nancy Olson's Cataloging Internet Resources

Nancy Olson's manual and practical guide to Cataloguing Internet resources was first published to support the OCLC InterCat project (Olson 1995). InterCat was partly funded to test the use of the USMARC 856 Electronic Location and Access field. Now a second edition of Olson's guide has been published (Olson 1997). The rules not only provide guidance on AACR2, but integrate the guidelines completely with OCLC MARC (a variant of USMARC) throughout the manual. The guidelines therefore provide rules for the USMARC 856 field and some comments on subject headings which are not part of AACR2.

Example: (Olson 1997, p. 37)

OCLC: 32103399      Rec stat: c 
Entered: 19950307   Replaced: 19960315   Used: 19950307
Type: m   ELvl: I   Srce: d   Audn:     Ctrl:   Lang: mul
BLvl: m   File: d   GPub:               MRec:   Ctry: dcu
Desc: a                       DtSt: m   Dates: 1995,9999 ¶

   1  040    UOK $c UOK ¶
   2  007    c $b r $d u $e n $f u ¶
   3  090    $b ¶
   4  049    ORDE ¶
   5  245 00 Worldnews online $h [computer file]. ¶
   6  246 3  World news online ¶
   7  256    Computer online service. ¶
   8  260    Washington, DC : $b Worldnews Online, $c [1995- ¶
   9  538    Mode of access: Internet. ¶
  10  500    Title from title frame. ¶
  11  520    "WorldNews OnLine is a service that brings newspapers
and news services from around the world to a global community of
multi-lingual people who need news from far away places ... our on-
line publications have full text of each day's edition on the same day
it appears in its local market. The papers may be accessed via any
World Wide Web client that supports user authentication." ¶
  12  650 0  Newspapers $x Databases. ¶ 
  13  856 7  $u http://worldnews.net $2 http ¶

1.3 How ROADS templates differ from other formats

ROADS templates are not based on AACR2 or ISBD. Like the MARC formats they can include a variety of information that is not generally included in those cataloguing formats. The most important examples are:

• subject headings and keywords
• administrative metadata
• contact information for the administrator or owner of a resource

Traditional cataloguing rules do not normally comment on this type of information.

1.4 Chief sources of cataloguing information

There are (currently) few comments on chief sources of cataloguing information in this document. For general guidance, the following is taken from Olson (1997, pp.7-8):

The chief source of information for computer files available by remote access is the title screen or similar display from the terminal or a printout of that information. If there is no special display, information may be taken from the home page, web page, or file itself: "readme file," "about" screen, TEI (Text Encoding Initiative) header, HTML tagging, documentation file, internal menus, labels, subject line, program statements, etc.

Because Internet resources are available by remote access, accompanying printed documentation is unlikely, though such documentation may be available in an internal file or a separate file. There are no containers with labels containing information. An added complication is that the file may be unreadable until it is decompressed and/or processed in some manner.

If no information is available as listed above, the cataloger may use a title from any published description of, or citation to, the file.

A file name may be used, if there is no other title given.

If no information is available from any source, the cataloger must supply a title.

The source of the title is stated in a required note in the bibliographic record being created

1.5 References

Curwen, A. G., 1990, ISBD Manual: a guide to the interpretation and use of the International Standard Bibliographic Description. PGI-90/WS/16. Paris: UNESCO.

Curwen, A. G., 1991, International Standard Bibliographic Description. In: McIlwaine, I. C. (ed.), Standards for the international exchange of bibliographic information: papers presented at a course held at the School of Library, Archive and Information Studies, University College London, 3-18 August 1990. London: Library Association Publishing, 73-81.

Deutsch, P., Emtage, A., Koster, M. and Stumpf, M., 1994, Publishing information on the Internet with Anonymous FTP. IETF Internet Draft, September. Available from: <URL:http://info.webcrawler.com/mak/projects/iafa/iafa.txt>

AACR2, 1988 rev. Gorman, M. and Winkler, P. W. (eds.), Anglo-American Cataloguing Rules, 2nd ed., 1988 rev. Prepared under the direction of the Joint Steering Committee for Revision of AACR. Ottawa: Canadian Library Association; London: Library Association Publishing; Chicago, Ill.: American Library Association, 1988.

ISBD(ER). International Federation of Library Associations and Institutions, IFLA Universal Bibliographic Control and International MARC Programme, ISBD(ER) International Standard Bibliographic Description for Electronic Resources: revised from the ISBD(CF): International Standard Bibliographic Description for Computer Files. Recommended by the ISBD(CF) Review Group. (UBCIM Publications, New Series, Vol. 17). München: K. G. Saur, 1997.

Olson, N. B. (ed.), 1995, Cataloging Internet resources: a manual and practical guide. Dublin, Ohio: OCLC Online Computer Library Center. Available from: <http://www.oclc.org/oclc/man/9256cat/toc.htm>.

Olson, N. B. (ed.), 1997, Cataloging Internet resources: a manual and practical guide, 2nd. ed. Dublin, Ohio: OCLC Online Computer Library Center. Available from: <http://www.purl.org/oclc/cataloguing-internet>.

Turabian, K.L., 1987, A manual for writers of term papers, theses and dissertations, 5th ed. Chicago, Ill.: Chicago University Press.

1.6 Acknowlegements

I would like to thank those representatives of eLib ANR subject services who attended a meeting about ROADS cataloguing guidelines held in Bath on the 17 September 1997 for their useful comments and support. In addition, I would also like to thank:

• Rebecca Bradshaw and ADAM (Art Design Architecture and Media information gateway), for being able to base parts of this document on the cataloguing rules developed for ADAM. These rules are available from the ADAM Public Document Archive: <http://www.adam.ac.uk/adam/public/>.

• Debra Hiom and SOSIG (Social Science Information Gateway) for sending me a copy of the SOSIG cataloguing rules.

These documents were very useful in the compilation of these guidelines.

Michael Day

2. ROADS data elements

2.1 Access-Policy:

Description: Policies for accessing a service.

Rule: Free-text.

2.2 Access-Times:

Description: Time-ranges for mandatory or preferred access to a service.

Discussion: It would be useful to have an agreed "time" format.

Rule: Free-text - care should be taken to specify which time-zone is being used.

2.3 Admin-

see USER cluster

2.4 Alternative-Title:

Description: An alternative to the title or short title fields

Rule: see Title:

2.5 Authentication:

Description: Authentication details, e.g. login and password details.

Rule: Free-text.

2.6 Author-

see USER cluster

2.7 Category:

Description: Type of resource.

Rule: [Under discussion].

2.8 Character-Set-v1:

Description: The character-set used, e.g. ASCII, ISO Latin-1, UNICODE, etc.

Rule: A need for an enumerated list?

2.9 Charging-Policy:

????

2.10 Checked-By-Date:

Description: Data element used by the ADAM project for administrative metadata.

Rule: No rule.

2.11 Checked-By-Name:

Description: Data element used by the ADAM project for administrative metadata.

Rule: No rule.

2.12 Citation:

Description: A preferred citation for the resource when used in other works.

Discussion: Several different citation formats exist, and usage of these vary considerably between different subject disciplines and countries. Also there are a large number of citation schemes that have been specifically developed for electronic resources. It will be difficult to enforce any single citation standard, although the most likely candidates are:

• Xia Li and Nancy B. Crane, Electronic styles: A handbook for citing electronic information, rev. ed. Medford, NJ: Information Today, 1996. See also: <URL:http://www.uvm.edu/~ncrane/estyles/>
• ISO Draft International Standard 690-2: Information and documentation - bibliographic references - electronic documents or parts thereof. Extracts available at: <URL:http://www.nlc-bnc.ca/iso/tc46sc9/standard/690-2e.htm>

It's probably best to avoid suggesting any particular citation format.

Rule: Any format appropriate to the resource may be used.

2.13 Comments:

Description: Comments added by the template creator or 'cataloguer'.

Rule: Free-text.

2.14 Copyright:

Description: A copyright statement.

Rule: Free-text.

2.15 Creation-Date:

Description: The date that the resource was created.

Discussion: Dates can be problematic. Electronic resources do not often contain adequate date information in any case, and where they do few attempt to distinguish between the date that the resource was created or last updated. In addition, some electronic resources - primarily but not exclusively textual ones - will have more than one relevant 'creation-date', e.g. the date originally written (where this is known), the date it was first published, the date of the edition or manifestation, the date that it was digitised and the date that it reached its final form as catalogued. For example, an (hypothetical) electronic edition of the Middle English poem Piers Plowman could be assigned the following possible 'creation-dates':

AACR2 would choose the date that the particular edition (or manifestation) was made available - it suggests for published items: "give the date (i.e., year) of publication, distribution, etc., of the edition, revision, etc., named in the edition area" (1.4F1). The electronic edition of Piers Plowman, for example would be assigned the date "1996", while the date of the source text - Kane and Donaldson's 1975 edition of the B Version - would be recorded as part of a 'Note'.

Another issue is the use of dates in other calendar systems, e.g. Julian calendar dates. As it is the creation date of a resource being described, this may not, however, be too big a problem.

An additional difficulty is the large number of formats available for dates. Two in particular suggest themselves for use in ROADS:

1. RFC 822 - the IAFA templates documentation (Deutsch et al. 1994, p.14) states that dates (and times) must be given as defined in RFC 822, Section 5.1 as modified in RFC 1123, Section 5.2.14, e.g.:

   Dec 1997 12:00:00 GMT

   This is the format currently used in ROADS templates, and it is used also in the automatically generated administrative metadata fields.

2. ISO 8601 - the suggested default date (and time) format in Dublin Core is ISO 8601, e.g.

   1997-12-22

   with six proposed levels of granularity:

   • Year: YYYY (e.g. 1997)
   • Year and month: YYYY-MM (e.g. 1997-07)
   • Complete date: YYYY-MM-DD (e.g. 1997-07-16)
   • Complete date plus hours and minutes: YYYY-MM-DDThh:mmTZD (e.g. 1997-07-16T19:20+01:00)
   • Complete date plus hours, minutes and seconds: YYYY-MM-DDThh:mm:ssTZD (e.g. 1997-07-16T19:20:30+01:00)
   • Complete date plus hours, minutes, seconds and decimal fractions of a second: YYYY-MM-DDThh:mm:ss.sTZD (e.g. 1997-07-16T19:20:30.45+01:00)

AACR2 neatly side-steps the date format issue by defining 'date' as the 'year' that particular manifestation was published or distributed (1.4F1, 9.4F1). ISBD(ER), however states that "in the case of online services and other dynamic resources (e.g. World Wide Web sites), a note may be given to indicate also the month, day, and year that appears in the resource" (4.4.1). For example, according to the ISBD(ER) section on Notes (7.9), a note could read as follows:

Description based on home page dated: 09/06/96.

Description of resource as of: May 19, 1996. --

No guidance is given on the format to be used in these notes, and as they will not generally be part of the searchable part of library catalogues, differences here will probably not unduly affect interoperability.

Whichever date format is chosen for use in ROADS templates, to ensure interoperability with ISBD(ER) and AACR2, only the 'year' of publication, distribution or issue needs (of necessity) to be extracted. In addition, tools that convert between RFC 822 and ISO 8601 may have some role within ROADS.

Rule: Use date (and time) in a standard format. Currently IETF RFC 822. Consideration should, however, be made of the possibility of using ISO 8601.

2.16 Description:

Description: Description or abstract.

Rule: Free-text description of resource.

2.17 Destination:

Description: The database to which the record will be added.

Rule: This should be defined by individual subject-services. No rule.

2.18 Discussion:

Description: Discussion of discussion forums appropriate for the resource.

Rule: Free-text.

2.19 Format-v1:

Description: Formats in which the resource is available, e.g. HTML, PDF, GIF or PostScript.

Rule: Would suggest an enumerated list of the most common formats.

2.20 Handle:

Description: Internal identifier for template.

Rule: Automatically assigned.

2.21 ISBN-v1:

Description: The International Standard Book Number of a resource.

Rule: Where a resource has an ISBN, it should be entered (where possible) using the standard hyphenation, e.g.:

IBSN-v1: 3-598-20387-X

If a resource has more than one ISBN, then a qualifer should be added.

ISBN-v1: 0-19-824235-2 (cased)
ISBN-v2: 0-19-823521-6 (pbk.)

ISBN-v1: 0-7458-0057-2 (Ellis Horwood Limited)
ISBN-v2: 0-470-20343-9 (Halsted Press)

Discussion: Are the qualifications really needed?

2.22 ISSN-v1:

Description: The International Standard Book Number of a resource.

Rule: Where a resource has an ISSN, it should be entered (where possible) using the standard hyphenation, e.g.:

ISSN-v1: 0010-4817

2.23 Keyword-Names:

Description: Element added to ROADS templates by ADAM to hold keywords for personal names.

Rule: Free-text, each keyword should be separated by either a comma or a semi-colon.

2.24 Keyword-Organisations:

Description: Element added to ROADS templates by ADAM to hold keywords for organisations.

Rule: Free-text, each keyword should be separated by either a comma or a semi-colon.

2.25 Keyword-Places:

Description: Element added to ROADS templates by ADAM to hold keywords related to geographical locations.

Rule: Free-text, each keyword should be separated by either a comma or a semi-colon.

2.26 Keywords:

Description: Subject keywords where these do not comprise part of a "Subject-Descriptor-Scheme:".

Rule: Free-text, each keyword should be separated by either a comma or a semi-colon.

2.27 Language-v1:

Description: The language/s of the intellectual content of the resource. For software, this could mean the programming language.

Discussion: Languages need to represented either by a standardised name, e.g. "Deutsch" instead of "German" or "Allemand". A better alternative would be to use an internationally agreed language coding scheme. The main schemes are:

1. ISO 639: Codes for the representation of names of languages - version 1 of ISO 639 uses two-letter language codes and covers about 120 languages, e.g.:

   en
   fr
   

2. ISO 639-2: Codes for the representation of names of languages - (which has been approved, but awaits publication [?] by ISO) uses three letter codes and covers about 400 languages, e.g.:

   eng
   enm
   

3. Z39.53 is a three character scheme broadly similar to ISO 639-2 and is used in USMARC and other formats.

One of these coding schemes should be agreed on and used. A link from to a registry of language tags should be included in a later version of these rules.

[Check: IETF registry of language tags, as specified in RFC 1766: Tags for the identification of languages <http://ds.internic.net/rfc/rfc1766.txt>].

Rule: Use language format detailed in Z39.50, until final publication of ISO 639-2.

2.28 Last-Revision-Date-v1:

Description: The date that the resource was last revised.

Rule: See discussion and recommendations under Creation-Date:

2.29 Owner-

see ORGANIZATION Cluster

2.30 Publication-Status:

Description: Status of publication, e.g. "draft", etc.

Rule: Free-text - possible use of enumerated lists.

2.31 Publisher-

see ORGANISATION cluster

2.32 Record-Created-Date:

Description: Administrative metadata.

Rule: Automatically-assigned by software - no rule.

2.33 Record-Created-Email:

Description: Administrative metadata.

Rule: Automatically-assigned by software - no rule.

2.34 Record-Last-Modified-Date:

Description: Administrative metadata.

Rule: Automatically-assigned by software - no rule.

2.35 Record-Last-Modified-Email:

Description: Administrative metadata.

Rule: Automatically-assigned by software - no rule.

2.36 Record-Last-Verified-Date:

Description: Administrative metadata.

Rule: Automatically-assigned by software - no rule.

2.37 Record-Last-Verified-Email:

Description: Administrative metadata.

Rule: Automatically-assigned by software - no rule.

2.38 Registration:

Description: Registration details for the resource if it is not available for general access.

Rule: Free-text.

2.39 Requirements:

Description: Description of any hardware or software requirements necessary for using the resource.

Rule: Free-text.

2.40 Short-Title:

Description: A shorter form of "Title:", e.g. an acronym.

Rule: see Title:

2.41 Size-v1:

Description: The length of the resource in bytes (octets).

Rule: Where this information is available (and desirable) it should be recorded as free-text, using standard abbreviations for units higher than bytes, e.g. Kb., Mb., etc.

Discussion: It is noteworthy that ISBD(ER) only provides for the physical description of electronic resources that are available for local access and have some kind of physical carrier, e.g.:

. - 1 electronic optical disc : sd., col. ; 12 cm

No physical description is (obviously) attempted for networked (or remote access) resources.

2.42 Source:

Description: Information about the definitive version of a resource.

Rule: The field is designed to be used for a free-text description of the source version of a resource.

Discussion: For electronic resources based on a previously existing texts (e.g. electronic texts) the information in this field would be largely bibliographic and an agreed format could be used, e.g. AACR2 (1.7A3):

Source: The crooked timber of humanity : chapters in
the history of ideas / Isaiah Berlin ; edited by Henry
Hardy. London : Fontana, 1990. xii, 276 p. ; 20 cm.
Originally published: London : John Murray, 1990. ISBN
0-00-686221-7.

Alternatively a bibliographical style like that used in the Chicago Manual of Style (Turabian 1987) could be used, e.g.:

Source: Ker, Ian. Healing the wound of humanity: the
spirituality of John Henry Newman. London: Darton, Longman
and Todd, 1993.

It is probably unrealistic to insist upon any particular format, especially as this data-element could be used for non-bibliographic items.

2.43 Sponsor-

see ORGANIZATION Cluster

2.44 Subject-Descriptor-Scheme-v1:

Description: The subject description scheme used in "Subject-Descriptor" data element. Typically a subject classification scheme or a controlled list based either on subject headings or a thesaurus. Popular schemes could be abbreviated, either using the list of subject systems codes registered with the IFLA UBCIM Office (listed in Appendix G of the UNIMARC Manual) expanded to include classification schemes.

Examples of selected IFLA UBCIM registered subject systems codes:

A clearer solution might be the use of a separate list of subject scheme abbreviations maintained by the ROADS template registry, for example:

Subject-Descriptor-Scheme-v1: LCSH [Library of Congress Subject Headings]
Subject-Descriptor-Scheme-v2: UDC [Universal Decimal Classification]
Subject-Descriptor-Scheme-v3: DDC21 [Dewey Decimal Classification, 21st ed.]

Where no abbreviated form exists in the ROADS template registry, then the full name of the scheme should be transcribed, for example:

Subject-Descriptor-Scheme-v1: Thesaurus of ERIC descriptors

Rule: Enter a shortened form of the subject descriptor scheme from an enumerated list (either from the ROADS template registry or the IFLA UBCIM registered list) or the full name of the relevant scheme used in the corresponding 'Subject-Descriptor' field. Other schemes may be registered with the ROADS template archive by the submission of relevant details. The abbreviation should be, where possible, capitalised.

2.45 Subject-Descriptor-v1:

Description: The subject terms themselves.

Rule: Transcribe complete subject descriptor according to the relevant "Subject-Description-Scheme" elsewhere in the template. Use the punctuation and capitalisation used in the original scheme, for example:

Subject-Descriptor-Scheme-v1: LCSH
Subject-Descriptor-Scheme-v2: DDC21
Subject-Descriptor-v1: World War, 1939-1945 - Germany
Subject-Descriptor-v1: Germany - History - 1933-1945
Subject-Descriptor-v1: Hitler, Adolf, 1889-45
Subject-Descriptor-v2: 940.43

2.46 Template-Type:

Description: The type of template in use.

Rule: The Template-Type must be one of those listed in the ROADS template registry, currently: DATASET, DOCUMENT, EVENT, IMAGE, MAILARCHIVE, PROJECT, SERVICE, SOFTWARE, SOUND, TRAINMAT, USENET and VIDEO.

Used in all Templates.

2.47 Title:

Description: The full title of a resource.

Discussion: This rule conforms to AACR2 practice. Display of records should be considered to be a separate issue.

Rule: Transcribe the title preserving the original wording, order and spelling. Only proper nouns should be capitalised. Punctuation need not reflect the usage of the original. Subtitles should be separated from the title by <Space>colon<Space>.

Title: Too hot to handle : the race for cold fusion

Where a resource has more than one title, the other title/s should be transcribed under the "Alternative-Title:" data element. Short titles, where they are an alternative to a longer title, can be transcribed under "Short-title:". If only a short title exists, it should be transcribed under "Title:".

Title: Council on Library and Information Resources
Short-title: CLIR

2.48 To-Be-Reviewed-Date:

Description: Administrative metadata.

Rule: Date automatically generated according to requirements of individual ROADS-based service. It would be useful if the format coincided with that used for Creation-Date:.

2.49 URI-v1:

Description: The Uniform Resource Indicator for a resource. In most cases, this will currently be a Uniform Resource Locator (URL).

Rule: Enter complete URI taking regard to correct spelling, punctuation and capitalisation. For example:

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

Where more than one URI exists for a resource:

URI-v1: http://www.dlib.org/
URI-v2: http://mirrored.ukoln.ac.uk/lis-journals/dlib/dlib/
URL-v3: http://sunsite.anu.edu.au/mirrors/dlib/

2.50 Version-v1:

Description: A version designator for the resource.

Rule: Enter in form found on resource, abbreviating "version" to "v." and "edition" to "ed.".

3. Clusters

3.1 User

USER clusters are used for recording personal information, e.g. the name of an author, the e-mail address of a site administrator or the address of a editor.

One general problem is distinguishing between the different types of USER cluster in use. In ROADS templates, the most commonly used are those for Author- and Admin- but also exist for Project-Manager- Project-Contact- and Project-Assessor-. On some sites distinguishing between an author and a site administrator can be problematic.

A second (related) problem is that formats appropriate for authors may not be appropriate for other USER cluster types. It is possible that name authority files may be useful for describing author-names, but may be of less utility for project contacts.

Traditional cataloguing rules would only tend to bother with the -Name attribute.

Note that all USER clusters are repeatable.

A sample (hypothetical) USER cluster:

Author-Handle-v1: 000034675
Author-Name-v1: Jones, Gordon
Author-Work-Phone-v1: +44 (0)1234 567 890
Author-Work-Fax-v1: +44 (0)1234 567 098
Author-Work-Postal-v1: P.O. Box 420, University of Wessex,
Casterbridge CB2 4HQ
Author-Job-Title-v1: Lecturer
Author-Department-v1: Department of Celtic Studies
Author-Email-v1: g.jones@wessex.ac.uk
Author-Home-Phone-v1: +44 (0)1234 765 890
Author-Home-Postal-v1: 11 City Road, Casterbridge PT3 4QH
Author-Home-Fax-v1: +44 (0)1234 765 098

3.1.1 -Department-v1:

Description: The Department in which the individual works.

Rule: Free-text - use the full title of the department, without abbreviations, wherever possible.

3.1.2 -Email-v1:

Description: E-mail address for individual

Rule: Use form used in original resource. Convert to lower-case where necessary.

3.1.3 -Handle-v1:

Description: Internal identifier for USER cluster record.

Rule: Automatically assigned.

3.1.4 -Home-Fax-v1:

Description: Facsimile telephone number for individual.

For all telephone numbers, see -Work-Phone-v1:

3.1.5 -Home-Phone-v1:

Description: Facsimile telephone number for individual.

For all telephone numbers, see -Work-Phone-v1:

3.1.6 -Home-Postal-v1:

Description: Home address of individual.

Rule: Free-text, use form used in resource, where possible, separating each line with commas.

3.1.7 -Job-Title-v1:

Description: Job title of individual.

Rule: Free-text, use form used in the resource.

3.1.8 -Name-v1:

Description: The name of an individual or corporate body.

Discussion: AACR2 deals with names (both personal and organisational) in two distinct ways. Firstly, they appear in the descriptive part of the catalogue record, typically in the statement of responsibility (AACR2 1988 rev. 1.1F) or in a note:

Some principles of liturgical reform : a contribution
towards the revision of the Book of Common Prayer / by W.H.
Frere. -- London : John Murray, 1911. -- xi, 210 p. ; 20 cm.

AACR2 directs that statements of responsibility should be transcribed in the form in which they appear in the item.

AACR2 also contains several chapters concerning headings for persons and corporate bodies (AACR2 1988 rev. ch. 22-23). Once the form of the name has been determined, the entry element itself is defined as "the name under which the person would normally be listed in authoritative lists in his or her language or country of residence or activity" (22.4A). This means that names are typically entered under a surname, e.g.:

Frere, W.H.
Weinberg, Gerhard L.
Day-Lewis, C.

For guidelines on other styles of personal names, including compound surnames, separately written prefixes and language specific rules, see AACR2 Ch. 22.

Rule: Enter names, where possible, surname first followed by a comma and the elements of the name that usually precede the entry element. For more precise rules see AACR2 chapters 22 and 23.

3.1.9 -Work-Fax-v1:

Description: Facsimile telephone number for individual.

For all telephone numbers, see -Work-Phone-v1:

3.1.10 -Work-Phone-v1:

Description: A telephone number for an individual.

Rule: Enter data in international format - including dialling code:

+International dialling code for that country <space> (0)telephone number

[List of international dialling codes in Appendix]

Admin-Work-Phone-v1: +44 (0)1225 323923

3.1.11 -Work-Postal-v1:

Description: Work address for individual.

Rule: Free-text, use form used in resource, where possible, separating each line with commas.

3.2 Organization

The attributes for the ORGANIZATION cluster are essentially the same as for the USER cluster, except that they omit the -Job-Title, -Home-Phone, -Home-Postal and -Home-Fax attributes and have additional attributes for -City and -State.

In ROADS templates, ORGANIZATION clusters are used for publishers, site-owners, site-sponsors and for project leaders and partners.

• Publisher-v1 - DOCUMENT template-type
• Owner-v1 - SERVICE template-type
• Sponsoring-v1 - SERVICE template-type
• Lead-v1 - PROJECT template-type
• Partner-v1 - PROJECT template-type.

3.2.1 -City-v1:

Description: The city (or town) in the postal address of the organisation.

Rule: Free-text - by preference, use the name used in the resource, but spellings could be normalised to standard English (or the language used in the rest of the ROADS template) language spelling - especially where other alphabets or symbols are used, e.g. the Welsh "Abertawe" becomes:

Publisher-City-v1: Swansea

If this field is going to be useful for cross-searching - e.g. a search asking for all templates associated with an organisation based in Rome or London - it would be better to normalise spelling in some way - either in the language of the resource being catalogued, the language in which the resource is being catalogued or a language independent of either, e.g. English. If cross-searching is not required, and this attribute is merely to be used as descriptive metadata, then normalised city spellings will not be necessary.

3.2.2 -Country-v1:

Description: The country in which the organisation is situated.

Rule: Free-text - by preference, use the name used in the resource, but spellings could be normalised to standard English (or the language used in the rest of the ROADS template) language spelling - especially where other alphabets or symbols are used, e.g. "Cymru" would become:

Publisher-Country-v1: Wales

As with the City attribute, if this field is going to be useful for cross-searching - e.g. a search asking for all templates associated with an organisation based in Germany - then it may not be useful to use the name actually used in the resource. It would be better to normalise spelling in some way - either in the language of the resource being catalogued (which could be difficult with some language), the language in which the resource is being catalogued or a language independent of either, e.g. English or international two letter country codes. If cross-searching is not required, and this attribute is merely to be used as descriptive metadata, then normalised country spellings will not be necessary.

3.2.3 -Department-v1:

Description: The relevant department of the organisation

Rule: Free-text - use the full title of the department, without abbreviations, wherever possible.

3.2.4 -Email-v1:

Description: E-mail address for the organisation

Rule: Use form used in original resource. Convert to lower-case where necessary.

3.2.5 -Handle-v1:

Description: Internal identifier for USER cluster record.

Rule: Automatically assigned.

3.2.6 -Name-v1:

Description: The name of an individual or corporate body.

Discussion: The discussion under USER -Name-v1 is relevant here, except that most organisation names will be almost certainly corporate names. In AACR2 (24.1A), headings for corporate bodies should, where possible, be entered in direct form "under the name by which it is commonly identified".

For guidelines on other styles of corporate body names, including government organisations, religious orders and the armed forces, see AACR2 Ch. 23.

Rule: Enter names, where possible, in direct form. For more precise rules see AACR2 chapters 23.

3.2.7 -Fax-v1:

Description: Facsimile telephone number for the organisation.

For all telephone numbers, see -Phone-v1:

3.2.8 -Phone-v1:

Description: A telephone number for the organisation.

Rule: Enter data in international format - including dialling code:

+International dialling code for that country <space> (0)telephone number

[List of international dialling codes needs to be added in Appendix]

Admin-Work-Phone-v1: +44 (0)1225 323923

3.2.9 -Postal-v1:

Description: Postal address of organisation.

Rule: Free-text, use form used in resource, where possible, separating each line with commas.

3.2.10 -State-v1:

Description: The State in which the organisation is based.

Rule: Free-text - by preference, use the name used in the resource, but spellings could be normalised to standard English (or other) language spelling. Used primarily for US states.

Some of the discussion regarding Country and City is relevant to this attribute.

4. ROADS template attributes of most relevance to ISBD

ISBD(ER)	ROADS templates
Title and statement of responsibility area -	Title: Author-Name-v1:
Edition area -	Version-v1:
Type and extent of resource area -	[use: "Electronic data"]
Publication, distribution area -	Publisher-City-v1: Publisher-Name-v1: Creation-Date:
Physical description area -	[None for Internet resources]
Series area -
Note area -	Description: Publication-Status: Last-Revision-Date: Language-v1: Admin-Name-v1: Owner-Name-v1:
Standard number and terms of availability area -	ISBN-v1: ISSN-v1: URI-v1:

It is possible that these attributes (where present) could form the basis of a quasi-mandatory set of ROADS template attributes. Also need: subject keywords, descriptors, name authorities, etc - but this is a start.

To ROADS cataloguing resources page.

This page maintained by Michael Day of the Metadata Group at UKOLN, University of Bath
Last Updated: 08-Jan-1998.