ReDIF version 1

Current maintainer: Thomas Krichel

Revision of 2007-08-14

This document contains contributions by José Manuel Barrueco Cruz, Christopher Baum, Sune Karlsson, Ivan Kurmanov, Benoit Pauwels, and Christian Zimmermann.

0. Status of this document

This version
http://openlib.org/acmes/root/docu/redif_1_2007-08-14.html
This stable version
http://openlib.org/acmes/root/docu/redif_1.html

It may be reproduced without the permission of the maintainer. You are encouraged to distribute it to your friends and colleagues. We hope that the collection of data that are encoded using ReDIF will also be widely distributed. Get in touch with the maintainer if wish to use ReDIF. Working together is more fun and more productive than working on your own.

Note that examples in this document are mostly fictitious. All similarity with the real world should be understood as a coincidence.

1. Introduction

This specification describes version 1 of the Research Documents Information Format (ReDIF). ReDIF version 1 will be referred to as ReDIF throughout. ReDIF is a metadata format to describe the output aspects of academic disciplines. But that we mean the scientific documents that are produced, the channels through which they are made public, the authors who produce the documents and the editors who control the output channels, etc as well as the institutions that support this process. ReDIF does not aim at a very elaborate description of these items. Its overriding design goal is simplicity. It is aimed primarily for the use by academics as a self-documentation tool. The idea is that if academics can make a better documentation of their work themselves, then the need for expensive intermediation between academics is reduced. ReDIF is supposed to be understood and deployed by people with no formal cataloging training.

ReDIF is shipped with software--written in Perl--that allows to read and validate ReDIF data. This software is available at http://openlib.org/acmes/root/soft/ReDIF-Perl. For example, any date has to be of the form yyyy-mm-dd. 1999-07 is a valid date, whereas Juillet 1999 is not a valid date. Therefore ReDIF is well suited for the decentralized maintenance of metadata. The validating software will make sure that only data that are syntactically correct will be passed on to user services. When subsequent versions will extend the capabilities of version 1 the data of version 1 will still be able to be understood by processing software that will implement future versions.

ReDIF is a relational metadata format. Each record has an identifier, also called a "handle". Elements in one record may use the identifier of another record. This allows elements to refer to other elements. A simple example should be sufficient. An author may have written several papers. She would like to have her email available within the data for each paper. But if the email address changes, there are changes required to all the records for all papers that the author has written. That is cumbersome. Instead, it is better to group all the personal data into one record, and use the handle of that record whenever personal data is required. The email address then only needs to be changed at one place. ReDIF explicitly allows for that.

In order to implement this handle structure, some human effort is required. This effort is being carried out by a group of people that we refer to as the "authority" in the following. RePEc is a well-know authority that uses ReDIF.

2. The ReDIF templates

2.1. The template types

ReDIF allows to describe things in the world that are important to the work of an academic discipline. We will use the word "items" to refer to any such things. ReDIF allows to catalogue three classes of items. First there are resources. A resource is either a digital string of information or anything that can be digitized. A book for example may not be digital but can be digitized, and therefore it is a resource. A second group of items are tangibles. These are objects of descriptions that can not be digitized. A person for example falls into that category. Finally, there are collections. These are manifolds that have a mixed nature that makes it difficult to decide whether they are tangibles or resources. In the following table, we list the items, the version of the ReDIF template that describes it, a description of the item, and finally the class of the item.

item name version concern class
ReDIF-paper 1.0 a research report that is not formally published resource
ReDIF-article 1.0 a research report in a scientific journal resource
ReDIF-chapter 1.0 a research report in a book resource
ReDIF-book 1.0 a book resource
ReDIF-software 1.0 an executable software or a software script resource
ReDIF-archive 1.0 describes a archive where templates are stored collection
ReDIF-series 1.0 describes a series of templates of the items above, e.g. a scientific journal collection
ReDIF-institution 1.0 an institution, e.g. a research center tangible
ReDIF-person 1.0 a person, who could be an author of a paper, editor of a journal etc. tangible

2.2. The ReDIF syntax

ReDIF splits all the information concerning an item into a set of data elements. By "data element" we mean an elementary piece of information that we do not wish to split further. The whole set of data elements that describe an item forms the bibliographic record or "template" of this item. "Field" are is a synonym for a "data element". We use in the following.

The ReDIF templates aim to compromise between human and machine readability. The general syntax for a field is

field_name: field value

where field_name would for example be Author-Workplace-Phone and field value would be +44 (0)1483 876958. Of course we could split the telephone number into an international dialing code, a city code and a local code, but that would go beyond what our data is actually needed for. The field name must be separated from the field value by a colon and optional whitespace. By a whitespace we mean a space character or a tabulation character or a newline character or a carriage return character or any combination of those.

Field names may contain only alphanumeric characters, the hyphen - and the hash sign #. No embedded spaces are allowed. Field names are case insensitive. Any field that starts with X- is considered to be local. The parsing software will read it but make no checks on the values.

Any field value may be continued (or even started) on the next line by adding a whitespace at the beginning of the continuing line. This is best practice as a general rule.

Here is the detail. Multi-line field values are delimited by the first line which starts with a string of characters without blanks that is ending in the colon character :. Thus an error will occor if a field name that is know to ReDIF appears at the beginning of the line. Example

Abstract: This paper is very complicated. It contains three
parts: one dealing with input, the next with output and the third
with throughput.

will lead to a parsing error because "parts" is not a field name known to ReDIF. To put this example right, it is suffient to write

Abstract: This paper is very complicated. It contains three
 parts: one dealing with input, the next with output and the third
with throughput.

but it is best to consistently indenent every continuing line

Abstract: This paper is very complicated. It contains three
 parts: one dealing with input, the next with output and the third
 with throughput.

The default character set for ReDIF is Windows-1252. This is a a superset of the ISO-8859-1 (also known as Latin1) character set available on non-Windows systems.

ReDIF files can also be encoded in UTF-8 which allows the use of characters not available in Windows-1252 or ISO-8859-1. This is recommended practice. When you encode a ReDIF file in UTF-8, you have to include the UTF-8 byte order mark at the beginning of the file. Most text editors will do this automatically for you.

Lines in a ReDIF file that start with '#' are used for comments.

Many fields may be repeated within one record, but repetitions are discouraged and for some fields they are prohibited. But for example, here is a person who works in two places

Author-Name: Sturm, J.F.
Author-Workplace-Name: Erasmus University Rotterdam,
       Econometric Institute 
Author-Workplace-Name: Center for Economic Policy Research

2.3. Order of fields in the template

The general principle is that all fields may appear in any order within the template. However there are two important exceptions to this rule.

