[Open-access] Fwd: FW: Freedom to mine factual information from Springer journals

[Naomi Lillie]

Response from Springer



---------- Forwarded message ----------
From: Stelt van der, Wim, Springer SBM NL <Wim.vanderStelt at springer.com>
Date: Mon, Mar 12, 2012 at 4:53 PM
Subject: Re: FW: Freedom to mine factual information from Springer journals
To: pm286 at cam.ac.uk


Peter,

I hope and expect this is a good base to continue working on this. I'd like
to stress that we always have been committed to be flexible and
constructive when talking about mining for non-commerci purposes.

Btw, has the issue with the license of springer open access articles you
mentioned ever been solved?


Wim

Wim van der Stelt
Springer
EVP Business Development


 *From*: Peter Murray-Rust [mailto:pm286 at cam.ac.uk]
*Sent*: Monday, March 12, 2012 05:45 PM

*To*: Bennett, Richard, Springer UK
*Cc*: pk219 at cam.ac.uk <pk219 at cam.ac.uk>; pbm2 at cam.ac.uk <pbm2 at cam.ac.uk>;
emc59 at cam.ac.uk <emc59 at cam.ac.uk>; Goerner, Bettina, Springer DE; Stelt van
der, Wim, Springer SBM NL
*Subject*: Re: FW: Freedom to mine factual information from Springer
journals



On Mon, Mar 12, 2012 at 4:16 PM, Bennett, Richard, Springer UK <
Richard.Bennett at springer.com> wrote:

> Dear Peter,****
>
> ** **
>
> Wim has asked me to look into this and get in touch with you.
>

Thanks very much Richard for your rapid response.  It is much appreciated.

> ****
>
> ** **
>
> The overall answer is yes Springer does support text mining of our content
> by users.  How we have gone about this in the recent past has been through
> various methods but generally we have been reticent about having a lot of
> systematic downloading on our live site because of fears over performance
> issues (we are currently on a third party platform run by Metapress and
> performance is an issue in general).  We have generally gone around this by
> supplying content to the requesting party to be hosted on their own servers
> and thus avoiding both the DNS errors and the performance drag – this is
> something we could offer for Cambridge if it is desirable.
>

This is understandable and resolvable with collaborative discussion.

> ****
>
> ** **
>
> That being said, we are just starting working with UCSC and their Genome
> browser project where they will be hitting the live site but their
> downloading is restricted to three documents a minute (their suggestion not
> ours) which will not cause any performance drag or set off any DNS errors.
>

This seems very constructive. I note that some agreements have been for a 5
second-delay.

> ****
>
> ** **
>
> We are more than happy to work out an acceptable solution to allow this
> kind of work and it may be that in the long term a separate text mining
>  server may have to be put in place if the demand keeps growing.
>

That is a good idea. There is also the possibility of some form of caching.


> We have a good relationship with the Cambridge library and this is a
> natural extension of our work there.****
>
> ** **
>
> Let me know if you have any questions or need more information.****
>
> **
>

I will. Unfortunately for me Springer is not among the largest publishers
of chemistry.

>  **
>
> Best regards****
>
> Richard****
>
>
> *Richard Bennett*
> Vice President Library Sales
> Northwestern Europe and Africa
> *__*
> Springer Science + Business Media B.V.****
>
> Van Godewijckstraat 30****
>
> PO Box 17, 3300 AA Dordrecht****
>
> The Netherlands****
>
> tel: +31 78 65 76 162****
>
> mob +31 629 42 01 34
>
> richard.bennett at springer.com
> www.springerlink.com
> *__* ****
>
> ** **
>
> ** **
>
>

-- 
Peter Murray-Rust
Reader in Molecular Informatics
Unilever Centre, Dep. Of Chemistry
University of Cambridge
CB2 1EW, UK
+44-1223-763069



-- 
Peter Murray-Rust
Reader in Molecular Informatics
Unilever Centre, Dep. Of Chemistry
University of Cambridge
CB2 1EW, UK
+44-1223-763069



-- 
Naomi Lillie
Foundation Administrator and Community Coordinator (Open Bibliography)
Open Knowledge Foundation
http://okfn.org/
Skype: n.lillie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/open-access/attachments/20120425/6a73e5e7/attachment.html>