RFC1691 日本語訳
1691 The Document Architecture for the Cornell Digital Library. W.Turner. August 1994. (Format: TXT=20438 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group W. Turner Request for Comments: 1691 LTD Category: Informational August 1994
コメントを求めるワーキンググループW.ターナー要求をネットワークでつないでください: 1691年のLTDカテゴリ: 情報の1994年8月
The Document Architecture for the Cornell Digital Library
コーネルDigital図書館への文書体系
Status of this Memo
この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.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This memo defines an architecture for the storage and retrieval of the digital representations for books, journals, photographic images, etc., which are collected in a large organized digital library.
このメモはストレージのためのアーキテクチャと本、ジャーナル、大きい組織化されたデジタル図書館に集められる画像などのためのディジタル表現の検索を定義します。
Two unique features of this architecture are the ability to generate reference documents and the ability to create multiple views of a document.
このアーキテクチャの2つのユニークな特徴が、参照がドキュメントであると生成する能力とドキュメントの複数の視点を作成する能力です。
Introduction
序論
In 1989, Cornell University and Xerox Corporation, with support from the Commission on Preservation and Access and later Sun Microsystems, embarked on a collaborative project to study and to prototype the application of digital technologies for the preservation of library material. During this project, Xerox developed the College Library Access and Storage System (CLASS), and Cornell developed software to provide network access to the CLASS Digital Library.
1989年に、Preservation、Access、および後のサン・マイクロシステムズの委員会からのサポートで、コーネル大学とゼロックス社はライブラリの材料の保存の研究する共同プロジェクトとデジタル技術のプロトタイプへの適用を始めました。 このプロジェクトの間、ゼロックスは大学図書館AccessとStorage System(CLASS)を開発しました、そして、コーネルはCLASS Digital図書館へのネットワークアクセスを提供するためにソフトウェアを開発しました。
Xerox and Cornell University Library staff worked closely together to define requirements for storing both low- and high-resolution versions of images, so that the low-resolution images could be used for browsing over the network and the high-resolution images could be used for printing. In addition, substantial work was done to define documents with internal structures that could be navigated. Xerox developed the software to create and store documents, while Cornell developed complementary software to allow library users to browse the documents and request printed copies over the network.
ゼロックスとコーネル大学の図書館スタッフは低く両方を保存するための要件とイメージの高画質バージョンを定義するために緊密に一緒に働いていました、ネットワークの上のブラウジングに低い解像度イメージを使用できて、印刷に解像度の高い像を使用できるように。 さらに、ナビゲートできた内部の構造があるドキュメントを定義するためにかなりの仕事をしました。 ゼロックスはドキュメントを作成して、保存するためにソフトウェアを開発しました、コーネルは図書館の利用者がドキュメントをブラウズして、ネットワークの上で印刷されたコピーを要求するのを許容するために補足的なソフトウェアを開発しましたが。
Cornell has defined a document architecture which builds on the lessons learned in the CLASS project, and is maintaining digital library materials in that form.
コーネルはCLASSプロジェクトで学習されたレッスンのときに建てて、そのフォームでデジタル図書館資料を維持している文書体系を定義しました。
Turner [Page 1] RFC 1691 CDL Document Architecture August 1994
ターナー[1ページ]RFC1691CDLは1994年8月にアーキテクチャを記録します。
Document Architecture Overview
文書体系概要
Just as a conventional library contains books rather than pages, so the electronic library must contain documents rather than images. During the scanning process, images are automatically linked into documents by creating document structure files which order the image files in the same way the binding of a book orders the pages. Thus, the digital book as currently configured consists of two parts: a set of individual pages stored as discrete bit map image files, and the document structure files which "bind" the image files into a document. In addition, a database entry is made for each digital document which permits searching by author and title (i.e., bibliographic information). Beyond the order of the pages, the arrangement of a physical book provides information to readers. The title page and publication information come first; the table of contents usually precedes the text; the text is divided into sections or chapters; if there is an index, it follows the text. The reader often refers to these components of a book when browsing the library shelves, in order to determine whether to read the book.
ちょうど従来のライブラリがページよりむしろ本を含んでいるように、電子ライブラリはイメージよりむしろドキュメントを含まなければなりません。 スキャンプロセスの間、イメージは、本の製本がページを注文する同じようにイメージ・ファイルを注文するドキュメント構造ファイルを作成することによって、自動的にドキュメントにリンクされます。 したがって、現在構成されているとしての電子書籍は2つの部品から成ります: 1セットの個人のページは離散的であるとしてビットマップイメージ・ファイル、およびドキュメントにイメージ・ファイルを「縛る」ドキュメント構造ファイルを保存しました。 さらに、作者とタイトルで探すのを可能にするそれぞれのデジタルドキュメントのためにデータベースエントリーをします(すなわち、図書目録の情報)。 ページの注文を超えて、物理的な本のアレンジメントは情報を読者に提供します。 タイトル・ページと公表情報は一番になります。 通常、目次はテキストに先行します。 テキストはセクションか章に分割されます。 インデックスがあれば、それはテキストに従います。 ライブラリ棚をブラウズするとき、読者はしばしば本のこれらの部品を参照します、本を読むかどうか決定するために。
The document structure provides direct access to the components of an electronic document, storing the information that would otherwise be lost when the book is disbound for scanning.
ドキュメント構造は電子化文書のコンポーネントに直接アクセスを提供します、スキャンのためにそうでなければ本が「不-バウンド」であるときに失われている情報を保存して。
Document Architecture Requirements
文書体系要件
Listed below are the requirements that were initially set down for the Cornell Digital Library Architecture.
以下に記載されているのは、初めはコーネルDigital図書館Architectureであるとみなされた要件です。
1. The architecture must be open (i.e., published and freely
available).
1. アーキテクチャは開いているに違いありません(すなわち、発行されて自由に利用可能な)。
2. The architecture should be as simple as possible (to facilitate
product development).
2. アーキテクチャはできるだけ簡単であるべきです(商品開発を容易にする)。
3. The architecture should assume data storage in UNIX file systems.
3. アーキテクチャは、データがUNIXファイルシステムでストレージであると仮定するべきです。
4. The architecture should allow for standard data usage, such as via
FTP and Gopher servers (i.e., pages of a document must exist in a
single directory, and the naming convention used must order them
in the standard collating sequence, such as the series "0001.TIF,
0002.TIF,..., 0411.TIF" (NOTE: a series such as "1.TIF, 2.TIF,...,
10.TIF" would be ordered "1.TIF, 10.TIF, 2.TIF, ..." which is not
acceptable).
4. アーキテクチャは標準のデータ用法を考慮するべきです、FTPやゴーファーサーバなどで。(すなわち、ドキュメントのページは単一ディレクトリに存在しなければなりません、そして、コンベンションが使用した命名は標準の照合順序でそれらを注文しなければなりません、シリーズ「0001.TIF、0002.TIF、…、0411.TIF」(「1.TIF、10.TIF、2.TIF」…許容できない が: 「1.TIF、2.TIF、…、10.TIF」はそうするだろうシリーズに命令されることに注意する)などのように。
5. The architecture should provide for storing the same information
in different formats. For example, when a page of a document is
available at several different resolutions.
5. アーキテクチャは異なった形式で同じ情報を保存するのに提供されるべきです。 ドキュメントの1ページがいくつかの異なった解決のときに例えば利用可能であるときに。
Turner [Page 2] RFC 1691 CDL Document Architecture August 1994
ターナー[2ページ]RFC1691CDLは1994年8月にアーキテクチャを記録します。
6. Low-resolution "thumbnail" images of each page must be stored to
facilitate browsing and sharing of data.
6. データのブラウジングと共有を容易にするためにそれぞれのページの低い解像度「親指の爪」イメージを保存しなければなりません。
7. The architecture must support distribution of files so that
similar files may be stored together, permitting optimization of
storage use and performance.
7. アーキテクチャは同様のファイルを一緒に保存できるようにファイルの分配をサポートしなければなりません、ストレージ使用と性能の最適化を可能にして。
8. The architecture must support documents that are composed of
references to all or part of other documents.
8. アーキテクチャは他のドキュメントのすべてか一部の参照で構成されるドキュメントを支えなければなりません。
9. The architecture must support document components which are
stored on separate servers distributed across the network.
9. アーキテクチャはネットワークの向こう側に分配された別々のサーバに保存されるドキュメントの部品を支えなければなりません。
10. The architecture must support not only an hierarchical structure
for each document, but the ability to define multiple views of
each document.
10. アーキテクチャは各ドキュメントのための階層構造だけではなく、それぞれのドキュメントの複数の視点を定義する能力もサポートしなければなりません。
11. The architecture should accept, rather than dictate, directory
structures in which documents will be stored. This will permit
documents created in other ways to be added to the Digital
Library simply by adding database information rather than by
copying or moving files.
11. アーキテクチャは書き取るよりむしろ、ドキュメントが保存されるディレクトリ構造を受け入れるべきです。 これはファイルをコピーするか、または動かすことによってというよりむしろ単にデータベース情報を加えることによってDigital図書館に追加されるべき他の方法で作成されたドキュメントを可能にするでしょう。
Document Architecture Description
文書体系記述
A digital library consists of a Digital Library Server, networked storage, and a referencing database. A single digital library will contain one or more collections. Each collection will contain one or more documents.
デジタルライブラリはDigital図書館Server、ネットワークでつながれたストレージ、および参照箇所データベースから成ります。 ただ一つのデジタルライブラリは1つ以上の収集を含むでしょう。 各収集は1通以上のドキュメントを含むでしょう。
The referencing database allows searching for documents by author, title, and document ID. In the current implementation, the referencing database is a relational SQL database, and each collection is epresented by a table in the database. It is planned to migrate to Z39.50 database searching as the preferred method, as this protocol has been established as the standard for library applications.
参照箇所データベースで、作者、タイトル、および文書識別コードはドキュメントを検索します。 現在の実装では、参照箇所データベースは関係SQLデータベースです、そして、各収集はデータベースのテーブルによってepresentedされます。 適した方法としてZ39.50データベース検索にわたるのは計画されています、このプロトコルがライブラリアプリケーションの規格と書き立てられたとき。
Authorization will be primarily collection-based, although the design will permit authorization checking at any level down to the individual file. Notification would come only when the patron attempted to open the document or access the particular component.
デザインはどんなレベルでも許可検査を個々のファイルまで可能にするでしょうが、承認は主として収集ベースになるでしょう。 後援者が、ドキュメントを開くか、または特定のコンポーネントにアクセスするのを試みたときだけ、通知は来るでしょう。
Each document consists of three components: the logical structure; the physical references; and the data files.
各ドキュメントは3つのコンポーネントから成ります: 論理構造。 物理的な参照。 そして、データファイル。
Turner [Page 3] RFC 1691 CDL Document Architecture August 1994
ターナー[3ページ]RFC1691CDLは1994年8月にアーキテクチャを記録します。
The logical structure is a logical description of the document. Conceptually, a document is a tree, with the leaves being the data files (pages). At a minimum, all documents have a logical structure which lists the pages in the document and the order in which they appear. Usually, documents will have a more elaborate structure. The logical structure relates the logical structure of a document to the physical references which make up the document.
論理構造はドキュメントの論理的な記述です。 概念的に、ドキュメントはデータファイル(ページ)である葉での木です。 最小限では、すべてのドキュメントがドキュメントにページを記載する論理構造とそれらが現れる注文を持っています。 通常、ドキュメントには、より入念な構造があるでしょう。 論理構造はドキュメントを作る物理的な参照にドキュメントの論理構造に関連します。
These physical references map the lowest levels of the document's logical structure (the leaves of the tree) to the files that contain the data. Where there are multiple representations of a page, such as images at various resolutions, these are linked together in the physical references file.
これらの物理的な参照は最も低いレベルのドキュメントの論理構造(木の葉)をデータを含むファイルに写像します。 1ページの様々な解決におけるイメージなどの複数の表現があるところでは、これらは物理的な参照ファイルで結びつけられます。
The data files contain the data making up a document. Any format can be accommodated: image files, ASCII text, PostScript, etc. However, one-to-one correspondence between data files for a given physical reference is assumed. That is, if there are multiple file types for a single page, these files should represent exactly the same information.
データファイルはドキュメントを作るデータを含んでいます。 どんな形式も設備することができます: イメージ・ファイル、ASCIIテキスト、ポストスクリプトなど しかしながら、与えられた物理的な参照のためのデータファイルの間の1〜1つの通信が想定されます。 すなわち、1ページ複数のファイルの種類があれば、これらのファイルはまさに同じ情報を表すはずです。
Physical References File
物理的な参照ファイル
The Physical References file is the component of the document which relates logical structures (logical components of documents) to physical files. Document references, by which a document can be composed of all or part of other documents possibly residing on different servers, are handled in the Physical References file.
Physical Referencesファイルは論理構造(ドキュメントの論理的な部品)を物理的なファイルに関係づけるドキュメントの部品です。 ドキュメント参照(ことによると異なったサーバにある他のドキュメントのすべてか一部でドキュメントを構成できる)はPhysical Referencesファイルで扱われます。
A document may contain multiple document objects, each of which contains one or more data objects. When a document contains actual physical data (for example, it is created by scanning or importing images), a Master Document Object is created. When a document incorporates components of other documents, a Reference Document Object is created for each of the other documents. The Document Objects are numbered with internal reference numbers, which are included in the corresponding Data Object lines.
ドキュメントは複数のドキュメントオブジェクトを含むかもしれません。それはそれぞれ1個以上のデータ・オブジェクトを含みます。 ドキュメントが実際の物理的なデータを含むとき(例えば、それはイメージをスキャンするか、またはインポートすることによって、作成されます)、Master Document Objectは作成されます。 ドキュメントが他のドキュメントの部品を取り入れると、Reference Document Objectはそれぞれの他のドキュメントのために作成されます。 Document Objectsは内部の参照番号で付番されます。(参照番号は対応するData Object系列に含まれています)。
Data Object lines include the Document Object number, the file reference number, and the file type. The Document Object number refers to a Document Object line, from which the library name, collection name, and document ID can be retrieved. The tuple
データObject系列はDocument Object番号、ファイル参照番号、およびファイルの種類を含んでいます。 Document Object番号はDocument Object系列について言及します。(それからライブラリ名、収集名、および文書識別コードを検索できます)。 tuple
<libraryID>+<collectionID>+<documentID>+<filetype>+<file reference>
<libraryID>+<collectionID>+<documentID>+<filetype>+<ファイル・リファレンス>。
is guaranteed to locate a file. Each Data Object line refers to a single file; where multiple file types of a single document page exist, there will be multiple Data Object lines for that page.
ファイルの場所を見つけるように、保証されます。 それぞれのData Object系列は一列について言及します。 1ドキュメントページの複数のファイルの種類が存在するところに、そのページ複数のData Object系列があるでしょう。
Turner [Page 4] RFC 1691 CDL Document Architecture August 1994
ターナー[4ページ]RFC1691CDLは1994年8月にアーキテクチャを記録します。
In the file, all Document Object lines will preceed all Data Object lines for a given document. Document Object lines may be either grouped together at the beginning of the file, or may immediately preceed the first Data Object line for the Document Object. Document Object lines will appear in order by Document Object number. Data Object lines will appear in order by sequence number, NOT by Document Object number.
ファイルでは、Document Object系列がそうするすべてが与えられたドキュメントのためにすべてのData Object系列をpreceedしました。 分類されたどちらかがファイルの始めに一緒にいたならそうするかもしれないか、またはObject系列がすぐにそうするかもしれないドキュメントはDocument Objectのために最初のData Object系列をpreceedしました。 Document Object番号に従って、ドキュメントObject系列は整然とするように見えるでしょう。 一連番号に従って、データObject系列はDocument Object番号に従って見えるのではなく、整然とするように見えるでしょう。
The fields in the Physical References file are delimited by vertical bars.
Physical Referencesファイルの分野は縦棒によって区切られます。
Document Object Lines
ドキュメント見える線
Field Description Comments
----- ---------------------- ----------------------------
1 Document Object number 0 => Master Document Object
1-9 => Reference Document Object
2 Library name Server name
3 Collection name
4 Document ID 8-digit number
5 Author name
6 Volume
7 Title
8 Edition
フィールド記述コメント----- ---------------------- ---------------------------- 1 >ドキュメントObject No.0=Master Document Object1-9は8桁数の>Reference Document Object2図書館名前Server名前3Collection名前4Document ID5Author名前6Volume7Title8Editionと等しいです。
Data Object Lines
データ・オブジェクト線
Field Description Comments
----- ---------------------- ----------------------------
1 Document Object number Corresponds to above
2 Sequence number
3 File reference Reference number used to locate
file in filing system
4 Physical reference number Equal to Logical Structure file
5 File type 1 = TIFF 600dpi
2 = TIFF thumbnail
3 = ASCII version of page
(i.e., OCR output)
4 = ASCII notes
5 = Other
6 = TIFF 300dpi
6 Note
フィールド記述コメント----- ---------------------- ---------------------------- 1 2Sequence No.3File参照Reference番号の上へのCorrespondsが以前はよく場所を見つけていたドキュメントObject番号はファイリングシステム4に他の6=TIFF 300dpi6 4つのページ(すなわち、OCR出力)=ASCII注意5=NoteのTIFFの小さいLogical Structureファイル5Fileタイプ1=TIFF 600dpi2=3=ASCII版にPhysical参照番号Equalをファイルします。
Turner [Page 5] RFC 1691 CDL Document Architecture August 1994
ターナー[5ページ]RFC1691CDLは1994年8月にアーキテクチャを記録します。
Physical References File Example
物理的な参照は例をファイルします。
+0|CORNELL|OLINLIB|00000001|Boole, Mary Everest||Philosophy Of Algebra||
+0|コーネル|OLINLIB|00000001|Boole、メアリ・エベレスト||代数の哲学||
|0|1|00000002|5|1|| (File ref. #2 = Phys. ref. #5 = 600dpi TIFF image) |0|2|00000003|5|2|| (File ref. #3 = Phys. ref. #5 = 100dpi TIFF image) |0|3|00000004|6|1|| (File ref. #4 = Phys. ref. #6 = 600dpi TIFF image) |0|4|00000005|6|2|| (File ref. #5 = Phys. ref. #6 = 100dpi TIFF image)
|0|1|00000002|5|1|| (審判をファイルしてください。 #2 = Phys審判。 #5 = 600dpi TIFFイメージ) |0|2|00000003|5|2|| (審判をファイルしてください。 #3 = Phys審判。 #5 = 100dpi TIFFイメージ) |0|3|00000004|6|1|| (審判をファイルしてください。 #4 = Phys審判。 #6 = 600dpi TIFFイメージ) |0|4|00000005|6|2|| (審判をファイルしてください。 #5 = Phys審判。 #6 = 100dpi TIFFイメージ)
Note that in the above, it is guaranteed that file references 2 and 3 are two different versions of the same page, as are file references 4 and 5.
ファイル・リファレンス4と5のように上記では、ファイル・リファレンス2と3が同じページの2つの異なった見解であることが保証されることに注意してください。
Logical Structure File
論理構造ファイル
The Logical Structure file is the component of the document structure which offers "views" of a document and links images together logically to define documents. The file is actually an unloaded tree; when a document is "opened", the file is read and the tree reconstructed. By convention, all Logical Structure files contain one logical structure "PAGES" which defines the document by listing the pages in the order in which they appeared in the original document.
Logical Structureファイルはドキュメントの「視点」を提供して、ドキュメントを定義するためにイメージを論理的に結びつけるドキュメント構造の部品です。 ファイルは実際に降ろされた木です。 いつドキュメントは「開かれ」て、ファイルが読まれるということですか、そして、再建された木。 コンベンションで、すべてのLogical Structureファイルがそれらが正本に現れたオーダーにページを記載することによってドキュメントを定義する1論理構造「ページ」を含みます。
Document Structure lines
ドキュメントStructure系列
Field Description Comments
----- ---------------------- ----------------------------
1 Parent structure number Structure is a child of...
2 Sequence number
3 Logical Structure name Label for this structure
4 Structure number Equal to Physical Reference file
5 Logical Children # of logical children of this
structure
Document Structure lines (continued)
フィールド記述コメント----- ---------------------- ---------------------------- 1 親構造番号Structureは…の子供です。 2 この構造Document Structureの論理的な子供のPhysical Referenceファイル5Logical Children#へのこの構造4Structure番号Equalのための一連番号3Logical Structure名前Labelは立ち並んでいます。(続けられています)
Field Description Comments
----- ---------------------- ----------------------------
6 Physical Children # of physical children of this
structure
7 References # of references to this
structure within this document
(for how many structures is this
a substructure)
フィールド記述コメント----- ---------------------- ---------------------------- 6 このドキュメントの中のこの構造の参照のこの構造7References#の物理的な子供の物理的なChildren#(いくつの構造がこのa基礎であるかのための)
Turner [Page 6] RFC 1691 CDL Document Architecture August 1994
ターナー[6ページ]RFC1691CDLは1994年8月にアーキテクチャを記録します。
Logical Structure File Example
論理構造ファイルの例
|0|0|ROOT|0|4|0|0| Structure 0, ROOT, has 4 logical children
|0|1|PAGES|1|100|0|1| Str. 1, PAGES, has 100 logical children
|0|2|CONTENTS|2|22|0|1| Str. 2, CONTENTS, has 22 logical children
...has no physical children
...
|1|1|Production note|5|0|2|2| Str. 5 is child of structure 1
...has a label "Production note"
...has no logical children
...has 2 physical references
...is referenced twice in this document
|1|2||6|0|2|1| Str. 6 has no label
|1|3||7|0|2|1| Str. 7 has 2 physical references
|1|4||8|0|2|1| Str. 8 is referenced only here
|1|5||9|0|2|1| Str. 9 is 5th sequential child of PAGES
...
|1|99||103|0|2|2|
|1|100||104|0|2|2|
|2|1|Production note|105|1|0|1| Str. 105 is a child of str. 2
|2|2|Title page|106|1|0|1| Str. 106 has 1 logical child
|2|3|Table of contents|107|2|0|1|
|2|4|Chapter 1. From Arithmetic to Algebra|108|6|0|1|
|2|5|Chapter 2. The Making of Algebras|109|4|0|1|
|2|6|Chapter 3. Simultaneous Problems|110|4|0|1|
|2|7|Chapter 4. Partial Solutions...|111|3|0|1|
|2|8|Chapter 5. Mathematical Certainty...|112|3|0|1|
|2|9|Chapter 6. The First Hebrew Algebra|113|8|0|1|
|2|10|Chapter 7. How to Choose our Hypotheses|114|9|0|1|
|2|11|Chapter 8. The Limits of the Teachers Function|115|5|0|1|
|2|12|Chapter 9. The Use of Sewing Cards|116|4|0|1|
...
|2|20|Chapter 17. From Bondage to Freedom|124|5|0|1|
|2|21|Appendix|125|2|1|1|
|2|22|advertisements|126|4|1|2|
|105|1|Production note|5|0|2|2| Str. 5 is a child of str. 105
|106|1|Title page|11|0|2|2| 2nd reference to str. 11
|107|1|7|15|0|2|2|
|107|2|8|16|0|2|2|
...
|126|4||104|0|2|2|
|0|0|根|0|4|0|0| 構造0(ROOT)には、4人の論理的な子供がいます。|0|1|ページ|1|100|0|1| Str。 1(ページ)には、100人の論理的な子供がいます。|0|2|コンテンツ|2|22|0|1| Str。 2、CONTENTSには、22人の論理的な子供がいます…どんな物理的な子供もいません… |1|1|生産注意|5|0|2|2| Str。 5は構造1の子供です…ラベル「生産注意」を持っています…どんな論理的な子供もいません…2つの物理的な参照箇所を持っています…二度本書では参照をつけられます。|1|2||6|0|2|1| Str。 6には、ラベルなしがあります。|1|3||7|0|2|1| Str。 7には、2つの物理的な参照箇所があります。|1|4||8|0|2|1| Str。 8はここだけで参照をつけられます。|1|5||9|0|2|1| Str。 9はページの5番目の連続した子供です… |1|99||103|0|2|2| |1|100||104|0|2|2| |2|1|生産注意|105|1|0|1| Str。 105はstrの子供です。 2 |2|2|タイトル・ページ|106|1|0|1| Str。 106には、1人の論理的な子供がいます。|2|3|目次|107|2|0|1| |2|4|第1章。 演算から代数まで|108|6|0|1| |2|5|第2章。 メイキング・オブAlgebras|109|4|0|1| |2|6|第3章。 同時の問題|110|4|0|1| |2|7|第4章。 部分的解決…|111|3|0|1| |2|8|第5章。 数学の確実性…|112|3|0|1| |2|9|第6章。 最初のヘブライの代数|113|8|0|1| |2|10|第7章。 Chooseへのどのようにが私たちのHypothesesであるか。|114|9|0|1| |2|11|第8章。 教師機能の限界|115|5|0|1| |2|12|第9章。 縫い物カードの使用|116|4|0|1| ... |2|20|第17章。 束縛から自由になりまで|124|5|0|1| |2|21|付録|125|2|1|1| |2|22|広告|126|4|1|2| |105|1|生産注意|5|0|2|2| Str。 5はstrの子供です。 105 |106|1|タイトル・ページ|11|0|2|2| strの2番目の参照。 11 |107|1|7|15|0|2|2| |107|2|8|16|0|2|2| ... |126|4||104|0|2|2|
Turner [Page 7] RFC 1691 CDL Document Architecture August 1994
ターナー[7ページ]RFC1691CDLは1994年8月にアーキテクチャを記録します。
Implementation Details
実装の詳細
The tuple <library ID>+<collection ID>+<document ID>+<filetype>+ <file reference> is guaranteed to locate a file. A file locator program will translate between this tuple and the fully-qualified path and file name in the underlying file system. While a library will always have a hierarchical nature corresponding to UNIX file systems, the order of the hierarchy will be flexible to accommodate optimization efforts. Each level of the hierarchy will have an INFO file that describes the order of the lower levels of the hierarchy. The file locator program will read these files as it navigates the directory structure of the file system when a library, collection, or document is opened. Two examples follow:
tuple<ライブラリID>+<収集ID>+<文書識別コード>+<filetype>+<ファイル・リファレンス>は、ファイルの場所を見つけるように保証されます。 ファイルロケータプログラムは基本的なファイルシステムのこのtupleと、完全に適切な経路とファイル名の間で翻訳されるでしょう。 ライブラリがいつも階層的な自然をUNIXファイルシステムに対応するようにする間、階層構造の注文は最適化取り組みを収容するのにおいてフレキシブルになるでしょう。 階層構造の各レベルに、階層構造の下のレベルの注文について説明するINFOファイルがあるでしょう。 ファイルシステムのディレクトリ構造にナビゲートするとき、ライブラリ、収集、またはドキュメントが開かれるとき、ファイルロケータプログラムはこれらのファイルを読むでしょう。 2つの例が従います:
Example 1. Hierarchy is LIBRARY, COLLECTION, DOCUMENT, FILETYPE.
例1。 階層構造は図書館、COLLECTION、DOCUMENT、FILETYPEです。
/<library name>
LIBINFO.TXT Description of library
/<collection name>
COLINFO.TXT Description of collection
/<document ID>
DOCINFO.TXT Description of document
LOGSTR.000 Logical structure file
PHYSREF.000 Physical reference file
/<filetype1>
00001.TIF
00002.TIF
...
/<filetype2>
00001.TIF
00002.TIF
...
ドキュメントLOGSTR.000Logical構造ファイルPHYSREF.000Physical参照ファイル/<filetype1>00001.TIF 00002.TIFの収集/<文書識別コード>DOCINFO.TXT記述のライブラリ/<収集名前>COLINFO.TXT記述の/<ライブラリ名>LIBINFO.TXT記述… /<filetype2>00001.TIF 00002.TIF…
Turner [Page 8] RFC 1691 CDL Document Architecture August 1994
ターナー[8ページ]RFC1691CDLは1994年8月にアーキテクチャを記録します。
Example 2. Hierarchy is LIBRARY, FILETYPE, COLLECTION, DOCUMENT.
例2。 階層構造は図書館、FILETYPE、COLLECTION、DOCUMENTです。
/<library name>
/<ライブラリ名>。
LIBINFO.TXT Description of library
/<filetype1>
/<collection name>
COLINFO.TXT Description of collection
/<document ID>
DOCINFO.TXT Description of document
LOGSTR.000 Logical structure file
PHYSREF.000 Physical reference file
00001.TIF
00002.TIF
...
/<filetype2>
/<collection name>
COLINFO.TXT Description of collection
/<document ID>
DOCINFO.TXT Description of document
LOGSTR.000 Logical structure file
PHYSREF.000 Physical reference file
00001.TIF
00002.TIF
....
ドキュメントLOGSTR.000Logical構造ファイルPHYSREF.000Physical参照ファイル00001.TIF 00002.TIFの収集/<文書識別コード>DOCINFO.TXT記述のライブラリ/<filetype1>/<収集名前>COLINFO.TXT記述のLIBINFO.TXT記述… ドキュメントLOGSTR.000Logical構造ファイルPHYSREF.000Physical参照ファイル00001.TIF 00002.TIFの収集/<文書識別コード>DOCINFO.TXT記述の/<filetype2>/<収集名前>COLINFO.TXT記述…
This implementation involves some redundancy, but it permits complete copies of a collection to be mounted on different file systems for performance considerations. In particular, the second scheme would facilitate storing all low-resolution images on high-speed magnetic disk for fast access, and all high-resolution images on slower, less expensive storage. This will also facilitate authorizing access to low-resolution images by other software systems (FTP, Gopher) while restricting access to high-resolution images.
この実装は何らかの冗長にかかわりますが、それは、収集の完本が性能問題の異なったファイルシステムの上に取り付けられることを許可します。 特に、2番目の体系は、速いアクセスのための高速磁気ディスクにすべての低い解像度イメージを保存して、より遅いところにすべての解像度の高い像を保存するのを容易にするでしょう、それほど高価でないストレージ。 また、これは、他のソフトウェア・システム(FTP、ゴーファー)でアクセスを解像度の高い像に制限している間、低い解像度イメージへのアクセスを認可するのを容易にするでしょう。
Turner [Page 9] RFC 1691 CDL Document Architecture August 1994
ターナー[9ページ]RFC1691CDLは1994年8月にアーキテクチャを記録します。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
References
参照
[1] Turner, W., "Cornell Digital Library Document Architecture,
Version 1.1 - 3/22/94", Library Technology Department, Cornell
University.
[1] w.ターナー、「コーネルDigital図書館はアーキテクチャ、バージョン1.1を記録します--3/22/94」、図書館技術部、コーネル大学。
Author's Address
作者のアドレス
William Turner
Library Technology
502 Olin Library
Cornell University
Ithaca, NY 14853
ウィリアムターナー図書館Technology502オリン・図書館コーネル大学イタケー、ニューヨーク 14853
Phone: 607-255-9098
Fax: 607-255-9346
EMail: wrt1@cornell.edu
以下に電話をしてください。 607-255-9098 Fax: 607-255-9346 メールしてください: wrt1@cornell.edu
Turner [Page 10]
ターナー[10ページ]
一覧
スポンサーリンク