First, every ReDIF templates must start with the Template-type: field. The value of this field indicates what type of resource will be described by this template. Therefore, the set of expected fields in the template itself depends on that value. The values for the template type are given in Subsection 2.1. The version number must be quoted after the template type. The version number will make it easier to implement changes to ReDIF. At the moment all template types are in version 1.0. For an example

Template-Type: ReDIF-Archive 1.0

Any data that does not start with a correct Template-Type: declaration will be ignored.

The second restriction of the freedom to group fields is necessary to express that certain pieces of information have to be kept together. Consider the case of a paper that has been co-authored by several people.

Author-Name:  Smith, Adam
Author-Name: Ricardo, David
Author-Email: Ricardo@classical.econ.org
Author-Email: Adam.Smith@classical.econ.org
Author-Workplace-Name: Institute of Classical Economics

Looking at this data you can easily find out that Smith's email address is Adam.Smith@classical.econ.org and that he probably works for the Institute of Classical Economics as Ricardo does. But computer is not able to find that out. We have to order the fields in such a way that the computer can understand which email address corresponds to which person. For each person, the name and the email address have to be kept together. There are other instances where we have to keep some fields in a group. We call such a group of fields a cluster.

3. Clusters

A cluster of fields is a group of fields within a template that belong together. Clusters are in fact like small templates within templates. For example, if we have a template of type "ReDIF-Paper 1.0" that describes a paper with several authors. It would contain several person clusters, one cluster for each author. If a document is available online, there should be one or several clusters with information about the files of the document--the main body of the text, a dataset that is used etc--as available on the Internet.

Each type of clusters has it's own field structure. Like templates, clusters must always start with one particular field, called the "key" field. Each cluster type has it's own key field. You should always keep one cluster's fields together.

Here is a simple cluster of type "Person" which describes an author

Author-Name: Smith, Joe
Author-Email: JoeSmith@some.uni.edu
Author-Postal: PO Box 123, Smith Street, Somewhere In The,
  Universe, 987654 
Author-Phone: +99 456-321123
Author-Homepage: http://www.some.where.edu/~JoeSmith

Here is a cluster of type "Organization" describing a provider of a series of papers:

Provider-Name: Central Publishing House
Provider-Phone: +44-(0)207 226 7063 
Provider-Homepage: http://www.central-publish.net

Clusters can be nested. For example, you can put an organization cluster to describe the organization an author is affiliated with, within the cluster of this particular author. Here we have an author who works at two institutions

Author-Name: Maria Saguvosky
Author-Workplace-Name: The New York Institute of Blasphemy 
Author-Workplace-Homepage: http://www.new-york.blasphemy.org
Author-Workplace-Name: The New Jersey Institute for Blasphemic Research

Within this document, when we want to show you that you can use some cluster in a template, we will use a syntax like Author-(PERSON*), Provider-(ORGANIZATION*), File-(FILE*) etc. Thus the clusters below in this document often join a field prefix, e.g. "Author-", with a cluster type name, e.g. "PERSON", , and a star sign, between parenthesis.

When writing clusters you should always remember to put the key field first. For example, if you write

Template-Type: ReDIF-Book 1.0
Title: The Capital
Author-Email: K.Marx@highgate.london.uk
Author-Name: Marx, Karl 
Author-Phone: ...

the Author-Email: field is not recognized, because at that point the Author-(PERSON*) cluster has not yet started. This will result in an error message or in your template being ignored. But the Author-Name: field that follows will start the cluster, because "Name" is the key field of the PERSON cluster. Hence the Author-Phone: field will be correctly processed.

This is all you need to know about clusters in general. We now address the specifics of the different cluster types.

3.1. The ORGANIZATION cluster

The ORGANIZATION cluster is defined by the following fields:

Name
Name of organization, the key
Homepage
URL of organization's home page
Name-English
English translation of the name of organization
Postal
Postal Address of organization
Location
Name of place where organization is based, e.g. "Harare"
Email
Electronic mail address(es) of organization
Phone
Telephone number(s) of organization
Fax
Fax number(s) of organization
Institution
Handle of an institution template that describes the organization

Name is the key field of the organization cluster. It should always be put first. Otherwise the most useful item is the homepage. Much of the remaining information can be derived from the homepage. It should be supplied if the homepage information is missing or the data at the homepage is not specific enough.

Here is an example of the organization cluster use to describe the provider of a working paper series.

Provider-Name:  Board of Governors of the Federal Reserve System 
Provider-Homepage: http://www.bog.frb.fed.us/ 
Provider-Email: feds_papers@frb.gov 

If a ReDIF institution template is available, then a better way to write to describe this institution is

Provider-Name:  Board of Governors of the Federal Reserve System 
Provider-Institution: RePEc:edi:frbgvus

In that case, the data of the institution template is used to describe the institution. It is then no longer necessary to give any further details about the institution within the template. The advantage of this representation is that when there is a change in the data for the institution, it is no longer necessary to update the data for the institution within each ORGANIZATION cluster within each PERSON cluster of every author who has written a paper when affiliated with that institution.

3.2. The Person cluster

The PERSON cluster is used to describe a person. It has the following fields

Name
Name of person, the key
Name-First
First name of person
Name-Last
Last name of person
Homepage
URL of person's home page
Workplace-(ORGANIZATION*)
Organization in which person works
Email
Electronic mail address(es) of person
Fax
Fax number(s) of person
Postal
Postal address of person
Phone
Telephone contact information
Person
Handle of a person template that describes the person, or short-id for such a person

Name is the key field of the person cluster. It should always be put first.

If a ReDIF person template for a person is available, then there is easy way to describe a person. This is done through the person template. For example

Author-Name: Thomas Krichel
Author-Person: RePEc:per:1965-06-05:thomas_krichel

There is also another type of handle for persons that is commonly used the RePEc project, the short-id. The short-id can be used as a substitute value in the Author-Person field. For example

Author-Name: Thomas Krichel
Author-Person: pkr1

Now all the information about the person, including the workplace data, is read from the person handle. No further information about the person needs to be entered.

3.3. The FILE cluster

The FILE cluster is used to describe a file that contains the resource that is being described, or a part of it. It is defined by the following fields:

URL
Uniform Resource Locator of file, the key
Format
The format, e.g. "application/pdf" for PDF files
Function
explains the function of file within the resource
Size
The file size, by default in kilobytes
Restriction
A restriction placed on accessing the file.

These fields of the FILE cluster are not self-descriptive as the fields of the previous clusters. We describe each of the fields in more detail.

URL: This is the Uniform Resource Locator (URL) of the file on the Internet. The URL identifies an access protocol and a code that this protocol can use to retrieve the resource. Please refer to RFC1783 when composing a URL. Any whitespace in the URL will be ignored. Following RFC1783 any whitespace that follows a dash character "-" is considered to be a mistake, because it is likely to have been introduced by word processing software. The URL can be written over several lines, but do not break it after a dash.

