http:^^www.cs.cornell.edu^info^people^lagoze^papers^www.html

来自「This data set contains WWW-pages collect」· HTML 代码 · 共 776 行 · 第 1/3 页

project, an ARPA-sponsored, CNRI-directed effort to create an online
digital library of technical reports from the nation's top computer
science universities.
This version was installed at the five universities that form
the project
(<!WA6><!WA6><!WA6><!WA6><!WA6><!WA6><!WA6><!WA6><!WA6><!WA6><!WA6><!WA6><!WA6><!WA6><!WA6><!WA6><!WA6><!WA6><!WA6><!WA6><a HREF="http://cs-tr.cs.cornell.edu">Cornell</A>,
CMU, Berkeley, MIT, and Stanford),
and shortly thereafter at Princeton, Dartmouth, and Rochester.
Here we describe a few of its features.
A full account may be found in <!WA7><!WA7><!WA7><!WA7><!WA7><!WA7><!WA7><!WA7><!WA7><!WA7><!WA7><!WA7><!WA7><!WA7><!WA7><!WA7><!WA7><!WA7><!WA7><!WA7><a HREF="#Dienst"> [Dienst]</A>.

<p>

One uses Dienst by connecting to any convenient Dienst server (that
supports the user interface services) using a standard Web client.
This server will display a form for searching the collection.  Unless
the user restricts the search to a single publisher, all Dienst
servers are searched in parallel.  Each Dienst server is made aware of
all other Dienst servers by fetching a list of all servers from a
single, central meta-server.  Thus when a new server comes online,
other servers become aware of it after only a short time.  The results
from a search are displayed as a list of the DocID, author, title, and
date for each matching document, and include a URL for each document.
Selecting one displays the document in more detail, including a list
of the available formats (obtained as described above.)  The user can
retrieve the document in any of the formats.

<p> Some repositories include page images as 4-bit 72 dot per inch GIF
files.  When this is the case, the user interface service is able to
display the document page at a time, inline on the user's Web client.
We found that such pages are readable on most monitors and saves
considerable network bandwidth compared to the 600 dpi TIFF images.
In addition, some sites also store reduced size "thumbnail" page
images, which allow the user to quickly browse through a document and
then click to view a interesting page (say one that contains a
graphic) in full-page version.  Although we do not have any formal
user studies, anecdotal evidence says that this is a very powerful
and helpful feature.  

<p>

The server also allows the user to download and/or print all or
selected pages of the document.  Local users may print directly, while
remote users can download a PostScript version of the document and
then print it manually.  Since all documents are not available in
PostScript, the server has the ability to translate from TIFF images
to level 2 PostScript on the fly.

<h2>Maintaining the Document Collection</h2>

Our goal is to simplify the process by which an author publishes
digital documents.  Much of the work in this area is at the
document creation layer - that is, enhancements to HTML and/or HTML
editors.  Our approach is to allow authors to use their traditional
text production system - LaTeX, troff, Word, etc - and then provide
tools by which they can submit the results of that text processing to
a digital library

<h3> Dienst simplifies digital library maintenance</h3>

Digital library technology will only propagate beyond the
technologically savvy if such systems require minimal human
intervention, especially by trained experts.  Two points are obvious.
First, authors are concerned primarily with writing documents and
getting them published.  Submission to a digital library should
require little more skill than using a word processor.  Second, many
of the organizations that wish to publish documents (e.g., government
agencies, academic departments, small companies) have little technical
expertise.  These organizations might tolerate the need for a
reasonable skill level to install a digital library system (we intend
to address the skill level required to install the digital library
system in future work).  However, they surely will not tolerate the
cost of a systems expert to maintain the library.

<p>

At Cornell we have implemented a set of tools that mostly automate the
process of managing a digital library.  The tools are closely
integrated with the Dienst digital library server.  They are similar
in spirit to those implemented for the Wide Area Technical Report
Server (<!WA8><!WA8><!WA8><!WA8><!WA8><!WA8><!WA8><!WA8><!WA8><!WA8><!WA8><!WA8><!WA8><!WA8><!WA8><!WA8><!WA8><!WA8><!WA8><!WA8><A HREF="#WATERS">[WATERS]</A>) system, known as Techrep, but
whereas Techrep is designed to maintain the centralized index and
unstructured FTP-based document repository that is characteristic of
WATERS, the tools described here are tailored for the distributed
indexes and structured repositories characteristic of Dienst.

<p>

Our design goal was to make the digital library maintainable by a
document librarian (DL) with relatively low-level computer training.
This DL serves four major roles - 1) as the general manager of the
collection; 2) as the reviewer of
document submissions, to protect against counterfeit document
submissions; 3) as the clearing house for copyright issues; and 4) as the archiver of document hardcopy.  This system has
recently been installed in the Cornell Computer Science Department and
is now the means for all technical report submissions.

<p>

<h4>Authors add documents with an HTML form</h4>

The  submitter  prepares a document for submission by producing a
PostScript representation.
Rather
than a plethora of document formats from a variety of word processors,
we determined that PostScript represents a 
<i> 
lingua franca 
</i> 
that
could be generated from virtually all word or text processing systems.
We recognize that there will be documents that can not be represented
in this fashion, but estimate that there number will be very few and
that techniques for managing them can be developed as the process
matures.  

<p>

The author submits a document by completing an HTML form that contains
text fields for bibliographic data about the document.  These fields are the
document title, author(s), pathname of the PostScript file, abstract,
and submitter's e-mail address.  The submitter can quickly complete this form by "cutting and pasting" text from the document source.

<p>

<h4>The document librarian validates submissions to the library</h4>

