RefDB, RefBase, and news from the Z39.50 World
Recent discussion on the citeULike mailing list made reference to 2 reference management servers: RefDB and RefBase. They might be ok backends, but none has the (promised) functionalities of CiteULike.Org.
—–Original Message—–
From: citeulike-discuss-admin@lists.citeulike.org [mailto:citeulike-discuss-admin@lists.citeulike.org] On Behalf Of Bruce D’Arcus
Sent: Friday, May 27, 2005 7:46 AM
To: citeulike-discuss@lists.citeulike.org
Subject: Re: [CiteULike-discuss] citeUlike backendOn May 27, 2005, at 4:03 AM, Diwaker Gupta wrote:
> Since there has already been a lot of work in this area, I would
> highly recommend using a bibliography specific backend. In particular,
> I really like refdb (http://refdb.sf.net) — it supports sqlite,
> mysql, pgsql; mutliple input formats (bibtex, RIS, RISX), and best of
> all, can given formatted output (docbook, bibtex, html, and so on).I dunno. I think the focus should be on standards and functionality, which for me means supporting more than just bibtex (ris, refer/endnote, pubmed, mods would be a nice start), and it means ideally supporting SRU as a standard search/retrieve protocol.*
While RefDB is one way to get *some* of this, it’s not the only way.
Bruce
* The lead developer for the RefBase project managed to implement SRU support last week (in a few days IIRC), including writing his own CQL parser in PHP.
Both are bibiographical info storage. You can import, search, and export. RefBase also gives RSS feeds on querries you define, which is nice. It also allows linking of one ref to another, either by user input or via auto links ("title:ecosystem").
Things have finally moved forward in the Z39.50 world for the past a few years. SRW and SRU are the next generation searching mechanisms based on SOAP and the URL, respectively. And the underlying common querry language is the hope for the future of information retrieval (so was I told about Z39.50, which worked great on Endnote while Ovid supported it).
CQL, the ‘Common Query Language’, is a formal language for representing queries to information retrieval systems such as web indexes, bibliographic catalogs and museum collection information. The CQL design objective is that queries be human readable and human writable, and that the language be intuitive while maintaining the expressiveness of more complex languages.
Traditionally, query languages have fallen into two camps: Powerful and expressive languages which are not easily readable nor writable by non-experts (e.g. SQL, PQF, and XQuery), on one hand; one the other hand, simple and intuitive languages not powerful enough to express complex concepts (e.g. CCL or google’s query language). CQL’s goal is to combine simplicity and intuitiveness of expression with the richness of Z39.50’s type-1 query. As any good text based interface, CQL is intended to ‘do what you mean’ for simple, every day queries, while allowing means to express complex concepts when necessary
May 29th, 2005 at 6:25 pm e
FWIW, I wasn’t necessarily advocating RefBase against RefDB and/or CiteUlike. What I was advocating was the sort of standards support that the RefBase project has been adding. I’m not seeing this in CiteULike, and I won;’t use the service until it does better on this count. I’m writing some citation processing software and am co-project lead for the OpenOffice bibliographic project, but I’m not going to write custom code to support CiteUlike when there’s SRU.
May 30th, 2005 at 8:37 pm e
I agree with Bruce — I’d rather see CiteULike as an “application layer” on top of an open-source bibilographic database, such as RefBase or RefDB. I think the project can move forward much faster if Richard Cameron would consider open source the CiteULike code. Several months back I had a discussion with Richard, where I suggested having a distributed system rather than a single server. Richard had some legitimate concerns over fragmantation of the social interactions that is the core of CiteULike. He had a point.
On the other hand, Richard has promised to work on a backend API to allow batch importing and exporting reference entries and other functions. If a search API is in the working, then SRU might eventually be partially supported.
Going back to Bruce’s point, though, I don’t think of CiteULike as a searchable bibilographic database. It’s main attaction is to discover people sharing the same interests with you and then find articles from their readings that you would not normally think of looking for. I am ok with it if it’s not integrated with a word processor.
– gary