File-URL: http://www.hhs.se/research/wpecofi/papers/wp0121.pdf.zip
File-URL: ftp://crefe.dse.uqam.ca/pub/cahiers/cah44.ps 

This is the key field of the file cluster. It should always be put first.

Format: This is a an optional field to give a precise indication about the type of format that is found in the field. The Format: field is not repeatable and is case-insensitive. The contents of this field (all valid values) is restricted by a controlled vocabulary, the MIME Multipurpose Internet Mail Extensions types. These types are specified in the RFC1521. The complete and up-to-date list of these types is maintained by the IANA. We do not support any values for file format that are not listed there. If you want to convey information about a type that is not registered here, please contact the IANA. The most important MIME types that are used with ReDIF data are application/pdf and application/postscript, as well text/html. If you simply want to give a message to the user about the file, it is best to use the Function: field.

Function: This is the function of the file. It should be used when a file represents only some part of the whole resource. The field value may indicate what particular part of the document is represented by the file. Here are three examples

File-Function: Appendix 1
File-Function: Main text
File-Function: Fortran program used for the simulations
 reported in the paper 

If the file is a complete rendering of the resource, the File-Function field should not be used at all. When we have different files with no file function, user services should assume that all are alternative renderings of the complete text.

Size: The file size, by default in kilobytes. This is an optional and obsolete field. It is not repeatable. Examples

File-Size: 48
...
File-Size: 1788984 bytes

Restriction: A restriction on the retrieval of a file. If the file can be retrieved by anybody with Internet access without any preliminary payment or registration, you should not use that field at all. As soon as there is a restriction on the file many services will be assuming that there is no public access to the file. Some user services may wish to display only non-restricted files and your file will not appear there. If all files of a document are restricted, please use the field Restriction: in the template of the resource, rather than repeating it for each file of the resource.

Two examples for a complete file cluster

File-URL: http://rich.com/papers/d_duck.txt
File-Format: text/plain 
File-Function: Abstract

File-URL: http://rich.com/papers/d_duck.pdf
File-Format: application/pdf
File-Function: Main text
File-Size: 13982 bytes

4. The Collection templates

The collection templates describe archives and series. We list the fields for these templates by order of importance, the most important is put first.

4.1. The Archive template

The archive template provides information about how the bibliographic data in the archive can be mirrored (the URL field) and gives contact information for the archive (the Maintainer-Email field).

Template-type: ReDIF-Archive 1.0

Each archive template must start with this statement.

Handle: This is a mandatory field for the archive handle. The handle of the archive is the name of the authority (for example RePEc), a : and then the archive_code. The archive code is proposed by the archive administrator and awarded by the authority. It should not have semantic contents.

URL: This is a mandatory field for the archive directory. The URL should either point to a http or ftp site. It is to good practice to have it end with the archive code. This element is repeatable, but reading software may ignore all but the first value that occurs in a template.

Maintainer-Email: This is mandatory field for the email of somebody in charge of the archive. It is very important to keep it this field up-to-date. In particular, it is preferable not to use a personal email address of an employee that may move on later. It is best to give a general address of the sponsor of the archive. Make sure that the mail is read there and transmitted to the person who really maintains the archive.

Name: This is a mandatory field for the name of the archive. Even though this name is mandatory, the contents is not usually shown to end-users. If you want to describe your contents in some detail, use the series templates.

Maintainer-Name: This is an optional field for the name of a person who is in charge of the archive.

Maintainer-Phone: This is an optional field for the phone number of a person in charge of the archive.

Maintainer-Fax: This is an optional field for the fax number of a person in charge of the archive.

Classification-scheme: This is an optional field for subject information for the archive. Consult the same field in the ReDIF-Paper template and Appendix A for description.

Homepage: This is optional field for the URL of the archive's homepage. This should point to a location that an end user may be interested in.

Description: This is an optional field for a description of the archive's contents.

Notification: This is an optional field that may be used to specify how new papers in the archive are announced.

Restriction: This is an optional field to specify access restriction. It should be handle with care. A restriction mentioned here applies to all files referred to in all resources of all series in the archive. If the series can be retrieved by anybody with Internet access, you should not use that field at all. If not all of the series that make up the archive are restricted, mention the restriction only in the series templates of the restricted series.

Here we have two examples for the archive templates

Template-type: ReDIF-Archive 1.0
Handle: RePEc:bob
Name: Economics Working Paper Archive at WUSTL
Maintainer-Email: bparks@wueconaa.wustl.edu
URL: ftp://econwpa.wustl.edu/bob

Template-type: ReDIF-Archive 1.0
Handle: RePEc:wop
Name: WoPEc Project
Maintainer-Email: WoP_Ec@netec.mcc.ac.uk
Description: This archive collects information about holding of
 papers on those sites that have not (yet) joined RePEc.
URL: ftp://netec.mcc.ac.uk/pub/NetEc/RePEc/wop

4.2. The Series template

The series template provides information about a logical or physical collect of items, for example a working paper series or a peer-reviewed journal. The bibliographic information provided here is directly relevant for end users. In particular the Name field (the name of the working paper series or journal), the Provider-Name (who supports or 'publishes' the working paper series or journal) and Provider-Homepage field (where to find more information) are useful.

Template-type: ReDIF-Series 1.0

Each series template must start with this statement.

Name: This is a mandatory field for the name of the series.

Handle: This is a mandatory field. The handle is a unique identifier for the series. It is based on the handle for the archive holding the data about the series. It consists of the archive handle followed by a colon (:) and a six-character series code. The series code must be unique within the archive. It can contain the letters a-z and the numbers 0-9.

Maintainer-Email: This is a mandatory field for the email address of a person who is in charge of the series' files but not necessarily of its contents. The maintainer should be ready to receive error reports. As with the archive maintainer's email, a personal address should be avoided.

Type: Each series may only contain one type of templates. This rule is called "Baum's principle". The Type: field is used to indicate the type. The default type is "ReDIF-Paper". If the type of the elements of the series is "ReDIF-Paper", then this field does not need to be specified. Other legal series types are "ReDIF-Software", "ReDIF-Article", "ReDIF-Chapter" and "ReDIF-Book".

Order-Email: This is an optional field for the email address where to send ordering requests to.

Order-Homepage: This is an optional field for the URL of a screen where orders can be placed.

Order-Postal: Snail mail address where to order the paper.

Price: Price for all papers in the series when ordered. It an be overwritten by a separate Price: field in the paper

Provider-(ORGANIZATION*): This is the organization that supports the series. The provider is a more general term than the usual term "publisher". If you have a handle for your institution, please use the Provider-Institution: field after the Provider-Name: field.

Restriction: A restriction on the retrieval of all papers in the series. It has the same meaning as in a FILE cluster. It implies that all the files of all the documents in that particular series have this restriction.