The document librarian, in the role of gatekeeper of the system,
learns of each submission through an automatically generated e-mail
message. No document actually enters the database until the DL
manually checks the submission.  In addition, the DL acts as the legal
gateway, ensuring that the authors complete a copyright release form
that gives the department permission to make the document available
over the internet.  When manual checking and copyright clearing are
complete, the DL uses a simple command to assign a DocID to the
document and signal that the document is ready entry into the
database.

<p>

The remainder of the process is fully automated.  Software that is
integrated with the digital library server
generates the RFC-1357 bibliographic entry from the
submitter's entry, checks the validity of the postscript file, builds the
actual database entry, and generates the GIF images for online viewing
and browsing of the document.

<p>

The image conversions in this process are done with the Extended Portable Bitmap Toolkit (<!WA9><!WA9><!WA9><!WA9><!WA9><!WA9><!WA9><!WA9><!WA9><!WA9><!WA9><!WA9><!WA9><!WA9><!WA9><!WA9><!WA9><!WA9><!WA9><!WA9><A
HREF="#PBMPLUS">[PBMPLUS]</A>).  PBMPLUS
consists of a number of filters for conversion between a variety of
image formats 
(TIFF's, GIF's, X Bitmaps, etc.) and a small set of portable formats
, and a set of tools to perform 
manipulations (rotations, color transformation, scaling) on the
portable format files.  PBMPLUS has the advantages of being free,
quite reliable, usable on a wide variety of graphical formats, and
quite powerful in its basic image manipulating capabilities.  

<h4>Document librarian controls document withdrawal</h4>

A library system must be able to handle author requests for
document withdrawal.  The reason for withdrawal may be invalidation of
the published research or newly published results in another document.
For purposes of maintaining the integrity of collection, we have made the
document librarian the control point for this operation.
Document withdrawal, via a simple command, replaces the bibliographic
file with an entry whose only attributes are the document number and a
"WITHDRAWN" flag - all other bibliographic information is deleted.
This ensures that the DocID is not reused for another document.
Furthermore, the withdrawal moves the original bibliographic
file and associated  image and postscript
files  to a location that is not accessible to the document server.

<h4>Hardcopy is sometimes required</h4>

While electronic document delivery is the 
<i>
raison d'etre
</i>
of our system, we recognize that publication quality hardcopy
is sometimes needed.  The document librarian must produce
paper copy for archival storage and for people who
do not have electronic access.

In our system, printing of TR's is done using a
package provided by Cornell Information Technologies called EZ-PUBLISH
<!WA10><!WA10><!WA10><!WA10><!WA10><!WA10><!WA10><!WA10><!WA10><!WA10><!WA10><!WA10><!WA10><!WA10><!WA10><!WA10><!WA10><!WA10><!WA10><!WA10><A HREF="#EZPUB"> [EZPUB] </A>.  EZ-PUBLISH allows users across campus on various
platforms to print to a central Xerox DocuTech publishing system.
This is a publication quality printer that offers very high-speed and
resolution (135 pages/minute, 600 dpi) and document setup facilities
such as binding, different paper types, etc.  
With a command in the
Dienst document management suite the DL can specify that multiple
copies of a TR be printed on the DocuTech.  The command does automatic
setup of the print job including formatting of a standard Cornell
Technical Report cover page.

<p>
<p>

We have just begun to use this automated system in the Computer Science
department at Cornell.  At a later time we will evaluate the
effectiveness of the system, with special attention payed to the
number of documents that require a special submission procedure (i.e.,
are not translatable to postscript).  Obviously if the ratio of these
is high to the number submitted documents, we need to rethink the
design of the system.

<h3> Digitizing existing documents is a mostly manual task</h3>

We describe above a system for almost complete automation of the
document submission process.  At Cornell, we faced the additional task
of converting an existing collection to digital form.  While some of
the tools described above were useful for this task, a large amount of
manual intervention was required.

The Cornell Computer Science Department has been publishing technical
reports since 1968.  As of September, 1994 the department had
published 1449 TR's, with an average length of thirty-six pages (a
total of over 52,000 pages).  The digital record for many of
these TR's is either non-existent, not easily available, or in a
format that is difficult to interpret with current hardware and
software (for example, a document formatted in an extinct copy of
WordStar that is only available on floppies for a long-gone CPM system).  

<p>

The common form that exists for all existing documents is hardcopy -
the department maintains archival copies of the entire TR corpus.  A
production scanning facility on campus allowed the department to
convert the entire corpus to high-quality 600dpi group 4-compressed
TIFF images.  Over a nine month period all hardcopy pages were scanned to
individual TIFF files and downloaded via FTP to disk in the Computer
Science Department.  Each TIFF file ranges in size from around one
kilobyte for a blank page to almost two megabytes for a page that
contains a high quality photographic image. The total collection of
pages images now occupies around 3.6 gigabytes.

<p>

It should be noted that scanning a collection, even as modest as the
Cornell CS TR's,  is time consuming, labor intensive, and not without
problems.  Even the most careful scanning technician occasionally
misses pages, skews pages, or misses part of a page due to a unnoticed
fold when the page is put on the scanner bed.  These problems are
difficult, if not impossible, to detect automatically.  In addition,
any problems that are detected are computationally intensive to
correct.  For example, a simple ninety-degree rotation of a 600 dpi
TIFF image (due to incorrect scanning orientation) can take up to
thirty minutes on a reasonably equipped SPARCstation 10.

<p>

An example illustrates the difficulty of correcting scanning
problems.  We discovered after all scanning was complete that many of
our older TR's were scanned from pages that were oriented in landscape
mode - two pages side-by-side.  The result was a TIFF file containing