RFC1807 日本語訳
1807 A Format for Bibliographic Records. R. Lasher, D. Cohen. June 1995. (Format: TXT=29417 bytes) (Obsoletes RFC1357) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Lasher
Request For Comments: 1807 Stanford
Obsoletes: 1357 D. Cohen
Category: Informational Myricom
June 1995
Network Working Group R. Lasher Request For Comments: 1807 Stanford Obsoletes: 1357 D. Cohen Category: Informational Myricom June 1995
A Format for Bibliographic Records
A Format for Bibliographic Records
Status of this Memo
Status of this Memo
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Abstract
Abstract
This RFC defines a format for bibliographic records describing technical reports. This format is used by the Cornell University Dienst protocol and the Stanford University SIFT system. The original RFC (RFC 1357) was written by D. Cohen, ISI, July 1992. This is a revision of RFC 1357. New fields include handle, other_access, keyword, and withdraw.
This RFC defines a format for bibliographic records describing technical reports. This format is used by the Cornell University Dienst protocol and the Stanford University SIFT system. The original RFC (RFC 1357) was written by D. Cohen, ISI, July 1992. This is a revision of RFC 1357. New fields include handle, other_access, keyword, and withdraw.
Introduction
Introduction
Many universities and other R&D organizations routinely announce new technical reports by mailing (via the postal services) the bibliographic records of these reports.
Many universities and other R&D organizations routinely announce new technical reports by mailing (via the postal services) the bibliographic records of these reports.
These mailings have non-trivial cost and delay. In addition, their recipients cannot conveniently file them, electronically, for later retrieval and searches.
These mailings have non-trivial cost and delay. In addition, their recipients cannot conveniently file them, electronically, for later retrieval and searches.
Publishing organizations that wish to use e-mail or file transfer to obtain these announcements can do so by using the following format.
Publishing organizations that wish to use e-mail or file transfer to obtain these announcements can do so by using the following format.
Organizations may automate to any degree (or not at all) both the creation of these records (about their own publications) and the handling of the records received from other organizations.
Organizations may automate to any degree (or not at all) both the creation of these records (about their own publications) and the handling of the records received from other organizations.
This format is designed to be simple, for people and for machines, to
be easy to read ("human readable") and create without any special
programs.
This format is designed to be simple, for people and for machines, to be easy to read ("human readable") and create without any special programs.
This RFC defines the format of bibliographic records, not how to process them.
This RFC defines the format of bibliographic records, not how to process them.
Lasher & Cohen Informational [Page 1] RFC 1807 A Format for Bibliographic Records June 1995
Lasher & Cohen Informational [Page 1] RFC 1807 A Format for Bibliographic Records June 1995
This format is a "tagged" format with self-explaining alphabetic tags. It should be possible to prepare and to read bibliographic records using any text editor, without any special programs.
This format is a "tagged" format with self-explaining alphabetic tags. It should be possible to prepare and to read bibliographic records using any text editor, without any special programs.
This RFC includes the CR-CATEGORY, a field useful for Computer Science publications. It is expected that similar fields will be added for other domains.
This RFC includes the CR-CATEGORY, a field useful for Computer Science publications. It is expected that similar fields will be added for other domains.
This format, as described in RFC 1357, was implemented as part of the Dienst system and has been in use by the five ARPA-funded computer science institutions to exchange bibliographic records (Cornell, SU, UC, MIT, and CMU). Programs have been written to map between this RFC and structured USMARC (format developed at the Library of Congress) cataloging records, also from USMARC to the RFC.
This format, as described in RFC 1357, was implemented as part of the Dienst system and has been in use by the five ARPA-funded computer science institutions to exchange bibliographic records (Cornell, SU, UC, MIT, and CMU). Programs have been written to map between this RFC and structured USMARC (format developed at the Library of Congress) cataloging records, also from USMARC to the RFC.
The focus of this ARPA-funded research has been into many aspects of digital libraries including searching and accessing techniques that do not necessarily use bibliographic records (for example, natural language processing, automatic and full-text indexing). However, the continued use of bibliographic records is expected to remain an important part of the library system environment of the future and its use is an important link between the physical world of scientific works and the on-line world of digital objects. The format described in this paper allows a link between these two worlds to be created.
The focus of this ARPA-funded research has been into many aspects of digital libraries including searching and accessing techniques that do not necessarily use bibliographic records (for example, natural language processing, automatic and full-text indexing). However, the continued use of bibliographic records is expected to remain an important part of the library system environment of the future and its use is an important link between the physical world of scientific works and the on-line world of digital objects. The format described in this paper allows a link between these two worlds to be created.
This format was developed with considerable help and involvement of Computer Science and Library personnel from several organizations, including Carnegie Mellon University, Corporation for National Research Initiatives (CNRI), Cornell University, University of Southern California/Information Sciences Institute (ISI), Meridian (now called DynCorp), Massachusetts Institute of Technology, Stanford University, and the University of California. Key contributions were provided by Jerry Saltzer of MIT, and Larry Lannom of DynCorp. The initial draft was prepared by Danny Cohen and Larry Miller of ISI. The revision was done by Rebecca Lasher from Stanford with assistance from the CS-TR participants.
This format was developed with considerable help and involvement of Computer Science and Library personnel from several organizations, including Carnegie Mellon University, Corporation for National Research Initiatives (CNRI), Cornell University, University of Southern California/Information Sciences Institute (ISI), Meridian (now called DynCorp), Massachusetts Institute of Technology, Stanford University, and the University of California. Key contributions were provided by Jerry Saltzer of MIT, and Larry Lannom of DynCorp. The initial draft was prepared by Danny Cohen and Larry Miller of ISI. The revision was done by Rebecca Lasher from Stanford with assistance from the CS-TR participants.
This RFC does not place any limitations on the dissemination of the bibliographic records. If there are limitations on the dissemination of the publication, it should be protected by some means such as passwords. This RFC does not address this protection.
This RFC does not place any limitations on the dissemination of the bibliographic records. If there are limitations on the dissemination of the publication, it should be protected by some means such as passwords. This RFC does not address this protection.
The use of this format is encouraged. There are no limitations on its use.
The use of this format is encouraged. There are no limitations on its use.
Lasher & Cohen Informational [Page 2] RFC 1807 A Format for Bibliographic Records June 1995
Lasher & Cohen Informational [Page 2] RFC 1807 A Format for Bibliographic Records June 1995
The Information Fields
The Information Fields
The various fields should follow the format described below.
The various fields should follow the format described below.
<M> means Mandatory; a record without it is invalid. <O> means Optional.
<M> means Mandatory; a record without it is invalid. <O> means Optional.
The tags (aka Field-IDs) are shown in upper case.
The tags (aka Field-IDs) are shown in upper case.
<M> BIB-VERSION of this bibliographic records format
<M> ID
<M> ENTRY date
<O> ORGANIZATION
<O> TITLE
<O> TYPE
<O> REVISION
<O> WITHDRAW
<O> AUTHOR
<O> CORP-AUTHOR
<O> CONTACT for the author(s)
<O> DATE of publication
<O> PAGES count
<O> COPYRIGHT, permissions and disclaimers
<O> HANDLE
<O> OTHER_ACCESS
<O> RETRIEVAL
<O> KEYWORD
<O> CR-CATEGORY
<O> PERIOD
<O> SERIES
<O> MONITORING organization(s)
<O> FUNDING organization(s)
<O> CONTRACT number(s)
<O> GRANT number(s)
<O> LANGUAGE name
<O> NOTES
<O> ABSTRACT
<M> END
<M> BIB-VERSION of this bibliographic records format <M> ID <M> ENTRY date <O> ORGANIZATION <O> TITLE <O> TYPE <O> REVISION <O> WITHDRAW <O> AUTHOR <O> CORP-AUTHOR <O> CONTACT for the author(s) <O> DATE of publication <O> PAGES count <O> COPYRIGHT, permissions and disclaimers <O> HANDLE <O> OTHER_ACCESS <O> RETRIEVAL <O> KEYWORD <O> CR-CATEGORY <O> PERIOD <O> SERIES <O> MONITORING organization(s) <O> FUNDING organization(s) <O> CONTRACT number(s) <O> GRANT number(s) <O> LANGUAGE name <O> NOTES <O> ABSTRACT <M> END
Lasher & Cohen Informational [Page 3] RFC 1807 A Format for Bibliographic Records June 1995
Lasher & Cohen Informational [Page 3] RFC 1807 A Format for Bibliographic Records June 1995
Meta Format
Meta Format
* Keep It Simple.
* Keep It Simple.
* One bibliographic record for each publication, where a
"publication" is whatever the publishing institution
defines as such.
* One bibliographic record for each publication, where a "publication" is whatever the publishing institution defines as such.
* A record contains several fields.
* A record contains several fields.
* Each field starts with its tag (aka the field-ID) which is a
reserved identifier (containing no separators) at the
beginning of a new line with or without spaces before it),
followed by two colons ("::"), followed by the field data.
* Each field starts with its tag (aka the field-ID) which is a reserved identifier (containing no separators) at the beginning of a new line with or without spaces before it), followed by two colons ("::"), followed by the field data.
* Continuation lines: Lines are limited to 79 characters.
When needed, fields may continue over several lines, with an
implied space in between. In order to simplify the use no
special marking is used to indicate continuation line.
Hence, fields are terminated by a line that starts (apart
from white space) with a word followed by two colons. Except
for the "END::" that is terminated by the end of line.) For
improved human readability it is suggested to start
continuation lines with some spaces.
* Continuation lines: Lines are limited to 79 characters. When needed, fields may continue over several lines, with an implied space in between. In order to simplify the use no special marking is used to indicate continuation line. Hence, fields are terminated by a line that starts (apart from white space) with a word followed by two colons. Except for the "END::" that is terminated by the end of line.) For improved human readability it is suggested to start continuation lines with some spaces.
* Several fields are mandatory and must appear in the record.
All fields (unless specifically not permitted to) may be in
any order and may be repeated as needed (e.g., the AUTHOR
field). The order of the repeated fields is always
preserved.
* Several fields are mandatory and must appear in the record. All fields (unless specifically not permitted to) may be in any order and may be repeated as needed (e.g., the AUTHOR field). The order of the repeated fields is always preserved.
* Only printable ASCII characters are to be used. The permissible
characters are ASCII codes 040 (Space) through 176(~)
and line breaks which are %%BODY%%12 (LF) or %%BODY%%12%%BODY%%15 (CRLF).
Empty lines indicate paragraph break. %%BODY%%09 (tab) must be
replaced by spaces. This specifically forbids tabs, null
characters, DEL, backspaces, etc. (i.e., if used, the record is
invalid.)
* Only printable ASCII characters are to be used. The permissible characters are ASCII codes 040 (Space) through 176(~) and line breaks which are %%BODY%%12 (LF) or %%BODY%%12%%BODY%%15 (CRLF). Empty lines indicate paragraph break. %%BODY%%09 (tab) must be replaced by spaces. This specifically forbids tabs, null characters, DEL, backspaces, etc. (i.e., if used, the record is invalid.)
However full 8 bit ASCII may be used. WARNING: some
electronic mailers cannot handle 8 bit ASCII and these
records may need to be transported via other mechanisms.
However full 8 bit ASCII may be used. WARNING: some electronic mailers cannot handle 8 bit ASCII and these records may need to be transported via other mechanisms.
Throughout this document the word "publisher" means the
publishing organization of a report (e.g., a university or a
department thereof), not necessarily an organization authorized
to issue ISBN numbers.
Throughout this document the word "publisher" means the publishing organization of a report (e.g., a university or a department thereof), not necessarily an organization authorized to issue ISBN numbers.
Lasher & Cohen Informational [Page 4] RFC 1807 A Format for Bibliographic Records June 1995
Lasher & Cohen Informational [Page 4] RFC 1807 A Format for Bibliographic Records June 1995
EXAMPLE
-------------------------------------------------------------
BIB-VERSION:: CS-TR-v2.1
ID:: OUKS//CS-TR-91-123
ENTRY:: January 15, 1992
ORGANIZATION:: Oceanview University, Kansas, Computer Science
TYPE:: Technical Report
REVISION:: January 5, 1995; FTP access information added
TITLE:: Scientific Communication must be timely
AUTHOR:: Finnegan, James A.
CONTACT:: Prof. J. A. Finnegan, CS Dept, Oceanview Univ,
Oceanview, KS 54321 Tel: 913-456-7890
<Finnegan@cs.ouks.edu>
AUTHOR:: Pooh, Winnie The
CONTACT:: 100 Aker Wood
DATE:: December 1991
PAGES:: 48
COPYRIGHT:: Copyright for the report (c) 1991, by J. A.
Finnegan. All rights reserved. Permission is granted
for any academic use of the report.
HANDLE:: hdl:oceanview.electr/CS-TR-91-123
OTHER_ACCESS:: url:http://electr.oceanview.edu/CS-TR-91-123
OTHER_ACCESS:: url:ftp://electr.oceanview.edu/CS-TR-91-123
RETRIEVAL:: send email to Finnegan@cs.ouks.edu with fax number
KEYWORD:: Scientific Communication
CR-CATEGORY:: D.0
CR-CATEGORY:: C.2.2 Computer Sys Org, Communication nets, Net
Protocols
SERIES:: Communication
FUNDING:: FAS
CONTRACT:: FAS-91-C-1234
MONITORING:: FNBO
LANGUAGE:: English
NOTES:: This report is the full version of the paper with
the same title in IEEE Trans ASSP Dec 1976
ABSTRACT::
EXAMPLE ------------------------------------------------------------- BIB-VERSION:: CS-TR-v2.1 ID:: OUKS//CS-TR-91-123 ENTRY:: January 15, 1992 ORGANIZATION:: Oceanview University, Kansas, Computer Science TYPE:: Technical Report REVISION:: January 5, 1995; FTP access information added TITLE:: Scientific Communication must be timely AUTHOR:: Finnegan, James A. CONTACT:: Prof. J. A. Finnegan, CS Dept, Oceanview Univ, Oceanview, KS 54321 Tel: 913-456-7890 <Finnegan@cs.ouks.edu> AUTHOR:: Pooh, Winnie The CONTACT:: 100 Aker Wood DATE:: December 1991 PAGES:: 48 COPYRIGHT:: Copyright for the report (c) 1991, by J. A. Finnegan. All rights reserved. Permission is granted for any academic use of the report. HANDLE:: hdl:oceanview.electr/CS-TR-91-123 OTHER_ACCESS:: url:http://electr.oceanview.edu/CS-TR-91-123 OTHER_ACCESS:: url:ftp://electr.oceanview.edu/CS-TR-91-123 RETRIEVAL:: send email to Finnegan@cs.ouks.edu with fax number KEYWORD:: Scientific Communication CR-CATEGORY:: D.0 CR-CATEGORY:: C.2.2 Computer Sys Org, Communication nets, Net Protocols SERIES:: Communication FUNDING:: FAS CONTRACT:: FAS-91-C-1234 MONITORING:: FNBO LANGUAGE:: English NOTES:: This report is the full version of the paper with the same title in IEEE Trans ASSP Dec 1976 ABSTRACT::
Many alchemists in the country work on important fusion problems. All of them cooperate and interact with each other through the scientific literature. This scientific communication methodology has many advantages. Timeliness is not one of them.
Many alchemists in the country work on important fusion problems. All of them cooperate and interact with each other through the scientific literature. This scientific communication methodology has many advantages. Timeliness is not one of them.
END:: OUKS//CS-TR-91-123 ---------------------------- End of Example -------------------
END:: OUKS//CS-TR-91-123 ---------------------------- End of Example -------------------
For reference, the above example has about 1,689 characters (184 words) including about 249 characters (36 words) in the abstract.
For reference, the above example has about 1,689 characters (184 words) including about 249 characters (36 words) in the abstract.
Lasher & Cohen Informational [Page 5] RFC 1807 A Format for Bibliographic Records June 1995
Lasher & Cohen Informational [Page 5] RFC 1807 A Format for Bibliographic Records June 1995
The Actual Format
The Actual Format
The term "Open Ended Format" in the following means arbitrary text.
The term "Open Ended Format" in the following means arbitrary text.
In the following double-quotes indicate complete strings. They are included only for grouping and are not expected to be used in the actual records.
In the following double-quotes indicate complete strings. They are included only for grouping and are not expected to be used in the actual records.
The BIB-VERSION, ID, ENTRY, and END field must appear as the first, second, third, and last fields, and may not be repeated in the record. All other fields may be repeated as needed.
The BIB-VERSION, ID, ENTRY, and END field must appear as the first, second, third, and last fields, and may not be repeated in the record. All other fields may be repeated as needed.
BIB-VERSION (M) -- This is the first field of any record. It is a
mandatory field. It identifies the version of the format
used to create this bibliographic record. This RFC defines
BIB-Version TR-v2.1
BIB-VERSION (M) -- This is the first field of any record. It is a mandatory field. It identifies the version of the format used to create this bibliographic record. This RFC defines BIB-Version TR-v2.1
BIB-VERSIONs that start with the letter X (case
independent) are considered experimental. Bib-records
sent with such a BIB-VERSION should NOT be incorporated
in the permanent database of the recipient.
BIB-VERSIONs that start with the letter X (case independent) are considered experimental. Bib-records sent with such a BIB-VERSION should NOT be incorporated in the permanent database of the recipient.
Using this version of this format, this field is always:
Using this version of this format, this field is always:
Format: BIB-VERSION:: CS-TR-v2.1
Format: BIB-VERSION:: CS-TR-v2.1
ID (M) -- This is the second field of any record. It is also a
mandatory field. The ID field identifies the bibliographic
record and is used in management of these records.
Its format is "ID:: XXX//YYY", where XXX is the
publisher-ID (the controlled symbol of the publisher)
and YYY is the ID (e.g., report number) of the
publication as assigned by the publisher. This ID is
typically printed on the cover, and may contain slashes.
ID (M) -- This is the second field of any record. It is also a mandatory field. The ID field identifies the bibliographic record and is used in management of these records. Its format is "ID:: XXX//YYY", where XXX is the publisher-ID (the controlled symbol of the publisher) and YYY is the ID (e.g., report number) of the publication as assigned by the publisher. This ID is typically printed on the cover, and may contain slashes.
The organization symbols "DUMMY" and "TEST" (case
independent) are reserved for test records that should NOT
be incorporated in the permanent database of the
recipients.
The organization symbols "DUMMY" and "TEST" (case independent) are reserved for test records that should NOT be incorporated in the permanent database of the recipients.
Format: ID:: <publisher-ID>//<free-text>
Format: ID:: <publisher-ID>//<free-text>
Example: ID:: OUKS//CS-TR-91-123
Example: ID:: OUKS//CS-TR-91-123
**** See the note at the end regarding the ****
**** controlled symbols of the publishers *****
**** See the note at the end regarding the **** **** controlled symbols of the publishers *****
Lasher & Cohen Informational [Page 6] RFC 1807 A Format for Bibliographic Records June 1995
Lasher & Cohen Informational [Page 6] RFC 1807 A Format for Bibliographic Records June 1995
ENTRY (M) -- This is a mandatory field. It is the date of
creating this bibliographic record.
ENTRY (M) -- This is a mandatory field. It is the date of creating this bibliographic record.
The format for ENTRY date is "Month Day, Year". The
month must be alphabetic (spelled out). The "Day" is a
1- or 2-digit number. The "Year" is a 4-digit number.
The format for ENTRY date is "Month Day, Year". The month must be alphabetic (spelled out). The "Day" is a 1- or 2-digit number. The "Year" is a 4-digit number.
Format: ENTRY:: <date>
Format: ENTRY:: <date>
Example: ENTRY:: January 15, 1992
Example: ENTRY:: January 15, 1992
ORGANIZATION (O) -- It is the full name spelled out (no acronyms,
please) of the publishing organization. The use of this
name is controlled together with the controlled symbol of
the publisher (as discussed above for the ID field).
ORGANIZATION (O) -- It is the full name spelled out (no acronyms, please) of the publishing organization. The use of this name is controlled together with the controlled symbol of the publisher (as discussed above for the ID field).
Avoid acronyms because there are many common acronyms,
such as ISI and USC. Please provide it in ascending
order, such as "X University, Y Department" (not "Y
Department, X University").
Avoid acronyms because there are many common acronyms, such as ISI and USC. Please provide it in ascending order, such as "X University, Y Department" (not "Y Department, X University").
Format: ORGANIZATION:: <free-text>
Example: ORGANIZATION:: Stanford University, Department of
Computer Science
Format: ORGANIZATION:: <free-text> Example: ORGANIZATION:: Stanford University, Department of Computer Science
TITLE (O) -- This is the title of the work as assigned by the
author. This field should include the complete title with
all the subtitles, if any.
TITLE (O) -- This is the title of the work as assigned by the author. This field should include the complete title with all the subtitles, if any.
Format: TITLE:: <free-text>
Format: TITLE:: <free-text>
Example: TITLE:: The Computerization of Oceanview with
High Speed Fiber Optics Communication
Example: TITLE:: The Computerization of Oceanview with High Speed Fiber Optics Communication
TYPE (O) -- Indicates the type of publication (summary, final
project report, etc.) as assigned by the issuing
organization.
TYPE (O) -- Indicates the type of publication (summary, final project report, etc.) as assigned by the issuing organization.
Format: TYPE:: <free-text>
Format: TYPE:: <free-text>
Example: TYPE:: Technical Report
Example: TYPE:: Technical Report
REVISION (O) -- Indicates that the current bibliographic record is
a revision of a previously issued record and is intended
REVISION (O) -- Indicates that the current bibliographic record is a revision of a previously issued record and is intended
Lasher & Cohen Informational [Page 7] RFC 1807 A Format for Bibliographic Records June 1995
Lasher & Cohen Informational [Page 7] RFC 1807 A Format for Bibliographic Records June 1995
to replace it. Revision information consists of a date
and/or followed by a semicolon and by text in an open
ended format. The revised bibliographic record should
contain a complete record for the publication, not just a
list of changes to the old record. If revision is
omitted, the record is assumed to be a new record and not
a revision. If the revision date is specified as 0, this
is assumed to be January 1, 1900 (the previous RFC, used
revision data of 0, 1, 2, 3, etc. this specification is for
programs that might process records from RFC1357).
to replace it. Revision information consists of a date and/or followed by a semicolon and by text in an open ended format. The revised bibliographic record should contain a complete record for the publication, not just a list of changes to the old record. If revision is omitted, the record is assumed to be a new record and not a revision. If the revision date is specified as 0, this is assumed to be January 1, 1900 (the previous RFC, used revision data of 0, 1, 2, 3, etc. this specification is for programs that might process records from RFC1357).
The text before the semicolon in this field is a date of
the form month day, year. Any record with a more recent
revision date replaces completely any record with an
earlier revision date (supplied either explicitly or by
default). Use the text to describe the revision.
Reasons to send out a revised record include an error in
the original, or change in the access information.
The text before the semicolon in this field is a date of the form month day, year. Any record with a more recent revision date replaces completely any record with an earlier revision date (supplied either explicitly or by default). Use the text to describe the revision. Reasons to send out a revised record include an error in the original, or change in the access information.
Format: REVISION:: January 1, 1995; <free-text>
Format: REVISION:: January 1, 1995; <free-text>
Example: REVISION:: January 1, 1995; FTP information
added
Example: REVISION:: January 1, 1995; FTP information added
WITHDRAW (O) Withdraw means the document is no longer
available. Some Institutions choose to delete the record
others remove some of the fields. It is up to each
institution to decide how to process withdraw records.
WITHDRAW (O) Withdraw means the document is no longer available. Some Institutions choose to delete the record others remove some of the fields. It is up to each institution to decide how to process withdraw records.
A withdraw record has all of the mandatory fields plus the
withdraw field and a mandatory revision field.
The Withdraw field should indicate the reason for the
withdraw in free text.
Example for withdrawing a bibliographic record::
A withdraw record has all of the mandatory fields plus the withdraw field and a mandatory revision field. The Withdraw field should indicate the reason for the withdraw in free text. Example for withdrawing a bibliographic record::
BIB-VERSION:: CS-TR-v2.1
ID:: OUKS//CS-TR-91-123
ENTRY:: January 21, 1995
ORGANIZATION:: Oceanview University, Kansas, Computer
Science
TITLE:: The Computerization of Oceanview with
High Speed Fiber Optics Communication
REVISION:: January 21, 1995
WITHDRAW:: Withdrawn, found to be irrelevant
END:: OUKS//CS-TR-91-123
BIB-VERSION:: CS-TR-v2.1 ID:: OUKS//CS-TR-91-123 ENTRY:: January 21, 1995 ORGANIZATION:: Oceanview University, Kansas, Computer Science TITLE:: The Computerization of Oceanview with High Speed Fiber Optics Communication REVISION:: January 21, 1995 WITHDRAW:: Withdrawn, found to be irrelevant END:: OUKS//CS-TR-91-123
Lasher & Cohen Informational [Page 8] RFC 1807 A Format for Bibliographic Records June 1995
Lasher & Cohen Informational [Page 8] RFC 1807 A Format for Bibliographic Records June 1995
AUTHOR (O) -- Personal names only. Normal last name first
inversion. Editors should be listed here as well,
identified with the usual "(ed.)" as shown below in the last
example.
AUTHOR (O) -- Personal names only. Normal last name first inversion. Editors should be listed here as well, identified with the usual "(ed.)" as shown below in the last example.
If the report was not authored by a person (e.g., it was
authored by a committee or a panel) use CORP-AUTHOR (see
below) instead of AUTHOR.
If the report was not authored by a person (e.g., it was authored by a committee or a panel) use CORP-AUTHOR (see below) instead of AUTHOR.
Multiple authors are entered by using multiple lines, each
in the form of "AUTHOR:: <free-text>".
Multiple authors are entered by using multiple lines, each in the form of "AUTHOR:: <free-text>".
The system preserves the order of the authors.
The system preserves the order of the authors.
Format: AUTHOR:: <free-text>
Format: AUTHOR:: <free-text>
Example: AUTHOR:: Finnegan, James A.
AUTHOR:: Pooh, Winnie The
AUTHOR:: Lastname, Firstname (ed.)
Example: AUTHOR:: Finnegan, James A. AUTHOR:: Pooh, Winnie The AUTHOR:: Lastname, Firstname (ed.)
CORP-AUTHOR (O) -- The corporate author (e.g., a committee or a
panel) that authored the report, which may be different
from the ORGANIZATION issuing the report.
CORP-AUTHOR (O) -- The corporate author (e.g., a committee or a panel) that authored the report, which may be different from the ORGANIZATION issuing the report.
In entering the corporate name please omit initial "the"
or "a". If it is really part of the name, please invert it.
In entering the corporate name please omit initial "the" or "a". If it is really part of the name, please invert it.
Format: CORP-AUTHOR:: <free-text>
Format: CORP-AUTHOR:: <free-text>
Example: CORP-AUTHOR:: Committee on long-range computing
Example: CORP-AUTHOR:: Committee on long-range computing
CONTACT (O) -- The contact for the author(s).
Open-ended, most likely E-mail and postal addresses.
CONTACT (O) -- The contact for the author(s). Open-ended, most likely E-mail and postal addresses.
A CONTACT field for each author should be provided,
separately, or for all the AUTHOR fields.
E-mail addresses should always be in "pointy brackets"
(as in the example below).
A CONTACT field for each author should be provided, separately, or for all the AUTHOR fields. E-mail addresses should always be in "pointy brackets" (as in the example below).
Format: CONTACT:: <free-text>
Format: CONTACT:: <free-text>
Example: CONTACT:: Prof. J. A. Finnegan, CS Dept,
Oceanview Univ., Oceanview, Kansas, 54321
Tel: 913-456-7890 <Finnegan@cs.ouks.edu>
Example: CONTACT:: Prof. J. A. Finnegan, CS Dept, Oceanview Univ., Oceanview, Kansas, 54321 Tel: 913-456-7890 <Finnegan@cs.ouks.edu>
Lasher & Cohen Informational [Page 9] RFC 1807 A Format for Bibliographic Records June 1995
Lasher & Cohen Informational [Page 9] RFC 1807 A Format for Bibliographic Records June 1995
DATE (O) -- The publication date. The formats are "Month Year"
and "Month Day, Year". The month must be alphabetic
(spelled out). The "Day" is a 1- or 2-digit number. The
"Year" is a 4- digit number.
DATE (O) -- The publication date. The formats are "Month Year" and "Month Day, Year". The month must be alphabetic (spelled out). The "Day" is a 1- or 2-digit number. The "Year" is a 4- digit number.
Format: DATE:: <date>
Format: DATE:: <date>
Example: DATE:: January 1992
Example: DATE:: January 15, 1992
Example: DATE:: January 1992 Example: DATE:: January 15, 1992
PAGES (O) -- Total number of pages, without being too picky about
it. Final numbered page is actually preferred, if it is a
reasonable approximation to the total number of pages.
PAGES (O) -- Total number of pages, without being too picky about it. Final numbered page is actually preferred, if it is a reasonable approximation to the total number of pages.
Format: PAGES:: <number>
Format: PAGES:: <number>
Example: PAGES:: 48
Example: PAGES:: 48
COPYRIGHT (O) -- Copyright information. Open ended format. The
COPYRIGHT field applies to the cited report, rather than
to the current bibliographic record.
COPYRIGHT (O) -- Copyright information. Open ended format. The COPYRIGHT field applies to the cited report, rather than to the current bibliographic record.
Format: COPYRIGHT:: <free-text>
Format: COPYRIGHT:: <free-text>
Example: COPYRIGHT:: Copyright for the report (c) 1991,
by J. A. Finnegan. All rights
reserved.
Permission is granted for any academic
use of the report.
Example: COPYRIGHT:: Copyright for the report (c) 1991, by J. A. Finnegan. All rights reserved. Permission is granted for any academic use of the report.
HANDLE (O) -- Handles are unique permanent identifiers that are
used in the Handle Management System to retrieve location
data. A handle is a printable string which when given to
a handle server returns the location of the data.
HANDLE (O) -- Handles are unique permanent identifiers that are used in the Handle Management System to retrieve location data. A handle is a printable string which when given to a handle server returns the location of the data.
Handles are used to identify digital objects stored within
a digital library. If the technical report is available in
electronic form, the Handle MUST be supplied in the
bibliographic record.
Handles are used to identify digital objects stored within a digital library. If the technical report is available in electronic form, the Handle MUST be supplied in the bibliographic record.
Format is "HANDLE:: hdl:<naming authority>/string
of characters". The string of characters can be the
report number of the technical report as assigned by the
publisher. For more information on handles and handle
servers see the CNRI WEB page at
Format is "HANDLE:: hdl:<naming authority>/string of characters". The string of characters can be the report number of the technical report as assigned by the publisher. For more information on handles and handle servers see the CNRI WEB page at
Lasher & Cohen Informational [Page 10] RFC 1807 A Format for Bibliographic Records June 1995
Lasher & Cohen Informational [Page 10] RFC 1807 A Format for Bibliographic Records June 1995
http://www.cnri.reston.va.us.
http://www.cnri.reston.va.us.
**** NOTE: White space in HANDLE due to line wrap is ignored.
**** NOTE: White space in HANDLE due to line wrap is ignored.
Format: HANDLE:: hdl:<naming authority>/string of
characters
Format: HANDLE:: hdl:<naming authority>/string of characters
Example: HANDLE:: hdl:oceanview.electr/CS-TR-91-123
Example: HANDLE:: hdl:oceanview.electr/CS-TR-91-123
OTHER_ACCESS (O) -- For URLs, URNs, and other yet to be invented
formatted retrieval systems.
OTHER_ACCESS (O) -- For URLs, URNs, and other yet to be invented formatted retrieval systems.
Only one URL or URN per occurrence of the field.
Only one URL or URN per occurrence of the field.
URL and URN information is available in the internet
drafts from the IETF (Internet Engineering Task Force).
The most recent drafts can be found on the CNRI WEB page
at http://www.cnri.reston.va.us.
URL and URN information is available in the internet drafts from the IETF (Internet Engineering Task Force). The most recent drafts can be found on the CNRI WEB page at http://www.cnri.reston.va.us.
**** NOTE: White space in a URL or URN due to line wrap is ignored.
**** NOTE: White space in a URL or URN due to line wrap is ignored.
Format: OTHER_ACCESS:: URL:<URL>
OTHER_ACCESS:: URN:<URN>
Format: OTHER_ACCESS:: URL:<URL> OTHER_ACCESS:: URN:<URN>
Example: OTHER_ACCESS:: URL:http://elib.stanford.edu/Docume
nt/STANFORD.CS:CS-TN-94-1
Example: OTHER_ACCESS:: URL:http://elib.stanford.edu/Docume nt/STANFORD.CS:CS-TN-94-1
Example: OTHER_ACCESS:: URL:ftp://JUPITER.CS.OUKS.EDU/PUBS/
computerization.txt.
Example: OTHER_ACCESS:: URL:ftp://JUPITER.CS.OUKS.EDU/PUBS/ computerization.txt.
When the URN standard is finalized naming authorities will
be registered and URNs will be viable unique identifiers.
Until then this is a place holder. For the latest URN
drafts see CNRI WEB page at http://www.cnri.reston.va.us.
When the URN standard is finalized naming authorities will be registered and URNs will be viable unique identifiers. Until then this is a place holder. For the latest URN drafts see CNRI WEB page at http://www.cnri.reston.va.us.
RETRIEVAL (O) -- Open-ended format describing how to get
a copy of the full text. This is an optional, repeatable
field.
RETRIEVAL (O) -- Open-ended format describing how to get a copy of the full text. This is an optional, repeatable field.
No limitations are placed on the dissemination of the
bibliographic records. If there are limitations on the
dissemination of the publication, it should be protected
by some means such as passwords. This format does not
address this protection.
No limitations are placed on the dissemination of the bibliographic records. If there are limitations on the dissemination of the publication, it should be protected by some means such as passwords. This format does not address this protection.
Format: RETRIEVAL:: <free-text>
Format: RETRIEVAL:: <free-text>
Lasher & Cohen Informational [Page 11] RFC 1807 A Format for Bibliographic Records June 1995
Lasher & Cohen Informational [Page 11] RFC 1807 A Format for Bibliographic Records June 1995
RETRIEVAL:: for full text with color pictures
send a self-addressed stamped envelope to
Prof. J.A. Finnegan, CS Dept,
Oceanview University, Oceanview, KS 54321
RETRIEVAL:: for full text with color pictures send a self-addressed stamped envelope to Prof. J.A. Finnegan, CS Dept, Oceanview University, Oceanview, KS 54321
KEYWORD (O) -- Specify any keywords, controlled or uncontrolled.
This is an optional, repeatable field. Multiple keywords
are entered using multiple lines in the form of
"KEYWORD:: <free-text>.
KEYWORD (O) -- Specify any keywords, controlled or uncontrolled. This is an optional, repeatable field. Multiple keywords are entered using multiple lines in the form of "KEYWORD:: <free-text>.
Format: KEYWORD:: <free-text>
Format: KEYWORD:: <free-text>
Example: KEYWORD:: Scientific Communication
KEYWORD:: Communication Theory
Example: KEYWORD:: Scientific Communication KEYWORD:: Communication Theory
CR-CATEGORY (O) -- Specify the CR-category. The CR-category (the
Computer Reviews Category) index (e.g., "B.3") should
always be included, optionally followed by the name of that
category. If the name is specified it should be fully
specified with parent levels as needed to clarify it, as in
the second example below. Use multiple lines for multiple
categories.
CR-CATEGORY (O) -- Specify the CR-category. The CR-category (the Computer Reviews Category) index (e.g., "B.3") should always be included, optionally followed by the name of that category. If the name is specified it should be fully specified with parent levels as needed to clarify it, as in the second example below. Use multiple lines for multiple categories.
Every year, the January issue of CR has the full list
of these categories, with a detailed discussion of the
CR Classification System, and a full index. Typically the
full index appears in every January issue, and the top two
levels in every issue.
Every year, the January issue of CR has the full list of these categories, with a detailed discussion of the CR Classification System, and a full index. Typically the full index appears in every January issue, and the top two levels in every issue.
Format: CR-CATEGORY:: <free-text>
Format: CR-CATEGORY:: <free-text>
Example: CR-CATEGORY:: D.1
Example: CR-CATEGORY:: D.1
Example: CR-CATEGORY:: B.3 Hardware, Memory Structures
Example: CR-CATEGORY:: B.3 Hardware, Memory Structures
PERIOD (O) -- Time period covered (date range). Applicable
primarily to progress reports, etc. Any format is
acceptable, as long as the two dates are separated with
" to " (the word "to" surrounded by spaces) and each date
is in the format allowed for dates, as described above for
the date field.
PERIOD(O)--期間は(日付の範囲)を含みました。 主として経過報告書などに適切です。 どんな形式も許容しています、2つの日付で切り離される限り「日付に上で年月日欄に説明されるように形式で」 (“to"という空間によって囲まれた単語)と各日付まで許容されています。
Format: PERIOD:: <date> to <date>
形式: 以上:、: <日付>への<日付>。
Example: PERIOD:: January 1990 to March 1990
例: 以上:、: 1990年1月から1990年3月
Lasher & Cohen Informational [Page 12] RFC 1807 A Format for Bibliographic Records June 1995
ラッシャとコーエンInformational[12ページ]のRFC1807 図書目録の記録1995年6月のための形式
SERIES (O) -- Series title, including volume number within series.
Open-ended format, with producing institution strongly
encouraged to be internally consistent.
SERIES(O)--シリーズの中に巻数を含むシリーズタイトル。 団体を生産する内部的に一貫させている強く奨励される制限のない形式。
Format: SERIES:: <free-text>
形式: シリーズ:、: <の無料のテキスト>。
Example: SERIES:: Communication
例: シリーズ:、: コミュニケーション
FUNDING (O) -- The name(s) of the funding organization(s).
FUNDING(O)--基金組織の名前。
Format: FUNDING:: <free-text>
形式: 以下に資金を供給します: <の無料のテキスト>。
Example: FUNDING:: ARPA
例: 以下に資金を供給します: アルパ
MONITORING (O) -- The name(s) of the monitoring organization(s).
MONITORING(O)--モニターしている組織の名前。
Format: MONITORING:: <free-text>
Example: MONITORING:: ONR
形式: 以下をモニターします: <の無料のテキストの>の例: 以下をモニターします: ONR
CONTRACT (O) -- The contract number(s).
CONTRACT(O)--契約番号。
Format: CONTRACT:: <free-text>
形式: 以下を契約してください: <の無料のテキスト>。
Example: CONTRACT:: MMA-90-23-456
例: 以下を契約してください: MMA-90-23-456
GRANT (O) -- The grant number(s).
グラント(O)--認可番号。
Format: GRANT:: <free-text>
形式: 以下を与えてください: <の無料のテキスト>。
Example: GRANT:: NASA-91-2345
例: 以下を与えてください: NASA-91-2345
LANGUAGE (O) -- The language in which the report is written.
Please use the full English name of that language.
LANGUAGE(O)--レポートが書かれている言語。 その言語の完全なイギリスの名前を使用してください。
Please include the Abstract in English, if possible.
英語で抽象的で、有り得るのを含めてください。
If the language is not specified, English is assumed.
言語が指定されないなら、英語は想定されます。
Format: LANGUAGE:: <free-text>
形式: 言語:、: <の無料のテキスト>。
Example: LANGUAGE:: English
Example: LANGUAGE:: French
例: 言語:、: イギリスの例: 言語:、: フランス語
Lasher & Cohen Informational [Page 13] RFC 1807 A Format for Bibliographic Records June 1995
ラッシャとコーエンInformational[13ページ]のRFC1807 図書目録の記録1995年6月のための形式
NOTES (O) -- Miscellaneous free text.
NOTES(O)--種々雑多な無料のテキスト。
Format: NOTES:: <free-text>
形式: 注意:、: <の無料のテキスト>。
Example: NOTES:: This report is the full version of the
paper with the same title in IEEE Trans ASSP
Dec 1976
例: 注意:、: 1976年12月にこのレポートは同じタイトルがIEEE Trans ASSPにある紙の完全版です。
ABSTRACT (O) -- Highly recommended, but not mandatory. Even
though no limit is defined for its length, it is suggested
not to expect applications to be able to handle more than
10,000 characters.
要約(O)--非常にお勧めですが、義務的ではありません。 限界は全く長さのために定義されませんが、それは、アプリケーションが1万以上のキャラクタを扱うことができると予想しないように示されます。
The ABSTRACT is expected to be used for subject searching
since titles are not enough. Even if the report is not in
English, an English ABSTRACT is preferable. If no formal
abstract appears on document, the producers of the
bibliographic records are encouraged to use pieces of the
introduction, first paragraph, etc.
タイトルが十分でないので対象の探すのに要約が使用されると予想されます。 レポートが英語でなくても、イギリスの要約は望ましいです。 どんな正式な要約もドキュメントの上に現れないなら、図書目録の記録のプロデューサーが序論、第一節などの断片を使用するよう奨励されます。
Format: ABSTRACT:: xxxx .............. xxxxxxxx
xxxx .............. xxxxxxxx
形式: 以下を抜き取ってください: xxxx… xxxxxxxx xxxx… xxxxxxxx
xxxx .............. xxxxxxxx
xxxx .............. xxxxxxxx
xxxx… xxxxxxxx xxxx… xxxxxxxx
END (M) -- This is a mandatory field. It must be the last entry
of a record, identifying the record that it ends, by stating
the same ID that was used at the beginning of the records,
in its "ID::".
END(M)--これは義務的な分野です。 それは記録の最後のエントリーであるに違いありません、終わるという記録を特定して、中の記録の始めに使用されたのと同じIDを述べることによってそれ、「ID:、:、」.
Format: END:: XXX//YYY
形式: 以下を終わらせてください: XXX//YYY
Example: END:: OUKS//CS-TR-91-123
例: 以下を終わらせてください: OUKS//Cs-TR-91-123
>>>>>>> [END OF FORMAT DEFINITION] <<<<<<<
>>>>>>>。[形式定義の終わり] <<<<<<<。
A Note Regarding the Controlled Symbols of the Publishers
出版社の制御シンボルに関する注
In order to avoid conflicts among the symbols of the publishing organizations (the XXX part of the "ID:: XXX//YYY") it is suggested that the various organizations that publish reports (such as universities, departments, and laboratories) register their <publisher-ID> symbols and names, in a way similar to the registration of other key parameters and names in the Internet.
出版組織のシンボルの中で摩擦を避ける、(XXXが離れている、「ID: : XXX//YYY」、)、レポート(大学や、部や、実験室などの)を発表する様々な組織がそれらの<出版社ID>シンボルと名を登録することが提案されます、インターネットにおいて他の主要なパラメタと名前の登録と同様の方法で。
Lasher & Cohen Informational [Page 14] RFC 1807 A Format for Bibliographic Records June 1995
ラッシャとコーエンInformational[14ページ]のRFC1807 図書目録の記録1995年6月のための形式
Rebecca Lasher (RLASHER@Forsythe.stanford.edu), of Stanford working with CNRI has agreed to coordinate this registration with the IANA for the publishers of Computer Science technical reports. It is suggested that before using this format the publishing organizations would coordinate with her (by e-mail) their symbols and the names of their organizations.
レベッカLasher( RLASHER@Forsythe.stanford.edu )、スタンフォードでは、CNRIと共に働いているのはコンピュータScience技術報告書の出版社のためにIANAとのこの登録を調整するのに同意しました。 この形式を使用する前に出版組織が彼女(メールによる)と共にそれらのシンボルと彼らの組織の名前を調整すると示唆されます。
In order to help automated handling of the received bibliographic records, it is expected that the producers of bibliographic records will always use the same name, exactly, in the ORGANIZATION field.
受信された図書目録の記録の自動化された取り扱いを助けるために、図書目録の記録のプロデューサーがいつも同じ名前を使用するとまさに予想されます、ORGANIZATION分野で。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Acknowledgements
承認
This work was supported by the Advanced Research Projects Agency under Grant No. MDA-972-92-J-1029 with the Corporation for National Research Initiatives (CNRI). Its content does not necessarily reflect the position or the policy of the Government or CNRI, and no official endorsement should be inferred.
この仕事はグラントNo.の下でAdvanced Research Projects Agencyによって支持されました。 国家の研究イニシアチブ(CNRI)のための社があるMDA-972-92-J-1029。 内容は必ず位置を反映するべきでないというわけではありませんか、CNRIを推論しますが、政府の方針にもかかわらず、どんな公式の裏書きも推論するべきではありません。
Authors' Addresses
作者のアドレス
Rebecca Lasher Mathematical and Computer Sciences Library M.S. 2125 Stanford University Stanford, CA, USA 94305
レベッカ・ラッシャ数学とコンピューターサイエンシズ図書館m.s.2125スタンフォード大学のスタンフォード、カリフォルニア、米国94305
Phone: +1 415 723 0864 EMail: rlasher@forsythe.stanford.edu
以下に電話をしてください。 +1 0864年の415 723メール: rlasher@forsythe.stanford.edu
Danny Cohen Myricom 325 N. Santa Anita Ave. Arcadia, CA 91006 USA
ダニーコーエンMyricom325N.サンタアニタAve。 理想郷、カリフォルニア91006米国
Phone: +1 818 821 5555 EMail: Cohen@myri.com
以下に電話をしてください。 +1 5555年の818 821メール: Cohen@myri.com
Lasher & Cohen Informational [Page 15]
ラッシャとコーエンInformationalです。[15ページ]
一覧
スポンサーリンク