Maintainer-Phone: This is an optional field for the phone number of the person in charge of the series

Maintainer-Fax: This is as optional field for the fax number of some person in charge of the series

Maintainer-Name: This is an optional field for the name of a person that is in charge of the files contained in the series.

Description: This can be a short description of the series' content.

Classification-scheme: This is an optional field for a subject for the series according to scheme scheme. Consult the same field in description of the paper template and Appendix A for description.

Keywords[-]: This is an optional field for keywords for the series according to scheme scheme. Consult the same field in the Paper template and Appendix A for description.

Editor-(PERSON*): This is the person responsible for the contents of the series.

Notification: This is an optional field to say how how new papers in the series are announced.

ISSN: This is the International Standard Serial Number for the series, if available.

Followup: This is an optional field that takes the value of another series' handle. That series is the successor of the series.

Predecessor: This is an optional field that takes the value of another series' handle. That series is the predecessor of the series.

Here are two examples for series templates.

Template-type: ReDIF-Series 1.0
Name: Computational Economics
Description: This is a series for economists who are computer nerds. You
 can not get more of an anorak than that. 
Maintainer-Name: Bob Parks
Maintainer-Email: robert_ parks@wuecona.wustl.edu
Handle: RePEc:bob:wuwpco

Template-type: ReDIF-Series 1.0
Name: Departmental Working Papers
Provider-Name: East Carolina University, Department of Economics
Provider-Homepage: http://ecuvax.cis.ecu.edu/~ecrothma/wp.htm 
Maintainer-Email: ecrothma@ecuvaax.cis.ecu.edu
Handle: RePEc:wop:eakjkl

5. The Resource template types

5.1. The ReDIF-Paper Template

This template concerns all documents that are not published as part of a journal or as part of a book or as a book. We will be a bit more verbose here than in Section 5.2 where we describe other templates.

We will list here the elements of the paper template in decreasing order of importance. We start with those elements that are really necessary. We then list those element that are optional but important. Finally, we turn to those elements that are not important.

Template-type: ReDIF-Paper 1.0

Each paper template must start with this statement.

Title: The title of the paper. This includes any subtitles. This is a required field. Use:

Title: A Theory of Gradual Trade Liberalisation

Author-(PERSON*): This is a required cluster field to describe the person(s) who has authored the document, i.e. who is responsible for its intellectual content. We recommend the name of the author should be given in normalized format like "Lastname, Firstname" but the direct order is also acceptable. Please add the full first names if you know them, but omit titles, honors etc. If there are several authors, there should be a separate cluster for each author. The special author name "et al" should be used when referring to a list of unknown other names. If you know the authors' names, put all authors names. This implies repeating a (PERSON*) cluster for every author. These other authors should be placed in separate author clusters.

The Author-(PERSON*) field is mandatory. That means that you should give at least one Author-Name: field with some value in each ReDIF-Paper template. Other information about the author is optional. Please do not overload the templates with author information. If you want to give elaborate personal information, register the person with a personal registration service. Use:

Author-Name: Lang, William 
Author-Email: wlang@lsumm.sncc.lsu.edu
Author-Workplace-Name: Center for Economic Performance 
Author-Name: Sturm, J.F.  
Author-Workplace-Name: Erasmus University Rotterdam, Econometric  
 Institute 
Author-Workplace-Postal: P.O. Box 1738, NL- 3000 DR Rotterdam, 
 The Netherlands 
Author-Workplace-Homepage: http://www.eur.nl/few/ei/indexuk.html 
Author-Workplace-Email: eb-webmistress@few.eur.nl 
Author-Homepage: http://www.eur.nl/few/ei/stu.html 

Handle: This is a required field to identify the bibliographic record. The Handle: field content starts with the name of the authority (organization), for example RePEc. The next element is the code of the archive, then follows the code of the series and finally the number of the paper within the series. All these parts are separated separated by the colon character, i.e. :. Note that this field may not contain whitespace. If the Handle is written over several lines, the processing software will eliminate the whitespace characters on the line boundaries. Use:

Handle: RePEc:bon:bonnsf:a452

Language: This field gives the language used in the paper. The language must be expressed as one of the values on ISO 639-1. Other codes are not available. If the languge is omitted, it is assumed to take the value "en". Example:

Language: fr

Contact-Email: This field gives a contact email address for the paper. This does not need to be one of the authors' email address. In some cases where the author does not wish her email to be in the paper information or when no author email is available, this field should be used. Use:

Contact-Email: Economics_Secretariat@hicks.gross-uni.yy 

Abstract: This is the abstract of the document. Although we do not require to have an abstract, but we strongly recommend to provide a detailed abstract, because it increases the chance of users finding your document within a full-text database. If you have a long abstract that has several paragraphs, you can leave a blank line. Use:

Abstract: This is the first paragraph of the abstract.

 This is the second paragraph of the abstract.

However, please recall that it is a good practice to indent every line that follows the first line with at least one blank.

File-(FILE*): A file cluster for a component of the paper. If the paper is contained in only one file, then quote the URL for that file. If the paper is available in various files, the file cluster should be repeated. If there are files that do not contain the full text of the paper, the File-Function: field should be used to specify the role of the file in the document. Under no circumstances should the File-(FILE*) cluster be used to link to an intermediate page where the files can be retrieved from via further hyperlinks. Use Order-URL: for this purpose.

Classification-scheme: This is the classification number associated with the document. The scheme is a code for a classification scheme. If there are several classification numbers of the same classification scheme, they will be separated by a semicolon. This field is not repeatable, unless there are multiple schemes used. Allowed (registered) classification schemes and codes are listed in the Appendix A. If you have documents, classified with some other scheme, just email us your suggestion, and we will register your scheme. Use:

Classification-JEL: C12; C30 

Keywords[-scheme]: These are keywords associated with the text. If there are several keywords they will be separated by a semicolon. scheme is the keywords scheme's code but it can also be empty, to say that the keywords do not follow a scheme. Keywords: should be used in that case. If you have some keywords scheme, we will register it for you. Use:

Keywords: Competition; Consumer economics; Ethics;
 Philosophy of economics

Keywords: Accounting theory; Accounting principles; Financial accounting

Number: The number of the paper within the series. This field is not repeatable.

Creation-Date: The date at which the original document was created. The format should be as similar to the ISO 8601:1988 Data elements and interchange formats--Information interchange--Representation of dates and times as possible. This is yyyy[-mm[-dd]] where yyyy is the year, mm is the month and dd is the day, and the square brackets indicate that the element is optional. Note that the field should only contain the date of the creation, no other information. This field is not repeatable. Use:

Creation-Date: 1995-06-30 

or

Creation-Date: 1996 

Revision-Date: A date at which the document was changed. The format for the value of that field is the same as in Creation-Date:. This field may be repeated.

Revision-Date: 1995-06-30

