0. Status of this document

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

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.

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.

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

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

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.

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.

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.

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:

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:

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:

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.

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:,
Note:, Length:, Revision-Date: and Series:.

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.

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.

6. ReDIF templates for physical entities

6.1. The person template

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:

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:

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.

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: 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.