Hi,
On Wed, 14 Oct 1998, "Thomas Krichel <T.Krichel_at_surrey.ac.uk>" wrote:
> In my own discipline, economics (which is another discipline that uses
> preprints), some very able and dedicated pople have set a central
> archive a la XXX, i.e. a disk where all preprints are kept centrally.
> The reponse has been muted. Today, this archive stores less than 10% of
> the total electronic holdings and its share is falling. XXX has failed in
> economics.
The econ archive was created back when Ginsparg would set up independent
servers for running archives (cond-mat and astro-ph were similar in physics,
alg-geom and funct-an in math). It became apparent that such archives
weren't maintained efficiently or kept current. Thus archives were brought
back in from the cold and have been much better maintained. I don't think
the econ one was kept current at all and it was never brougt back under the
central server. I had thought that one reason that things weren't catching
on in economics was that publishers had more restrictive policies about
preprint circulation, but maybe I am misinformed.
> The system that is winning the critical mass is a
> distributed system called RePEc where lots of archives, some large
> some small share one metadata format. The metadata can then be
> collected to build user interfaces. RePEc does not have an official
> user interface, but there are several user interfaces that compete for
> the users' favour. So the basic philosophy is
>
> many archives ---> one dataset ---> many user interfaces
xxx is
one archive, many mirrors -> one dataset -> many user interfaces
The math archives have an alternative interface maintained by Greg
Kuperberg (
http://front.math.ucdavis.edu/) for instance. NSCTRL access to
xxx is another.
> Documentation on the concepts underlying RePEc can be found
> at http://www.nber.org/RePEc. Examples of interfaces are found
> at http://netec.mcc.ac.uk/WoPEc.html, http://ideas.uqam.ca
> and http://netec.wustl.edu/NEP.
>
> So much far for economics, which is a discipline I know quite well ;-)
There is nothing wrong with this kind of interface. The problem is that in
a distributed system, many more people have to maintain many more servers.
Experience in physics and math has shown that you end up with a very mixed
bag of quality detrimental to both authors and readers. Are all servers
high-availibility servers? Are they run by a grad student who will move on
at some point leaving it to languish? Do they keep abreast with the latest
technical developments and migrate to new formats as needed? Adding a new
subject area to xxx is basically cookie cutter mechanics now and you get a
lot of functionality immediately. Hence, the CS decision to create a new
archive on xxx and provide an alternative interface through NCSTRL.
> Now consider the next statement:
>
> > It is already doing so. It lately subsumed computer science too.
>
> I think that Stevan is referring to the Computing Research Repository.
> Let me quote from http://www.acm.org/repository/
>
[...]
> We settled on a hybrid approach that combines the best features
> of LANL and NCSTRL, and secured the cooperation of the two
> groups. We will be able to use the well-tested LANL software
> for submission, notification, and searching. The NCSTRL
> architecture will make it easy to build new gateways from which
> to access the files, with a more user-friendly interface and
> new features. (In fact, LANL will now be a node on NCSTRL.)
>
> My interpretation of this last sentence is that NCSTL has subsumed XXX,
> rather than "XXX subsumed computer science". In fact that proposed
> architecture seems to be close to what I outlined for the RePEc system,
> although it is not spelled out in these terms. Please correct me if I
> am wrong.
Your interpretation is disputable. It is a hybrid, but really it is all xxx
with an alternative retreival-only interface via NCSTRL. They use xxx for
submission, mirroring, noitification, file conversions, etc. Becoming a node
merely means implementing the DIENST protocol on xxx and not much more than
that. There is no 'subsuming', nor is there any competition. Personally I
find it difficult to use NCSTRL-like interfaces for navigating around.
> My conclusion here is this: xxx is a good system but it is not the only
> path towards a solution of the distributing electronic research
> documents through the internet. Differnet disciplines will take
> different approaches.
Perhaps, but the example from CS doesn't really support your case. How
reliable is retrieval from RePEc? Do you run into dead links often? Does the
quality of the PDF's that you download vary greatly? Are all servers
reliably backed up? I don't think you should write off the advantages of
having a scalable centralized (but mirrored) repository. Anyway, xxx
cooperatively operates with things like NSCTRL, so I don't see why it
couldn't do the same for RePEc. It certainly would be one of the more
dependable nodes....
Regards,
Mark Doyle
APS Research and Development
Received on Tue Aug 25 1998 - 19:17:43 BST