Publication-Status: This can be used to say if a modified version of the document exists, has been forthcoming, etc. in a commercial journal, book or other type of formal publication. It should always start with the word "published" or the word "forthcoming" (case insensitive). Use:

Publication-Status: Forthcoming in
  Computational Statistics and Data 
Publication-Status: Published in Journal of Artificial
   Intelligence Research, Vol.3 
Publication-Status: Published in American Journal of 
  Agricultural Economics, 1995, vol. 77, no. 1. pp. 120-134.
Publication-Status: Published by University of Arizona Press 

Note: Any other information that is relevant for the document. This can be its relation to other documents, a word or two about the history of the document etc. Use:

Note: This was an invited paper to a special issue of the 
 Noddyland Journal of Blasphemy

Length: The length of a printed version of the document, usually in pages. This field is not repeatable. Use:

 Length: 29 pages 

Series: This is the series in which the document appeared. It should be the same of the Name field in the series template. Thus this information is redundant. But you can put it here again. This field is not repeatable.

Availability: This field can be used to state if a paper is out of print. If the paper is on the net it should not be used. It can also be used to say how the get hold of the copy of the paper. This field is not repeatable. The use of this field is deprecated. It is allowed for backwards compatibility. Use:

Availability: out of print 

Order-URL: This is the URL of an intermediate page where there is ordering information about the file. The term "ordering information" should be taken in the widest possible sense. For example, web page with a set of links to various manifestation of the paper is a good candidate for an Order-URL:. Note that the URL should be specific to the paper. If all the papers in the series have the same ordering URLs then that information should be put in the series template.

Article-Handle, Book-Handle, Chapter-Handle, Paper-Handle, Software-Handle: These take values of handles of other publication forms of the paper.

The following elements are not important. They have been introduced to integrate legacy data into ReDIF-based system.

Restriction: A restriction on the retrieval of a paper. This is similar to the field of the same name in the File cluster. If the paper can be retrieved by anybody with Internet access, you should not use that field at all. Please do not use the field to make recommendations of the type "please use outside working hours", since as soon as there is a restriction on a paper many services will be assuming that there is no public access to it. If not all of the files that make up the paper are restricted, mention the restriction only in the FILE cluster of the restricted file. The use of this field is deprecated. It is allowed for backwards compatibility.

Price: That refers to the price of a printed copy of the document, when ordered through the ordering channels specified in the series template. Use:

Price: $3.00 Surface, $4.00 Air (U.S. $) 
Price: 15 guilders by mail, free by ftp 

For the price of an electronic copy, use the Restriction: field.

Notification: to specify how new versions of the paper are announced. The use of this field is deprecated. It is allowed for backwards compatibility.

Publication-Type: This field can be used to specify the type of publication of the document. The ReDIF-paper template should be used to describe any document that is not formally published. This includes working papers, but also documents of all types that are deposited in an institutional repository and hence for which the holding institution can not be labelled as the formal publisher (in the restrictive sense of the word). Examples of these are postprint versions of articles, author versions of book chapters or conference contributions. This field permits to distinguish between these different types of documents. Allowed values for this field are listed in the Appendix B.

Here are two examples of ReDIF templates of type "ReDIF-Paper 1.0". This is a simple document available only in PostScript format.

Template-Type: ReDIF-Paper 1.0
Author-Name:  David Currie
Author-Name:  Paul Levine
Author-Email:  p.l.levine@surrey.ac.uk
Author-Name:  Joeseph Pearlman
Author-Name:  Michael Chui
Title:  Phases of Imitation and Innovation in a North-South 
  Endogenous Growth  Model
Abstract:  In this paper, we develop a North-South endogenous growth
  model to examine three phases of development in the South: imitation
  of Northern products, imitation and innovation and finally, innovation
  only. In particular, the model has the features of catching up (and
  potentially overtaking) which are of particular relevance to the 
  Pacific Rim economies.  We show that the possible equilibria 
  depend on cross-country assimilation effects and the ease of
  imitation.  We then apply the model to analyze the impact of R&D
  subsidies.  There are some clear global policy implications which
  emerge from our analysis.  Firstly, because subsidies to Southern
  innovation benefit the North as well, it is beneficial to the North
  to pay for some of these subsidies.  Secondly, because the ability
  of the South to assimilate Northern knowledge and innovate depends
  on Southern skills levels, the consequent spillover benefits on 
  growth make the subsidizing of Southern education by the North
  particularly attractive.
Length:  26 pages
Creation-Date:  1996-07
File-URL: ftp://ftp.surrey.ac.uk/pub/econ/WorkingPapers/surrec9602.ps
File-Format: Application/postscript
Handle: RePEc:sur:surrec:9602

This is an example of a document from the banking structure conference 1994 at the Federal Reserve Bank of Chicago. Although there is no published working paper series of that kind, we have created a imaginary series with code "fedhbs". The document is available as PostScript in two parts, or as a zipped PostScript file. Since there is no MIME type for the zipped files, we have left out the File-Function: field.

Template-Type: ReDIF-Paper 1.0
Author-Name: Joseph P.Huges
Author-Name: William Lang
Author-Name: Loretta J. Mester
Author-Name: Choon-Geol Moon
Title: Recovering Technologies That Account for Generalized
        Managerial Preferences: An Application to Non-Risk-
        Neutral Banks
File-URL: ftp://test.frbchi.org/pub/bsc/doc13a.ps
File-Format: Application/PostScript
File-Function: Main Text
File-URL: ftp://test.frbchi.org/pub/bsc/doc13b.ps
File-Format: Application/PostScript 
File-Function: Chart
File-URL: ftp://test.frbchi.org/pub/bsc/doc13ps.zip
File-Function: Archive of Main text and chart
Handle: RePEc:wop:fedhbs:_013

Note that only Author-Name, Title and the Handle are mandatory in a template. It is however highly recommended that you should also give a Creation-Date, Abstract, Classification and/or Keywords.

5.2. ReDIF templates for other documents

In this Subsection, we look at templates that describe other forms of scientific documents.

5.2.1. The ReDIF-Article Template

An article is something that appeared in a journal or is forthcoming in a journal. This is a template for such publications.

Template-Type: ReDIF-Article 1.0

The template must start with this field.

Handle: Handle of journal article. This is a required field. It is of the same form as the handle of the paper template. As far as the series identifier is concerned, only series of articles are admissible here. Note that a journal is a nothing else than a series of articles. It therefore has a series code like a paper series. It can be referred to as a "journal code" in casual language, but the reader should keep in mind that as far as the structure of ReDIF is concerned the journal is nothing else than a series.

The component of the handle that describes an individual article is up to the maintainer of the data. All that is required is that it is unique within the journal series. Appendix C documents a scheme that is used a lot within RePEc.

