Re: docster: instant document delivery

[Karen Coyle <karen.coyle@ucop.edu>]

At 08:40 AM 5/23/00 -0400, Frank Walker wrote: 
>
>  For one, there is the problem of identifying journal articles
> that users receive.  In my world, which is biomedical, journal articles are
> identified through the MEDLINE unique identifier....
> For that matter, what about the non-biomedical world; is there any unique
> identifier for journal articles in other fields?
>  


Not that has that same kind of use as the Medline UI, but there is the SICI
- a
code that can be developed from the ISSN, title characters, volume, number,
date and pages. We use modified SICI's to link from A&I databases to the
articles as stored on publisher sites. 

That's just a unique identifier, however, and I assume that we also would want
enough metadata to allow an author, title, and Journal title/issue search.
Basically, we have to think through how it is that users will find articles --
do we assume that they've already gone through some bibliograhic database and
found the citation, and are just now looking for the full text? Or should they
be able to search Docster on its own? since it is possible to add any content
to a "*ster", i.e. something you yourself have created, there does need to be
some way to discover that content.


>
> Another potential problem with docster is how long will users keep copies
of 
> their electronic material on their computers (in this case, journal
> articles)?  
> In my experience with DocView software, most users tend to print their 
> articles after they are received; after that they may or may not delete the 
> electronic copy from their computer. 
>  
> Another minor stumbling block is the method by which documents are received
> and
> the disk directory where they are stored. Today there are three: MIME email
> attachments, 
> Ariel FTP and the WWW.  


I was actually thinking of a different model, but first let me answer this. If
end-users are contributing to Docster, then we have to assume some basic level
of expertise. Those who are unable to store the documents in a certain
directory to make them available simply won't be likely participants. Napster
users had to have enough savvy to install the client and do the minimum needed
to exchange files. Docster users will need some skills as well.

The model that I was thinking of was not that of individual users storing the
documents but of individual libraries. Maybe that isn't really in the Napster
spirit, but it would make it possible to avert some of the legal issues by
identifying licensing units (libraries, consortia, etc.) within which exchange
of the documents is legal. Otherwise there's not much hope for Docster at all
except to be used by faculty members as a shared pre-print server. (And even
pre-print servers have to follow rules.) None of our licenses for content
would
allow us or our users to put that content up on the Net for general
consumption; we could share among the users and institutions that are covered
by our license, however.

>
> All this has implications for docster, and I am sure that without a legal
> team from day one, docster
> might suffer the same fate as napster and Carl Uncover, and be smothered
with
> lawsuits.


Yes, absolutely. Which is why it's important to find a legal model that works
for it -- otherwise there's not much use gong to the effort to create the
program.




----------------------------------------------
Karen Coyle                    karen.coyle@ucop.edu
  University of California Digital Library
  http://www.kcoyle.net        510/987-0567
----------------------------------------------