Exploring the Docster concept

[Julia Schult]

At the request of Jane Dysart, program coordinator for
Computers in Libraries 2001, I am trying to put together a
program about the Docster concept, or whatever it has become
by that time (March 2001).  Please email me with ideas for
sessions and speakers!

I’ve reviewed the discussions I can find on the web
specifically about the Dan’s Docster article, and it seems
to be widely misunderstood.  The discussion on Web4Lib seems
to have a good handle on it and on the issues involved. :-)

Here is an attempt to pull together all the buzz about
docster and digital/electronic file-sharing models for ILL:

Ideas borrowed from Napster:

Distributed computing:  whoever scans the document, or
requests it, keeps it on their server so others don't have
to do the work.  There would probably be more than one copy
of the document, but at much less effort than the current
models of creating a new electronic copy for every request.
If you keep a copy of the article on the recieving computer
available to Docster, that reduces the load on the server
you got it from.  If an article is requested 10 times, and 7
of those people delete their copies, the other 3 will still
be up there so the original server won't have to answer all
requests for the article.  NOTE: currently there are more
paper copies floating around than electronic copies.  Ariel
is not everywhere.  The Docster idea would encourage a move
away from paper ILL.

Searching: when you're looking for a document, you search
all the currently available servers for the article you're
looking for.  NOTE:  several servers could have it up in
different file formats.  Suppose one library has it in Ariel
ftp format, while another has it as a .pdf.  The downloader
could choose which format they want.  Presumably the Docster
(or whatever we call it) protocol would have some standard
tags for the files.  After seeing the success of the sloppy
Napster way of doing things, if you have the Article Title
and Journal Title or just the Date (3 fields) that you
request from the user, that would suffice for most ILL
specialists to find the article they want.  Okay, we can
stick on Author (4 fields total).

Authentication:  Two possibilities:  if only libraries are
involved, quality will tend to be high.  So if we pull back
from the full power of Docster as Dan has envisioned it as
involving the end researcher and her/his computer, and just
stick to library participants, that removes some of the
quality problem.  Second possibility:  just as on Napster
and with conventional ILL, certain servers will be known for
their good or bad quality.  If someone misspells words in
the article title, that copy of the article won't be found,
but the next request for the article would probably get it
right, and that copy could become the most-used copy (though
it might be on several machines).

Idea from the library world:

Copyright control:  The best way I can see to handle this
for *library ILL purposes* is for the Docster protocol to
send a message for each copy made through the system to a
central copyright clearance center (the CCC or a ccc?)
noting the identifying information for the article (Article
Title, Journal Title, Date, and Author) and the user or
institution that is requesting the copy.  You need a
centralized place to track this for two reasons: a certain
amount of ILL of a given article is justified under
copyright law, but requesting the same article for 25
patrons probably isn't.  A centralized place would know how
many copies you requested even though your source for the
many copies might be 25 different Docster nodes.  Secondly,
to aggregate the fees, so that you can pay Cambridge U.
Press one chunk, Academic Press another hunk and Elsevier
another (huge) chunk ;-) at regularly scheduled intervals
instead of paying out in dribs and drabs.

An alternative *non-exclusive to libraries* solution would
be for each document to have a fifth field designating the
copyright holder's information, and sending them a notice
whenever the Docster protocol sends that document
somewhere.  Oof-da.  Just the thought of trying to determine
the copyright holder's electronic address each time you use
the system encourages me to, well, bypass copyright law.  It
does put the burden of collection on the copyright holder.

Any better ideas out there?  Where do we go from here?

---Julia E. Schult
Access/Electronic Services Librarian
Elmira College
Jschult at elmira.edu