The usual location information of an article is very useful to its citation. ReDIF fields that accomplish these are listed here. None of these fields is repeatable. They are fields that are specific to the article template, i.e. they do not appear in the paper template.

Journal: This is the journal in which the paper appeared. It should be the same of the Name field in the series template. Thus this information is redundant. But you can put it here again. This field is not repeatable.

Volume: The volume number that the article appeared in.

Year: Year of publication of the article.

Issue: The number or name of the issue in which the article appeared.

Month: The month where the journal issue where the article is appeared in.

Pages: The pages of the article in the journal in the form start-end, where start is the number of the first page and end is the number of the last page.

Number: The number of the article within the journal. This field is not repeatable and indicates a number that has been given to a electronic article without page numbers.

Article-Handle, Book-Handle, Chapter-Handle, Paper-Handle, Software-Handle: These take values of handles of other publication forms of the article.

Other fields are like the paper template except that the following are not valid: Availability:, Length:, Revision-Date: and Series:.

Example:

Template-Type: ReDIF-Article 1.0
Title: Productivity Spillovers from FDI in the Uruguayan
   Manufacturing Sector
Author-Name: Kokko, Ari
Author-Workplace-Name: Dept. of Economics, Stockholm School
   of Economics
Author-Workplace-Postal: Stockholm School of Economics,
   P.O. Box 6501, 113 83 Stockholm, Sweden
Author-Name: Tansini, Ruben
Author-Name: Zejan, Mario
Author-Workplace-Name: Dept. of Economics, Stockholm School
   of Economics
Author-Workplace-Postal: Stockholm School of Economics,
   P.O. Box 6501, 113 83 Stockholm, Sweden
Journal: Journal of Development Studies
Pages: 602-611
Volume: 32
Year: 1996
Publication-Status: Published
Handle: RePEc:jou:devstu:v:32:y:1996:i:Q1:p:602-611

What happens if you wish to provide data about the formal publication, i.e., within a journal, of a paper for which you have ReDIF-Paper information. This is called Sune's problem. The basic status is that it is not possible for you to provide information about an article that you have published in a journal. It is for the journal or some agent of the journal to provide that information, because all the information about all the articles has to be kept together in once directory. However, you can give the Article handle, and a ReDIF literate individual should be able to find the information.

5.2.2. The ReDIF-Software Template

Template-Type: ReDIF-Software 1.0

The template must start with this field.

Handle: This a required field. It uses the same syntax as the handle in the ReDIF-paper template.

Title: Name of the software, required, non-repeatable.

Programming-Language: This is a controlled vocabulary identifier for the language used. At the moment the only allowed value are "c", "c++", "dos executable", "executable", "fortran", "gauss", "gretl", "java", "mathematica", "matlab", "octave", "ox", "perl", "python", "r", "rats", "shazam", "s-plus", "stata", "tsp international". The term "executable" may be used for directly executable files. All these identifiers are case insensitive. This is a required field. This field is unique to the software template.

File-(FILE*): File cluster for a component file of the software.

Author-(PERSON*): Person cluster for each author, at least one cluster is required, see the paper template for guidance.

Abstract: Abstract to describe the principal function of the software.

Number: The number of the software. This is an optional field. It ought to be equal to the unique component of the handle.

Version: The version number of the software.

Classification-scheme: This is an optional field for subject information for the software. Consult the same field in the ReDIF-Paper template and Appendix A for description.

Keywords: Keywords for the software.

Size: Size of software, usually the number of lines of code. This optional field is unique to the software template.

Series: This is just a generic indication of what type of software it is.

Creation-Date, Revision-Date: as used is in the ReDIF-paper template.

Note: Any additional information.

Requires: indicates that a certain package version, compiler, or operating environment is needed. This optional field is unique to the software template.

Article-Handle, Book-Handle, Chapter-Handle, Paper-Handle, Software-Handle: These take values of handles of other publication forms of the software.

Example:

Template-Type: ReDIF-Software 1.0
Title: MKSTRSN: Stata modules to format Social Security number variables
Author-Name: William Gould
Author-WorkPlace-Name: Stata Corporation
Author-WorkPlace-Postal: Stata Corporation, 702 University Drive East,
  College Station, Texas 77840 USA
Author-Email: w_gould@stata.com
Programming-Language: Stata
Abstract: mkstrsn and mkdashsn make string variables (without and with
 dashes,respectively) from a nine-digit variable containing a Social 
 Security number.   The commands have the syntax mkstrsn newvar oldvar
  and mkdashsn newvar oldvar.
Series: Statistical Software Components
Number: S328601
Creation-Date: 19971212
Length: 39 lines
Classification-JEL: C87
File-URL: ftp://ftp.bc.edu/pub/user/baum/statal/mkstrsn.ado
File-Format: text/plain
File-Function: program code
File-URL: ftp://ftp.bc.edu/pub/user/baum/statal/mkdashsn.ado
File-Format: text/plain
File-Function: program code
Handle: RePEc:boc:bocode:S328601

5.2.3. The ReDIF-book Template

The book template is for providing data about single or jointly authored books as well as edited volumes. The book templates must be in a series with ReDIF-Book as the type.

Template-Type: ReDIF-Book 1.0

The template must start with this field.

Title: Title of book, required, non-repeatable

Handle: This a required field. It uses the same syntax as the handle in the ReDIF-paper template.

Author-(PERSON*): Authors of the book. Use a person cluster for each author. At least one cluster is required if there is no Editor-(PERSON*) cluster. See the paper template for guidance.

Provider-(ORGANIZATION*): Organization cluster for the provider. This is a required. The provider is a more general term for the publisher of a book.

Contact-Email: This field gives a contact email address for the book.

Year: Year of publication, required for published books, non-repeatable.

Month: Month of publication, non-repeatable.

Volume: Volume in multi-volume works, non-repeatable

Edition: 2nd, 3rd etc., non-repeatable.

Series: If the book is part of a series, non-repeatable. Use:

Series: Springer Lecture Notes in Mathematics, volume 234

Editor-(PERSON*): Editor of the book. Use a person cluster for each editor. At least one cluster is required if there is no Author-(PERSON*) cluster. See the paper template for guidance.

ISBN: ISBN of the book, non-repeatable.

Publication-Status: One of "Published" or "Forthcoming", non-repeatable. "Published" is assumed if field is not present.

Note: Any additional information

Abstract: Abstract.

Classification-scheme: same as for the ReDIF-paper template

Keywords[-scheme]: same as for the ReDIF-paper template.

HasChapter: If bibliographic data on the chapter in a book (for example an edited volume) is available in a separate series of chapters (for technical reasons data on chapters must be provided separate from data on books) this data can be linked to the book by adding one HasChapter field for each chapter.

Price: Price information for the book.

