Skip to Content.
Sympa Menu

acawiki-general - Re: [acawiki-general] 33 GB of Scientific Papers - and a Manifesto - Uploaded to Pirate Bay

acawiki-general AT lists.ibiblio.org

Subject: Acawiki-general mailing list

List archive

Chronological Thread  
  • From: pitman AT stat.Berkeley.EDU (Jim Pitman)
  • To: ml AT gondwanaland.com, jon AT fabricatorz.com
  • Cc: acawiki-general AT lists.ibiblio.org
  • Subject: Re: [acawiki-general] 33 GB of Scientific Papers - and a Manifesto - Uploaded to Pirate Bay
  • Date: Tue, 26 Jul 2011 09:25:03 -0700

Jon Phillips <jon AT fabricatorz.com> wrote:

> Reminds me, that one approach we could do is simliar to what we were doing
> with openlibrary in bringing in as many bibtex and other
> bibliographic records for academic literature to provide stubs/starters.

I'm working on this in collaboration with others in the UK. See
http://bibserver.okfn.org/roadmap/open-bibliography-for-stm/
especially Section 6.6 BibSoup

The use of lightweight technology has allowed us to create a radically new
approach towards the collection of Open bibliography. Conventional wisdom
would suggest that all bibliographic records should be normalised and
validated by a central authority. In BibJSON, we take the view that any Open
bibliographic record (with its provenance) is potentially valuable, even
though there may be duplicates referring to âœthe same bibliographic
objectâ. The question of determining whether two records relate to âœthe
same object❠is difficult and controversial and BibSoup deliberately avoids
this. It consists of a number of collections of bibliography (initially in
STM areas) united by a common syntax. It is left to humans and machines to
develop annotations and equalities between the components of these
collections. Thus, for example, âœthe same paper❠will be reported in arXiv,
DBLP and possibly even Medline.

The BibSoup approach encourages the contribution of Open bibliography without
the overhead of de-duplication at contribution time. We expect that, as it
grows, services will develop that help users and maintainers to manage the
information. De-duplication into a central repository may be one solution
(with the presumed platonic identity of STM bibliographic entries), but we
also expect that software based on RDF will allow tools to manage alternative
representations of bibliographic data, leaving the choice to the user as to
what strategy they take. In short, current STM bibliography is a distributed
mess. BibSoup takes this as a starting point and, where the political will
and financial support is available, offers methods for tidying this up.

> Another approach is we can ally with some machine summary researchers to
> read through papers that are available and provide some machine
> summaries as starters for human reviewers. Its not a bad idea and provides
> us with some hooks into development communities.

I agree in principle. But I think we encounter the problem that
either: summaries are already available (e.g. arXiv and RePEc data, or
researcher's homepages)
or: this action would be restricted by publisher terms of service.
Would have to tread very carefully around the publisher terms to keep this
legal. This will be complex and vary from
publisher to publisher. Not clear to me that its in acawiki's interest to do
anything that pushes this legal envelope too early.
I would rather see acawaki focus on support of BibSoup as a melting pot for
acawiki users to easily find things they think
are worth summarizing. The needed biblio metadadata is arguably born in the
public domain, and with some crowdsourcing of its acquisition and
maintenance it may be possible to keep it so in large quantities.


--Jim

----------------------------------------------
Jim Pitman
Director, Bibliographic Knowledge Network Project
http://www.bibkn.org/

Professor of Statistics and Mathematics
University of California
367 Evans Hall # 3860
Berkeley, CA 94720-3860

ph: 510-642-9970 fax: 510-642-7892
e-mail: pitman AT stat.berkeley.edu
URL: http://www.stat.berkeley.edu/users/pitman




Archive powered by MHonArc 2.6.24.

Top of Page