Re: docster: instant document delivery

[Frank Walker <walker@nlm.nih.gov>]

I've just read Daniel's paper on docster and find it to be very interesting.

From a technical standpoint, there should be few problems in getting such

a system up and running.  However, there are a few details that would need

to be worked out.  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.  This is assigned to each

article in any of up to 4,000 biomedical journals.  Docster should work well

for a group of journals like this whose articles are uniquely identified.  However,

what about the remaining 70,000 biomedical publications whose articles are

not indexed?  Is it possible to create a method of uniquely identifying articles

that people receive that are not routinely indexed such as those in MEDLINE?

For that matter, what about the non-biomedical world; is there any unique

identifier for journal articles in other fields?

 

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.  I suppose that if users see the benefits

of docster, they will try to keep electronic journal copies for longer periods of time. 

Eventually, hard disks become cluttered with bitmapped images, and users will

want to remove older articles.  The oldest articles will tend to become deleted first

from user's computers, which is probably okay, since researchers tend to

request recent publications from their libraries. A better model for document

retention might be Carl Uncover' central storage scenario, in which all articles are

kept forever, and the collection keeps on building without end.  In that case, old

articles will never be lost.

 

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.  While the first two methods have InBoxes, where received

documents are stored until deleted, there is no InBox for web deliveries.  Documents

received through the web may be either printed directly via a client such as Adobe

Acrobat Reader, or stored first on disk.  But if it is stored on disk, there is no consistent

directory for storage.  Users of docster would have to configure their docster client software to

point to the directory (or directories) where documents are stored.  Would docster be

intelligent enough to be able to extract an attachment from a MIME email message?

Or would users have to do this themselves and save all document deliveries into a

special directory that docster would use?  In my experience, I've found some users who don't

have the slightest idea how to save a MIME email attachment.  This is all food for thought,

and details would have to be worked out.

 

Speaking of Carl Uncover, what happened to the lawsuit?  I saw that Carl Uncover was sold

to another company earlier this year, but did it affect the lawsuit?  Last I heard, Carl was

found guilty and was going to appeal.  It looked pretty bleak for a company that had a great

idea.  Apparently it was not enough to get permission from 6,000 publishers to keep electronic

copies of journal articles from their publications...it was also necessary to get permission from

all article authors, who might be dead or alive, and whose numbers might total in the millions.

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.

 

Frank Walker