File-(FILE*): A file cluster for a component of the book. If the book is contained in only one file, then quote the URL for that file. If the paper is available in various files, the file cluster should be repeated. If there are files that do not contain the full text of the book, the File-Function: field should be used to specify the role of the file in the book. Under no circumstances should the File-(FILE*) cluster be used to link to an intermediate page where the files can be retrieved from via further hyperlinks. Use Order-URL: for this purpose.

Order-URL: This is the URL of an intermediate page where there is ordering information about the book. The term "ordering information" should be taken in the widest possible sense. For example, web page with a set of links to various manifestation of the book is a good candidate for an Order-URL:. Note that the URL should be specific to the book. If all the papers in the series have the same ordering URLs then that information should be put in the series template.

Number: This is an optional field for the number of the book in a series of books.

Creation-Date: The date at which the original book was written. The format should be as similar to the ISO 8601:1988 Data elements and interchange formats--Information interchange--Representation of dates and times as possible. This is yyyy[-mm[-dd]] where yyyy is the year, mm is the month and dd is the day, and the square brackets indicate that the element is optional. Note that the field should only contain the date of the creation, no other information. This field is not repeatable. Use:

Creation-Date: 1999-06 

or

Creation-Date: 1996 

Publication-Date: The date at which the original book was published. The format is the same as in Creation-Date This field is not repeatable.

Article-Handle, Book-Handle, Chapter-Handle, Paper-Handle, Software-Handle: These take values of handles of other publication forms of the book.

5.2.4. The ReDIF-Chapter Template

This template is for chapters with individual authors in a collection of papers. Examples are papers published in conference proceedings, reprint volumes and Festschrifts.

Many of the fields in the Chapter template can be derived from a linked book template: Editor cluster, provider/sponsor cluster, year, month, volume, edition, series, ISBN, publication-status and can be left out when this is present in the book template.

Template-Type: ReDIF-Chapter 1.0

The template must start with this field.

Handle: This a required field. It uses the same syntax as the handle in the paper template.

Title: Title of chapter, required, non-repeatable.

Author-(PERSON*): Person cluster for each author, at least one cluster is required, see the paper template for guidance.

Contact-Email: This field gives a contact email address for the chapter.

Abstract: Abstract of the chapter.

Classification-scheme: non-repeatable

Keywords[-scheme]: non-repeatable

Provider-(ORGANIZATION*): Organization cluster for Provider. This is general field that covers both the publisher of a book as well as the organizer of a conference for conference proceedings.

Book-Title: Title of book where the chapter was published , non-repeatable. This field is redundant if the book information is available.

Editor-(PERSON*): Editor cluster for each editor of the book where the chapter was published. This field is redundant if the book information is available.

Year: Year of publication, for published chapters, non-repeatable. This field is redundant if the book information is available.

Month: Month of publication, non-repeatable. This field is redundant if the book information is available.

Pages: Pages that the chapter occupies in the book, non-repeatable.

Chapter: The number of the chapter in the volume, non-repeatable.

Volume: For multi-volume works, this says in which volume the chapter was published, non-repeatable.

Edition: 2nd, 3rd etc, non-repeatable. This field is redundant if the book information is available.non-repeatable.

Series: Series that the book, where the chapter was published, is part of, non-repeatable. This field is redundant if the book information is available.

ISBN: ISBN of the book, non-repeatable. This field is redundant if the book information is available.

Publication-Status: One of 'Published' or 'Forthcoming', non-repeatable. Published is assumed if field is not present.

Note: Any additional information.

In-Book: Handle of the book that the chapter appeared in. This is the reverse of the HasChapter field in the ReDIF-Chapter template.

File-(FILE*): A file cluster for a component of the chapter. If the chapter is contained in only one file, then quote the URL for that file. If the paper is available in various files, the file cluster should be repeated. If there are files that do not contain the full text of the chapter, the File-Function: field should be used to specify the role of the file in the document. Under no circumstances should the File-(FILE*) cluster be used to link to an intermediate page where the files can be retrieved from via further hyperlinks. Use Order-URL for this purpose.

Order-URL: This is the URL of an intermediate page where there is ordering information about the chapter. The term "ordering information" should be taken in the widest possible sense. For example, web page with a set of links to various manifestation of the paper is a good candidate for an Order-URL. Note that the URL should be specific to the chapter. If all the papers in the series have the same ordering URLs then that information should be put in the series template.

Article-Handle, Book-Handle, Chapter-Handle, Paper-Handle, Software-Handle: These take values of handles of other publication forms of the chapter.

Example:

Template-Type: ReDIF-Chapter 1.0
Title: Modelling Economic Relationships with Smooth
   Transition Regressions
Author-Name: Teräsvirta, Timo
Author-Workplace-Name: Department of Economic Statistics
Author-Workplace-Postal: Stockholm School of Economics, Box
   6501, 113 83 Stockholm, Sweden
Book-Title: Handbook of Applied Economic Statistics
Editor-Name: Giles, D.E.A.
Editor-Name: Ullah, A.
Provider-Name: Dekker
Publication-Status: Forthcoming
Paper-Handle: RePEc:hhs:hastef:0131
Handle: RePEc:hhs:haschp:chp0131

6. ReDIF templates for physical entities

6.1. The person template

Template-Type: ReDIF-Person 1.0

The template must start with this field.

Handle: The handle of the person template. This is a mandatory field of the form

authority:archive_identifier: yyyy-mm-dd:namestring

where authority is the code of the authority, archive_identifier is the identifier of the archive, yyyy, mm, dd form a year, month and day of the month of a valid date. This date is called the significant date of the person. It is recommended to use the birthday, but any other date in the lifetime of the person is also admissible. Finally namestring is a name string that should resemble the person's name. Blanks is the name are replaced by the underscore character _.

Name-Full: The full name of the person. This field is mandatory.

Name-First: The first name of the person. This is useful when searching for the person's name in unstructured name data.

Name-Last: The first name of the person. This is useful when searching for the person's name in unstructured name data.

Name-Prefix: The prefix of the name, such as Mr, Very Reverend etc. This is optional.

Name-Middle: The middle name, ofter given as an initial. Use the full middle name or middle names here. This is an optional field.

Name-Suffix: The name suffix such as "Jr.", "III" etc. Use the abbreviated form as you wish to have it appear an a normal name screen. This is an optional field.

Name-ASCII: This is an form of the name that only uses ASCII characters. We recommend you adding this variation in case that the name does contain non-ASCII characters. This is an optional field.

Email: The email of the person.

Homepage: The URL of the homepage.

Fax, Postal, Phone, Workplace-(ORGANIZATION*), are allowed and take the same meaning as in the person cluster.

Workplace-Organization: takes the handle of the organization that the person is affiliated with.

Author-Paper, Author-Article, Author-Software, Editor-Series, Author-Book, Editor-Book, and Author-Chapter: These fields say that the person is the author or editor of a paper, article or software, etc The value of these fields must be the handle of a valid template.

