Re: [CODE4LIB] Serials Solutions Summon

2009-04-21 Thread Dr R. Sanderson
Sorry, but, me too! Rob On Tue, 21 Apr 2009, Mike Taylor wrote: I, and most of the people I've worked with, have been using the terms metasearch, federated search, broadcast search and distributed search synonymously for years. Have they now settled down into having distinct meanings? If

Re: [CODE4LIB] Serials Solutions Summon

2009-04-21 Thread Dr R. Sanderson
Eric, How is this 'new type' of index any different from an index of OAI-PMH harvested material? Which in turn is no different from any other local search, just a different method of ingesting the data? Sounds like good PR to me, rather than a revolution ;) Rob On Tue, 21 Apr 2009, Eric

Re: [CODE4LIB] Serials Solutions Summon

2009-04-21 Thread Dr R. Sanderson
On Tue, 21 Apr 2009, Eric Lease Morgan wrote: On Apr 21, 2009, at 10:55 AM, Dr R. Sanderson wrote: How is this 'new type' of index any different from an index of OAI-PMH harvested material? Which in turn is no different from any other local search, just a different method of ingesting the data

Re: [CODE4LIB] ticTOCs makes its data available to developers

2009-02-12 Thread Dr R. Sanderson
How does this compare to Zetoc at Mimas, which also provides RSS feeds for journal ToCs? Rob On Thu, 12 Feb 2009, Boheemen, Peter van wrote: This is great !!! But don't forget the API ! Peter -Original Message- From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of

Re: [CODE4LIB] ticTOCs makes its data available to developers

2009-02-12 Thread Dr R. Sanderson
Thanks Terry, a really good comparison! One more that I came up with, in thinking about this slightly further ... ticTOCs is open to the public whereas ZETOC requires an institutional login to access the data. A big plus on ticTOCs' side! Rob On Thu, 12 Feb 2009, Bucknell, Terry wrote:

Re: [CODE4LIB] Latest OpenLibrary.org release

2008-05-08 Thread Dr R. Sanderson
I guess I don't understand why you'd prefer SRU to an API. The ideal Except SRU _is_ an API? However, if there was no API available, only a SRU service, wouldn't you complain about something else that SRU didn't do? Like what? The current API seems to be concerned with search. Search is

Re: [CODE4LIB] Latest OpenLibrary.org release

2008-05-07 Thread Dr R. Sanderson
* built an API http://www.openlibrary.org/dev/docs/api to the data which allows you to query the database for objects matching particular criteria or to GET an object from the database Not SRU? Any reasons why you rolled your own? Rob

Re: [CODE4LIB] Latest OpenLibrary.org release

2008-05-07 Thread Dr R. Sanderson
I'm the only non-techie on the team, so I don't know that much about SRU. (Our head programmer lives in India, and is presumably asleep at the moment, otherwise I'd ask him!) Is it an interface that is used primarily by libraries? We are definitely hoping that our API will be used by all

Re: [CODE4LIB] Latest OpenLibrary.org release

2008-05-07 Thread Dr R. Sanderson
I shouldn't respond to such blatant trolling, but heh... On Wed, 7 May 2008, Casey Durfee wrote: SRU is crap, in my opinion -- overengineered and under-thought, incomprehensible to non-librarians and burdened by the weight of history. What is so incomprehensible about it? Is it the fact it

Re: [CODE4LIB] [c4lj-articles] SPARC Europe and the DOAJ Announce the Launch of the SPARC Europe Seal for Open Access Journals

2008-04-25 Thread Dr R. Sanderson
The intention of the scheme is to motivate open access journals to deliver metadata to DOAJ. The DOAJ team will then convert the metadata into standardized XML-format and OAI-compliant format, which will further increase the visibility of articles and provide means for the easiest possible

Re: [CODE4LIB] many processes, one result

2008-02-18 Thread Dr R. Sanderson
And Perl's fork() explained: http://hell.jedicoder.net/?p=82 Enjoy :) Rob On Mon, 18 Feb 2008, Kevin S. Clarke wrote: Hi Eric, you wrote: How do I write a computer program that spawns many processes but returns one result? ... Is the idea of threading in Java suppose to be able to