This document describes version 1 of the Research Documents Information Format (ReDIF). 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 that produce the papers and the editors that control the output channels, etc as well as the institutions that support this process. Subsequent versions will extend the capabilities of version 1. Data of version 1 will still be able to be understood by processing software that will implement future versions.
This document is outdated. It is available in PDF format for US letter size paper and for A4 size paper . The current versions are available in PDF format for US letter size paper and for A4 size paper . All versions are in the public domain. You are encouraged to distribute it to your friends and colleages. We hope that the collection of data that are encoded using ReDIF will also be in the public domain. Get in touch with the maintainer if wish to use ReDIF. Working together is more fun and more productive than working on your own.
ReDIF is shipped with software that allows to validate the syntax of its argument. 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.
In principle, ReDIF should be syntax independent; and we are working on a way to express ReDIF in a completely syntax independent way. The verison 1 is not syntax independent. In this document we only describe a template syntax for ReDIF. This is a simple "field: value" data format inspired from the IAFA templates. A primitive nesting structure syntax is enabled through the use of clusters of fields. The default character set for ReDIF is ISO-8859-1. This is close to what is called Latin-1 on most machines and close enough to the standard Windows character set. It is also the character set that is used in the Hypetext Transfer Protocol (http).
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 phone number 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.
Note that examples in this document are mostly fictitious. All similarity with the real world should be understood as a coincidence.
ReDIF allows to describe things in the world that are important to the work of an academic discipline. We will use the word "item" to refer to any such things. ReDIF allows to catalogue the following types of item.
| item name | concern |
| ReDIF-paper | a research report that is not formally published |
| ReDIF-article | a research report in a scientific journal |
| ReDIF-chapter | a research report in a book |
| book | a book |
| software | an executable software or a software script |
| series | describes a series of templates of the items above |
| institution | an institution, e.g. a reseach centre |
| person | a person, who could be an editor of a paper, editor
of a journal etc. |
In addition, ReDIF knows about a number of templates that are internal to its operation.
The ReDIF format splits all the information concerning a document 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 object forms the bibliographic record or "template" of this object. "Attribute" and "field" are two synonyms for a data element. "Record" is a synonym for a template.
Templates or records are stored in files. Each file can contain one or more templates. But one template cannot be separated into several files.
The ReDIF templates aim to compromise between human and machine readability. The general syntax for a field is
data_element_name: data element value
where data_element_name would for example be
Author-Workplace-Phone and the data element value would be
+44 1483 876958. Of course we could split the telephone
number into an international dialling 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 any combination of those.
Any field value may be continued (or even started) on the next line by adding a whitespace at the beginning of the continuing line. Multi-line data element values are delimited by the first line which does not have a whitespace character in the first position, or is blank. Thus all lines containing data element names should have no whitespace characters in the beginning of the line.
As a general rule, all whitespace characters that intends to signal the continuation of a field value are to be collapsed into a blank space character by processing software. For example,
Title: Ecological outcomes
of economic progress of
mankind in last 100 years.
Critical review.
is a correct.
All data element names may contain only alphanumeric characters, the hyphen ("-") and hash sign ("#"). No embedded spaces are allowed. All data element names are case insensitive. For readability we prefer that the initial letters are capitalised for better human readability).
Any attribute that starts with X- is considered to be local,
and generally may be ignored by anyone.
It may be used by template writers to store any additional information.
Many attributes may be repeated within one record, but repetitions are discouraged and for some fields they are prohibited. But for example, here is a person that 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
But again, please avoid repeating attributes.
The ReDIF format requires some ordering requirements on the attributes within the templates. Some information has to be kept together. In that case of several authors, each having different affiliations, the affiliation of each author have to be kept with the author information. More generally, some data elements have to be kept together. We call such a group of data elements a cluster and discuss it in Section 3. Each cluster has to start with a specific field. Similarly each template has to start with a Template-Type declaration.
All ReDIF templates must start with the Template-type field. The value of this field has important meaning - it indicates what type of resource will be described by this template. Therefore, set of expected fields in the template itself depends on that value. The following are allowed at the moment.
| Name | Version | used for |
| ReDIF-Paper | 1.0 | individual documents |
| ReDIF-Article | 1.0 | documents in a journal |
| ReDIF-Chapter | 1.0 | documents in a book |
| ReDIF-Series | 1.0 | series of documents |
| ReDIF-Archive | 1.0 | archives of series of documents |
| ReDIF-Mirror | 1.0 | mirrors of archives of series of documents |
Each template type has also a version number. That 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.
Use:
Template-Type: ReDIF-Archive 1.0 ...
Any data that does not start with a correct Template-Type: declaration will be ignored.
There are some sets of data elements in all template types, which are common in several cases. For example each file on the Internet has it's URL (Internet-address), it's content is presented in some specific format, and several different files can represent different parts the whole document. For example, each person mentioned in any template may have a phone number, postal address, and probably works for some organizations and so on. Similarly, each organization has it's specific name, address, phone number etc.
We decided that these three cases (persons, organisations and files) are more or less universal, so we use the concept of "clusters of attributes" for these cases.
A cluster of attributes is a set of logically tied fields in a template about one particular subject or object. Clusters are in fact like small templates, which can be used inside real (bigger) templates. For example, if we have a template of type "ReDIF-Paper 1.0", it usually would contain a cluster (or several clusters) with information about the author(s) of the paper, and one or several clusters with information about the files of the paper, available on the Internet (if there are any).
Each type of clusters has it's own structure (attributes). Like templates, clusters must always start with one particular field, "key" field. Each cluster has it's own key field. The use of the key field is independent on which template the cluster is used in. It is also independent from the place where cluster is used in. We say that it is independent on the context.
A cluster cannot be mixed with other attributes, which do not relate to this particular cluster. So you should always keep one cluster's attributes together. You can however nest clusters, for example start an organisation cluster to describe the organisation an author is affiliated with, within the cluster of this particular author.
In fact, it's all not so complicated as it may seem. Let's look at some examples to make things clear. Here is a simple cluster of type "Person" which describes an author
Author-Name: Joe Smith 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: ... Provider-Fax: ... Provider-Homepage: http://...
When we want to show you that you can use some cluster type a template, we will use a syntax like Author-(PERSON*), Provider-(ORGANIZATION*), File-(FILE*) etc.
Thus the clusters below in this document often join an attribute prefix, e.g. "Author-", with a cluster type name, e.g. "(PERSON*)", between parenthesis.
When writing clusters you should always remember about putting the key field first. For example, if you write
Template-Type: ReDIF-Paper 1.0 Title: The Capital Author-Email: K.Marx@highgate.london.uk Author-Name: Karl Marx Author-Phone: ...
the Author-Email: attribute is not recognised, 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 Author-Phone: field will be correctly processed.
Another example of potential mistakes is a case, when there are several objects to be described by a cluster type. Imagine that we have two editors for a series
Editor-Name: Adam Smith Editor-Name: David Ricardo Editor-Email: Adam.Smith@classical.econ.org Editor-Email: David.Ricardo@classical.econ.org Editor-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 wouldn't.
For the computer, the line Editor-Name: David Ricardo has started
a new PERSON cluster, so it will eventually contain all the rest
information you gave, including the email address of Smith.
This mistake will not be identified as by any software only
a human can find this mistake.
We believe that it's enough for you to understand the general principles of clusters. We will fill in the details now.
The ORGANIZATION cluster is defined by the following attributes:
| Name | Description |
| Name | Name of organization, the key |
| Name-English | English translation of the name of organization |
| Postal | Postal Address of organization |
| Location | Name of place where organisation is based, e.g. "Harare" |
| Electronic mail address(es) of organization |
|
| Phone | Telephone number(s) of organization |
| Fax | Fax number(s) of organization |
| Homepage | URL of organisation's home page |
Name is the key attribute of the organization cluster. It should always be put first.
If you need example of organization cluster (where the organisation is in fact a provider):
Provider-Name: Board of Governors of the Federal Reserve System Provider-Homepage: http://www.bog.frb.fed.us/pubs/feds/1996/ Provider-Email: fedspapers@frb.gov
The PERSON cluster is used to describe Homo Sapiens.
| Name | Description |
| Name | Name of person, the key |
| Workplace-(ORGANIZATION*) | Organization in which person works |
| Electronic mail address(es) of person |
|
| Fax | Fax number(s) of person |
| Postal | Postal address of person |
| Phone | Telephone contact information |
| Homepage | URL of person's home page |
Name is the key attribute of the person cluster. It should always be put first.
Clusters can be nested, e.g., the (PERSON*) cluster can have a Workplace-(ORGANIZATION*) cluster inside it, as we illustrated in the Adam Smith example earlier.
| Name | Description |
| URL | Uniform Resource Locator of file, the key |
| Format | The format, e.g. "application/pdf" for PDF files, mandatory |
| 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 attributes may be not so trivial as in previous clusters, so we'll describe each of them now.
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 http://src.doc.ic.ac.uk/rfc/rfc1738.txt 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. Use:
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 attribute of the file cluster. It should always be put first.
Format: The contents of this field (all valid values) is restricted by a controlled vocabulary, with the MIME Multipurpose Internet Mail Extensions types. These types are specified in the RFC1521 at http://src.doc.ic.ac.uk/rfc/rfc1521.ps.gz. One complete and up to date list of these types is maintained by the IANA Internet Assigning Number Authority. But we have added some more types to the list since MIME does not cover all the formats that we have in the database. The format of this field's value is:
File-Format: type/subtype[/subsubtype1][/subsubtype2]
Here square brackets indicate that the expression inside is optional.
type: The type will be one of text, application or image.
subtype: The subtype is related to the type. When type is text we have:
text/plain text/html text/tex text/latex text/bibtexWhen the the type is
application we have: application/pdf application/postscript application/msword application/wordperfect application/dvi application/lotus application/chiwriter application/gauss application/amipro application/mathematica application/rtf application/envoy application/quattropro application/eps application/vnd.ms-excel application/hp application/fortran application/bin application/prnWhen the type is
image we have: image/jpeg image/gif image/tiff
They are open lists that will be completed when documents with new formats will appear. If you wish to use a new type, please mail to the current author of this document.
/subsubtype1 & subsubtype2: To enumerate if the file is
compressed and/or taped in some way. If one version is compressed and
taped the file format will need two subsubtype parts. The
subsubtype is optional. All files must have one type and subtype,
but they may not have a subsubtype. The subsubtypes can be:
zipped: zip files are the most popular compressed files
on the Internet. Usually they have the
extension .zip
gnuzipped: This is a gzip (GNU zip) file format. zip and gzip are two
different programmes, although the actual compression and decompression
sources were written by the same people. zip is an archiver: it compresses
several files into a single archive file. gzip is a simple compressor: each
file is compressed separately. On Unix, gzip is mostly useful in combination
with tar. Usually they have the extension .gz.
unixcompressed: Compressed with the standard Unix compress utility;
usually they have the extension .Z.
taped: an archive produced by the Unix tar utility. Tar is not
a compression programme. It is used in Unix machines and provides a
way to store many files in a single archive, which can be kept in
another Unix file. Usually the archive has the extension .tar.
The subsubtypes can be combined:
.../zipped .../gnuzipped .../gnuzipped/taped .../unixcompressed .../mac-binhex40 .../unixcompressed/taped
The attribute Format: is not repeatable and is case-insensitive.
Function: This is the function of the file. It should be used when a file represents only some part of the whole document (or resource). And the field value indicates what particular part of the document is represented. For example, use:
File-Function: Appendix 1 ... File-Function: Main text ... File-Function: Example programmeIf the file is a complete rendering of the resource, the
File-Function
field should not be used. The field is not repeatable within the
description of the same file.
Size: The file size, by default in kilobytes. This attribute is not repeatable. Use:
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. 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 the file many services will be assuming that there is no public access to the file. 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.abs File-Format: text/plain File-Function: Abstract File-URL: http://rich.com/papers/d_duck.wp File-Format: application/wordperfect File-Function: Main text File-Size: 13982 bytes
This template concerns all papers that are not published as part of a journal. We will be a bit more verbose here than in Section 5 where we describe other templates.
Author-(PERSON*): This cluster-field is used to describe the person(s) that has created the document and is mainly responsible for its intellectual content. We recommend the name of the author(s) should be given in normalised format like "Lastname, Firstname" but the direct order is also acceptable.
Omit titles, honours and others. If there are several authors, the information should be repeated for each author. This 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. Use:
Author-Name: Lang, William
Author-Email: wlang@lsuvm.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-webmaster@few.eur.nl
Author-Homepage: http://www.eur.nl/few/ei/stu.html
Contact-Email: This field is used to describe the a person that is a contact for the paper. This does not need to the be the author's email. You should not supply this field if you already have the author email. In some cases where the author does not wish her email to be in the paper information, this field should be used. Use:
Contact-Email: Economics_Secretariat@hicks.gross-uni.yy
Title: The name of the document being catalogued. This includes any subtitles. This is a required field. Use:
Title: A Theory of Gradual Trade Liberalisation
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 please
split the paragraphs by the html <p>
sequence or repeat the Abstract: field for each paragraph.
Classification-scheme: This is the classification number associated with the document. The scheme is a code for a classification scheme. Allowed (registered) classification schemes and codes are listed in Section 10.1. If you have documents, classified with some other scheme, just email us your suggestion, and we will register your scheme.
If there are several classification numbers of the same classification scheme, they will be separated by a semicolon. This attribute is not repeatable, unless there are multiple schemes used. Example:
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 schemes, we will register it for you in Section 10.2.
Example:
Keywords: Competition; Consumer economics; Ethics; Philosophy of economics Keywords: Accounting theory; Accounting principles; Financial accounting
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 Polish... Note: This paper was written 5 years ago and we haven't...
Length: The length of a printed version of the document, usually in pages. This attribute is not repeatable. Use:
Length: 29 pages
Series: This is the series of the document. You can simply name the series here. In any case series information may also be extracted from the series templates of the core template files. This attribute is not repeatable.
Number: The number of the paper within the series. This attribute 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 attribute is not repeatable. Use:
Availability: out of print
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. The notation yyyy[dd[mm]] may also be used. 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
Revision-Date: A date at which the document was changed. See previous paragraph for value format of this field - it is the same as in Creation-Date. This field may be repeated.
Revision-Date: 1995-06-30
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
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
Handle: This is a required field in all cases. It's really important. The Handle field content starts with the name of the authority (organization), for example RePEc. The next element is a : and after that follows the code of the archive, then code of the series finally the number of the paper. All these parts are : separated. 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 lines boundaries. Use:
Handle: RePEc:bon:bonnsf:a452 Handle: RePEc:die:calsdi:9338 Handle: RePEc:wop:censes:90-1 Handle: RePEc:wop:comadt:08 Handle: RePEc:wop:fedhbs:_007
Each electronic document, described in RePEc system will have it's own unique handle, which will allow to identify it (if we now the type of the document, e.g. Paper).
template_type-Handle: This attribute cannot be used until we develop and introduce more template types for different document types. But we will explain you idea for the future. If there is a different version of a document and this new version has been described using the ReDIF templates in some system (may be RePEc or may be not), it is possible to provide a reference to this another variant of the document by use of this field. You just need to specify a template-type in the field and give a handle. For a example, imagine that we have defined the ReDIF-Book template and we have a template of a paper, which was later published as a book. And this book also got to be described in a ReDIF template. Then just can include Book-Handle field into the ReDIF-Paper template and supply the handle (value of the field Handle) of the book. Restrictions on value of this field are the same like in case of bh(Handle). Use:
Article-Handle: RePEc:chgooe:957701a Book-Handle: RePEc:aripr038The resolution process of these handles is not yet clear.
Notification: to specify how new versions of the paper are announced.
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.
Below there are several 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.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 analyse 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 subsidising
of Southern education by the North particularly attractive.
Length: 26 pages
Creation-Date: 199607
File-URL: ftp://ftp.surrey.ac.uk/pub/econ/WorkingPapers/surrec9602.ps
File-Format: Application/postscript
Handle: RePEc:wop:surrec:9602
This example from the Washington University Working Paper Archive. The paper has six different formats (postscript, postscript unixcompressed, pdf and so on). It's author is Francisco F. R. Ramos from the Faculty of Economic, University of Porto. The original document was prepared using Microsoft Word as it said in the Note field.
Template-Type: ReDIF-Paper: 1.0
Title: Forecasting market shares using VAR and BVAR models: A comparison of
their forecasting performance
Author-Name: Francisco F. R. Ramos
Author-Email: framos@fep.up.pt
Author-Workplace-Name: Faculty of Economic, University of Porto
Note: Type of original Document - Winword 2.0; prepared on IBM PC; to print
on HP/Epson; figures: included. Word document submitted by ftp
Length: 41 pages
Keywords: Automobile market; BVAR models; Forecast accuracy; Impulse
response analysis; Marketing decision variables; Specification of
marketing priors; variance decomposition; VAR models
Classification-JEL: C11; C32; M31
Abstract: This paper develops a Bayesian vector autoregressive model (BVAR)
for the leader of the Portuguese car market to forecast the market
share. The model includes five marketing decision variables.The
Bayesian prior is selected on the basis of the accuracy of the out-
of-sample forecasts. We find that our BVAR models generally produce
more accurate forecasts of market share. The out-of-sample accuracy
of the BVAR forecasts is also compared with that of forecasts from
an unrestricted VAR model and of benchmark forecasts produced from
univariate (e.g., Box- Jenkins ARIMA) models. Additionally,
competitive dynamics of the market place are revealed through
variance decompositions and impulse response analysis.
Creation-Date: 19960123
File-URL: http://econwpa.wustl.edu/econ-wp/em/papers/9601/9601003.ps
File-Format: Application/PostScript
File-URL: http://econwpa.wustl.edu/econ-wp/em/papers/9601/9601003.ps.Z
File-Format: application/postscript/unixcompressed
File-URL: http://econwpa.wustl.edu/econ-wp/em/papers/9601/9601003.pdf.Z
File-Format: Application/pdf/unixcompressed
File-URL: http://econwpa.wustl.edu/econ-wp/em/papers/9601/9601003.pdf.zip
File-Format: Application/pdf/zipped
File-URL: http://econwpa.wustl.edu/econ-wp/em/papers/9601/9601003.pdf.gz
File-Format: application/pdf/gnuzipped
File-URL: http://econwpa.wustl.edu/econ-wp/em/papers/9601/9601003.pdf
File-Format: application/pdf
Handle: RePEc:bob:wuwpem:9601001
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.
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 Techonologies 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-Format: Application/Postscript/zipped
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.
Core templates are templates that describe archives, mirrors and services.
Template-type: ReDIF-Archive 1.0
Each archive template must start with this declaration.
Handle: This is the archive handle. The handle of the archive is
the name of the authority (for example RePEc), a : and then
the archive_identifier. The archive identifier has 3 letters. It
should not have semantic contents. The archive identifier is proposed
by the archive administrator and awarded by the authority.
This field must not contain whitespace.
Name: The name of the archive. This is a mandatory field.
URL: url for the archive directory. This is a mandatory field. The URL should either point to a http of ftp site and should and with the three letter archive code.
Homepage: the url of the archive's homepage. This should point to a location that an end user may be interested in.
Description: a description of the archive's contents
Maintainer-Email: the email of somebody in charge of the archive (mandatory)
Maintainer-Phone: phone number of some person in charge of the archive
Maintainer-Fax: phone number of some person in charge of the archive
Maintainer-Name: the name of a person that is in charge of the archive
Classification-scheme: Subject information for the archive, if applicable. Consult the same attribute in the Paper template and Appendix A for description.
Notification: To specify how new papers in the archive are announced.
Restriction: A restriction on the retrieval of all series in the archive. Similar to the same field in the paper template and in the file cluster. 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.
Templates examples:
Template-type: ReDIF-Archive 1.0 Handle: RePEc:bob Name: Economics Working Paper Archive at WUSTL Maintainer-Email: bparks@wuecona.wustl.edu URL: ftp://econwpa.wustl.edu/bob Template-type: ReDIF-Archive 1.0 Handle: RePEc:wop Name: WoPEc Project Maintainer-Email: WoPEc@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 URL: http://netec.mcc.ac.uk/RePEc/wop/
The archive template must be kept in a file called ???arch.rdf
where ??? is the archive_identifier of the archive. Note
the slash that ends the last URL!
Template-type: ReDIF-Series 1.0
Each series template must start with this attribute.
Name: The name of the series is a mandatory field.
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". Other legal series types are "ReDIF-Software", "ReDIF-Article", and "ReDIF-Book".
Description: This should be a short description of the series' content. Advertise your series here!
Classification-scheme Subject for the series according to scheme scheme. Consult the same attribute in the Paper template and Appendix A for description.
Keywords[-scheme]: Keywords for the series according to scheme scheme. Consult the same attribute in the Paper template and Appendix A for description.
Editor-(PERSON*): This is the person responsible for the contents of the series
Provider-(ORGANIZATION*): This is the organisation that supports the series.
Publisher-(ORGANIZATION*): This is a synonym for "provider". It is valid for historical reasons.
Notification: To specify how new papers in the series are announced.
ISSN: The International Standard Serial Number for the series, if available.
Maintainer-Email: the email address person in charge of the series' files but not necessarily of its contents. Note that this field is mandatory, the maintainer will receive mail alerting her of any errors discovered.
Maintainer-Phone: phone number of some person in charge of the series
Maintainer-Fax: phone number of some person in charge of the series
Maintainer-Name: the name of a person that is in charge of the series
Order-Email: email address where to send ordering requests to
Order-Homepage: http 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. Can be overwritten by a separate Price: field in the paper
Restriction: A restriction on the retrieval of all papers in the series. It has the same meaning as in File cluster and as in Paper template, but related to all the files of all the documents in that particular series.
Handle: The handle of the series is the name of the authority (in
our case RePEc, a : the handle of the archive, a : and
then the series_identifier. This attribute must not contain
whitespace. The series_identifier is a six letter code. It should
not have semantic contents. The series code is awarded by the archive.
Direct-Handle: The handle of another series that offers a better service about the papers in a series. This should be used if you have a large collection that comprises data about papers by institutions that directly supply data to us. In that case you wish to signal that this direct data may be available. Processing software should check if the data for the direct series is available before dropping material from the series.
Example:
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: bparks@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@ecuvax.cis.ecu.edu Handle: RePEc:wop:eakjkl
If a paper has been published in a journal, as a book or as a chapter in a book, you may wish to indicate that in the Publication-Status: field of the ReDIF-Paper template. The templates that follow are provided for archives that wish to provide more detailed information of the manifestations of a paper. We only give a summary of the meaning of the fields. Most of the fields are the same as in the ReDIF-Paper template and thus need no further explanation.
The templates in this section are considered draft templates.
An article is something that appeared in a journal or is forthcoming in a journal. This is a draft template for such publications.
Template-Type: ReDIF-Article 1.0 The template must start with this field
Other fields are like the paper template except that the following are not valid:
Length: Series: Availability: Price: Revision-Date: Article-Handle:. Of course Paper-Handle: is valid.
There are the following extra fields that the ReDIF-Article field has that are not in the ReDIF-Paper template. These are listed here.
Journal: Name of the journal, non-repeatable
Year: Year of publication, non-repeatable
Pages: Pages in journal, non-repeatable
Volume: Volume article appears in, non-repeatable
Month: Month journal issue is published, non-repeatable
Handle: Handle of journal article. required.
It is of the form
RePEc:archive_identifier:series_identifier:article_code
where archive_identifier is the 3 letter archive identifier, series_identifier is the six letter identifier of a series and :article_code is the article code. The archive identifier should be the archive where the information is kept, if that is not known put "jou".
As far as the series identifier is concerned, only series of articles are admissible here. In fact as far as ReDIF is concerned, a journal is a nothing else than a series of articles. It therefore has a series code like a paper series. It can be refereed 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 article_code is a concatenation of qualifiers, separated by the colon character. Each qualifier is an attribute:value pair. The attribute is represented by one letter only This is best understood by an example.
RePEc:xxx:joinec:v:19:y:1985:i:Q1: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.
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
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 $monthe="(jan|feb|mar|apr|may|jun|jul|aug|sep|oct|nov|dec)"
and $season="(spr|sum|aut|win|spe)"
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-611What 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.
This is a drafter template
Template-Type: ReDIF-Book 1.0 The template must start
with this field.
Title: Title of book, required, non-repeatable
Author-(PERSON*): Person cluster for each author, at least one cluster is required.
Abstract: Abstract.
Classification-scheme: non-repeatable
Keywords[-scheme]: non-repeatable
Publisher-(ORGANIZATION*): Organization cluster for Publisher, required.
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. For example Series: Springer Lecture Notes in Mathematics, volume 234
Editor-(PERSON*): Editor of series.
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
template-Handle: Handle of Paper, Article or Chapter template if published in several places.
Handle: Required. See comment for Handle: in Article template. Sune Karlsson has suggested the naming scheme RePEc:Archive:Series:boknnnn.
Required fields are Title:, Author-Name:, Handle: and Publisher-Name:. For published (as opposed to forthcoming) papers Year: is also required.
This template is for chapters with individual authors in a collection of papers. Examples are papers published in conference proceedings, reprint volumes and Festschrifts.
Template-Type: ReDIF-Chapter 1.0 The template must start with this field
Title: Title of chapter, required, non-repeatable.
Author-(PERSON*): Person cluster for each author, at least one cluster is required.
Abstract: Abstract.
Classification-scheme: non-repeatable
Keywords[-scheme]: non-repeatable
Book-Title: Title of volume, required, non-repeatable.
Editor-(PERSON*): Editor cluster for each editor, at least one cluster is required.
Year: Year of publication, required for published papers, non-repeatable.
Month: Month of publication, non-repeatable.
Pages: Pages in volume, non-repeatable.
Chapter: Chapter in volume, non-repeatable.
Volume: For multi-volume works, non-repeatable.
Edition: 2nd, 3rd etc, non-repeatable.
Series: Series that volume is part of, non-repeatable.
ISBN: ISBN of volume, non-repeatable.
Publication-Status: One of 'Published' or 'Forthcoming', non-repeatable, Published is assumed if field is not present.
Note: Any additional information.
Paper-Handle: Handle of working paper template, non- repeatable
<template>-Handle: Handle of Article, Book or Chapter handle if published in several places.
Handle: Required. Suggested scheme: RePEc:Archive:Series:chpnnn.
Required fields are Title:, Author-Name:, Book-Title:, Editor-Name:, Handle: and Provider-Name: or Sponsor-Name:. For published papers Year: is also required.
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. Publisher-Name: Dekker Publication-Status: Forthcoming Paper-Handle: RePEc:hhs:hastef:0131 Handle: RePEc:hhs:hastef:chp0131
This is a draft template.
Template-Type: ReDIF-Software 1.0 The template must start with this field
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 "stata", "Mathematica", "RATS", "GAUSS", "MATLAB", "FORTRAN", "C", "Ox" and "perl". All these identifiers are case insensitive.
Author-(PERSON*): Person cluster for each author, at least one cluster is required.
Abstract: Abstract to describe the principal function of the software.
Number: The version number of the software
Keywords: keywords for the software,
Size: size of software, usually the number of lines of code
Creation-Date: The date at which the original code 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. The notation yyyy[dd[mm]] may also be used. 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
Revision-Date: A date at which the document was changed. See previous paragraph for value format of this field - it is the same as in Creation-Date. This field may be repeated.
Revision-Date: 1995-06-30
Note: additional information
Requires: indicates that a certain package version, compiler, or operating environment is needed.
Handle: Handle, of the form RePEc:Archive:Series:Number
Required fields are Title:, Author-Name: Programming-Language: and Handle:.
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: wgould@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
This template concerns information about institutions. This information can be used in the other templates by a call to the appropriate institution handle. The template has to be in a directory called inst.
The elements of the ReDIF-Institution template
There are three types of clusters: Primary, Secondary and Tertiary. This is to take account of some institutions being subdivision of others. Examples are: University of London/London School of Economics/Financial Markets Group, Federal Reserve Bank of Minneapolis/Research Department, Government of Zambia/Ministry of Finance. These three clusters are organized like the ORGANIZATION cluster described in section 3.1, with the addition of Location and Name-English elements. An example is:
Primary-Name: Universite des Grands Espoirs Primary-Name-English: University of Grand Hopes Primary-Location: Panava-les-Flots Secondary-Name: Departement d'Economie Secondary-Name-English: Department of Economics Secondary-Email: eco@uge.edu Secondary-Homepage: http://www.eco.uge.edu/ Secondary-Phone: (+567)3466356
An additional element is:
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). Archive edi (EDIRC) already has a lot of institutional information. For updating information about an institution already listed in EDIRC, please use the same handle! Information at other archives overrides the information of the edi archive. Examples:
Handle: RePEc:edi:imfffus Handle: RePEc:edi:mofgvzm Handle: RePEc:fmg:fmlseukComplete templates may therefore read:
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
These templates are not intended for the providers of archives.
The mirror template describes what kind of mirror you are running on your machine. You are allowed to mirror any series and archive you wish. What you are mirroring is described in the mirror template. It contains information that is read by the scripts that build your mirror.
Template-type: ReDIF-Mirror 1.0 Each mirror template must
start with this declaration.
Archive-Handle: This is the archive identifier of your archive. This is a mandatory field. Each mirror must belong to an archive.
User: For Unix machines only. This is the name the user that that owns the archive. We recommend that you give that you use the name "adrepec". This is also the default username. Why the "ad" stands in front of the "repec" is a long story that does not really belong here.
Group: For Unix machines only. The name of the group of the user that that owns the archive. The default is "adrepec".
Directory: The path for the directory of the mirror on your
machine, i.e. the place where the
directories of the archives live. The path can either be the full path
or a relative path from home of the user that owns the archive. Note
that this directory is not the RePEc directory where your own archive
lives, but the place where a series of remote archive directory lives.
We recommend that this path ends with /remo.
Description: any description that you may add to the information about the mirror
Maintainer-Email: the email of somebody in charge of the mirror (mandatory)
Maintainer-Phone: phone number of some person in charge of the mirror
Maintainer-Fax: fax number of some person in charge of the mirror
Maintainer-Name: the name of a person that is in charge of the mirror.
Machine: The DNS name or number on which the mirror is running. This is a mandatory field.
The next four fields should be handled with care. At most one of them may appear.
Archives-Included: a list of archives handles that are included in the mirror. The list may be separated by any character except letters and colons. If this field does not appear, the mirror will include all archives known to RePEc. If it appears, the mirror will include only the series listed. Thus for example, if you leave that attribute blank, the mirror will mirror nothing.
Archives-Excluded: a list of archives handles that are excluded in the mirror. The list may be separated by any character except letters and colons. If this field does not appear, the mirror will include all archives known to RePEc. If it appears, the mirror will exclude the archives that are listed. Thus for example, if you leave that attribute blank, the mirror will mirror everything.
Series-Included: a list of series handles that are included in the mirror. The list may be separated by any character except letters and colons. If this field does not appear, the mirror will include all series known to RePEc. If it appears, the mirror will include only the series listed. Thus for example, if you leave that attribute blank, the mirror will mirror nothing.
Series-Excluded: a list of series handles that are excluded in the mirror. The list may be separated by any character except letters and colons. If this field does not appear, the mirror will include all archives known to RePEc. If it appears, the mirror will exclude the archives that are listed only the series listed. Thus for example, if you leave that attribute blank, the mirror will mirror everything.
ReDIF-only: This field may be used to tell mirroring software only to mirror files with the extension tt.rdf). The value of the field will be ignored. If you wish to mirror everything in an archive please do not use this field.
Examples
Template-type: ReDIF-Mirror 1.0 Archive-Handle: RePEc:jkb Machine: ftp.play.edu User: adrepec Group: users Directory: RePEc/remo Location: Southern Playland Description: Small mirror of two game theory series Maintainer-Email: J.von.Neumann@smart.edu Series-Included: RePEc:bon:bonsfa RePEc:bob:wuwpga Template-type: ReDIF-Mirror 1.0 Archive-Handle: RePEc:sur Machine: gretel.econ.surrey.ac.uk Description: A full mirror on a private machine User: adrepec Group: users Directory: /usr/local/ftp/pub/RePEc/remo Location: Guildford, Surrey, England Maintainer-Name: Thomas Krichel Maintainer-Email: T.Krichel@surrey.ac.uk
This is a draft template.
Template-type: ReDIF-Mirror 1.0 Each authority template must
start with this declaration.
Url: The url where the authority is based. Required
Handle: The handle of the authority. Required
Examples
Template-type: ReDIF-Authority 1.0 Url: http://netec.mcc.ac.uk/pub/RePEc Handle: RePEc
Some metadata relating to preprints contain information on where the paper has been published. If a complete record for this instance is provided by the publisher of the formal channel, a link to that record may be included in the paper. However in most cases only partial and non-authoritative information about this instance in available. If that data is just a chain of characters, the Publication-Status field can be used. If that data is itself fielded, the MANIFESTATION cluster should be used.
Any instance where the resource or something very similar is formally published is called a manifestation of the resource. The manifestation cluster is used to deal with that.
Type: Each manifestation template must start with this field. This field has a controlled vocabulary. It can take the following values.
| value | explanation |
prar |
Published refereed journal article |
puar |
Published unrefereed journal article |
pboc |
Published book chapter |
pcpa |
Published conference paper |
pcpo |
Published conference poster |
frar |
Refereed journal article in press |
fboc |
Book chapter in press |
fcpa |
Refereed conference paper in press |
aupa |
Author archived Unrefereed paper |
dupa |
Departmental archive unrefereed report |
cupa |
Unpublished conference paper |
cupo |
Unpublished conference poster |
pnew |
Published Newspaper/magazine article |
Date: A date associated with the manifestation
Title: The title of the manifestation. This should be similar to but not necessarily identical with the title of the resource.
Pages: The pagination of the manifestation, of the form number of the first page - number of the last page.
Publisher-ORGANIZATION: The publisher of the manifestation, an organization cluster.
Conference-Date: the date of the conference where the manifestation was presented. It must be of the form yyyy-mm-dd-yyyy-mm-dd. Dates may be of a simpler form like "1999", only the first yyyy is required.
Conference-Title: The title of the conference.
Conference-Location The location of the conference.
Conference-Editor-PERSON: A person cluster for each editor of the conference proceedings.
Journal-Title: The title of the journal in which the manifestation appeared.
Journal-Volume: The volume of the journal in which the manifestation appeared.
Journal-Year: The volume of the journal in which the manifestation appeared.
Journal-editor-PERSON: Personal data for the editor of the journal where the manifestation appeared.
Book-Chapter: a free text indication about the chapter in the book the manifestation corresponds to.
Book-Volume The volume of the book, independly if the manifestation is a chapter in the book or the book itself
Book-Editor-PERSON: This is personal data for the editor of the book where the chapter was produced.
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-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-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-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-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.
Attent: This is a thesaurus (list of controlled keywords) which was used for a database "Attent: Research Memoranda". This database, as well as the thesaurus, is produced and maintained by Tilburg University Library. "Attent: Research Memoranda" only includes economic working papers. The thesaurus includes economic and mathematical keywords. For further details contact Corry Stuyts <C.Styuts@kub.nl>.