Classification-scheme: A subject classification code for the academic area that the person is working in, according to the scheme scheme.

Short-Id: This is the short-id, an alternative form of identification as developed by the ACIS software. This field is not repeatable.

Last-Login-Date: This field contains the most recent date at which the user logged in. This field is used by the ACIS software. This field is not repeatable.

Registered-Date: This field contains the date the user registered. This field is used by the ACIS software. This field is not repeatable.

6.2: The ReDIF-Institution template

This template concerns information about institutions. This information can be used in the other templates by a call to the appropriate institution handle.

Template-Type: ReDIF-Institution 1.0

Every record must start with this field.

Handle: This has to be a 7 letter handle, the last two characters being the ISO 3166 country codes (us for the United States, ea foe associations and societies). This is a required field.. Examples:

Handle: RePEc:edi:imfffus Handle: RePEc:edi:mofgvzm Handle:
RePEc:fmg:fmlseuk 

Primary-(ORGANIZATION*): The main organization.

Secondary-(ORGANIZATION*): The second level of the organisation, of example a department.

Tertiary-(ORGANIZATION*): The third level of the organisation, for example a group within a department.

Quaternary-(ORGANIZATION*): The fourth level of the organisation, for example a sub-lab in a lab.

Examples for the leveling of organizations are: "University of London/London School of Economics Financial Markets Group", or "Federal Reserve Bank of Minneapolis / Research Department", "Government of Zambia / Ministry of Finance". These three clusters are organized like the (ORGANIZATION*) cluster. An example for a complete organization cluster is:

Primary-Name: Université des Grands Espoirs 
Primary-Name-English: University of Grand Hopes 
Primary-Location: Panava-les-Flots 
Secondary-Name: Departement d'Économie 
Secondary-Name-English: Department of Economics
Secondary-Email: eco@uge.edu 
Secondary-Homepage:http://www.eco.uge.edu/ 
Secondary-Phone: (+567)3466356

Primary-Defunct, Secondary-Defunct, Tertiary-Defunct: These fields take handles of former values of organizational elements.

An example for a complete record is:

Template-Type: ReDIF-Institution 1.0
Primary-Name: Government of Bahrain
Primary-Location: Manama
Secondary-Name: Bahrain Monetary Agency
Secondary-Homepage: http://www.bma.gov.bh/
Handle: RePEc:edi:bmagvbh

Appendix A: Classification and keywords schemes

A.1: Classification scheme(s)

RePEc only handles the JEL classification scheme. It is however, possible to use other schemes with ReDIF, and work in the past has done just that.

Classification-ACM-1964: The classification scheme used by the Association for Computing Machinery, in its version of 1964. Several codes may be given separated by colon, semi-colon or blanks.

Classification-ACM-1991: The classification scheme used by the Association for Computing Machinery, in its version of 1991. Several codes may be given separated by colon, semi-colon or blanks.

Classification-ACM-1998: The classification scheme used by the Association for Computing Machinery, in its version of 1998. Several codes may be given separated by colon, semi-colon or blanks.

Classification-Ila: The classification scheme proposed in the NASA TechReport TM-1998-208955.

Classification-JEL: The classification system of Journal of Economic Literature. It's usually used to classify economics texts. For more info see http://www.aeaweb.org/journal/elclasjn.html. Several code may be given separated by colon, semi-colon or blanks.

Classification-MSC-1991: The Mathematics classification scheme devised by the American Mathematical Society, in its version of 1991. Several codes may be given separated by colon, semi-colon or blanks.

Classification-MSC-2000: The Mathematics classification scheme devised by the American Mathematical Society, in its version of 2000. Several codes may be given separated by colon, semi-colon or blanks.

A.2: Keywords scheme(s)

Attent: This is a thesaurus (list of controlled keywords) which is used for the database "Attent: Research Memoranda". This database, as well as the thesaurus, is produced and maintained by Tilburg University Library. "Attent: Research Memoranda" only includes Economics working papers. The thesaurus includes economic and mathematical keywords. For further details contact Corry Stuyts <C.Stuyts at kub nl>.

Appendix B: Publication types in the ReDIF-Paper template

journal article

book

book chapter

working paper: for working papers and discussion papers

conference paper

report: for government reports and other final research report

other: for other publications

All values are case insensitive.

Appendix C: Suggestion for article handles

This appendix is a suggestion on how to generate article handles. These suggestions have been taken up by the RePEc project.

The article code in the unique identifier of a single article within a journal. We suggest that it is a concatenation of qualifiers, separated by the colon character :. Each qualifier is an field:value pair. The field is represented by one letter only. This is best understood by an example.

RePEc:xxx:joinec:v:19:y:1985:i:2:Q:1:p:67-84

The qualifiers currently defined are the following. We list a name for the qualifier, the letter of the qualifier, a description of values and a perl regular expression that that can be used to verify the syntax of the qualifier, as well as an optional additional check. All regular expressions are case insensitive.

Name: volume
Letter: v
Value: any sequence of digits
RegEx: v:[1-9][0-9]*

Name: issue
Letter: i
Value: any sequence of digits
RegEx: i:[1-9][0-9]*

Name: year
Letter: y
Value: any sequence of four digits
RegEx: y:([1-9][0-9]{3})
Check: warn if $1 is higher then current year or earlier than 1500

Name: pages
Value: number of page where article starts - number of page where the article ends
RegEx: p:S*([1-9][0-9]*)-S*([1-9][0-9]*)
Check: $1 should be smaller than $2

Here the S stands for "supplement", just in case that the paper has not been published in the main issue.

Name: issue
Value: which issue within the year. If the issue is a month, then we give the English three letter start of the month: JAN, FEB MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, DEC. The numbers of the months are also allowed here, but that is discouraged. If the issue is a quarter, we use Q1, Q2 etc. If the issue has a start date, put that date like 04-01 for 1 April. Note that you need to put the - separator here because the date is otherwise mistaken to be the number of the issue.There is no need to put an end date for this issue. You can repeat the issue qualifier if the physical issue covers several logical issues. SPE can be added to say it is a special editions, and S can be postponed for a supplement.
RegEx: i:(($months\d*)($season[S]*)(Q[1234])(\d+)(\d\d-\d\d)) where
$month="(jan|feb|mar|apr|may|jun|jul|aug|sep|oct|nov|dec)" and
$season="(spr|sum|aut|win|spe)"

Appendix D: Deprecated fields

Some fields have been valid in an earlier version of this specification. They are still considered valid by the ReDIF-Perl software. However, the use of such deprecated fields is discouraged.

Publisher-(ORGANIZATION*): This is a deprecated synonym for Provider-(ORGANIZATION*) in the ReDIF-Series, ReDIF-Book and ReDIF-Chapter templates.