 |
 |
Thanks Karen and Mark, I'll definitely look into the Drupal/biblio angle. The Views Datasource looks promising as well for the exposure piece... Mike On 6/28/2010 11:06 AM, Karen Coombs wrote: > I agree with Mark that the Biblio module would be really good for > this. I'm using it on a project right now to keep track of > publications related to particular OCLC Web services. Can add > additional fields with CCK if you want. Can create different displays > with Views. Should be able to expose the data for other applications > to consume as well. There are a few different options for this. Maybe > Mark has a particular suggestion about this? I've been doing it with > Views and Views Datasource. I also have played with the Services and > REST Server modules. > > Karen > > On Mon, Jun 28, 2010 at 12:51 PM, Mark A. Matienzo<[log in to unmask]> wrote: > >> If you're at all comfortable with Drupal, I suggest looking into the >> Biblio module:<http://drupal.org/project/biblio> >> >> Mark A. Matienzo >> Digital Archivist, Manuscripts and Archives >> Yale University Library >> >> >> On Mon, Jun 28, 2010 at 1:22 PM, Michael Lindsey >> <[log in to unmask]> wrote: >> >>> Hi all, >>> We periodically create bibliographies to support faculty projects and are at >>> the point where we either want to roll our own re-usable software or adopt >>> something from the wild. We need something that can understand library >>> metadata on the way in and on the way out. We also need something that can >>> be available as a data store to different webapps, e.g. a subject guide, a >>> faculty publications webapp, etc. In other words, we need the datastore to >>> be queryable from a script. >>> I'm looking at Zotero, which seems to be hot on the harvesting end, but >>> seems to be conceived of as a tool for a single researcher at their browser. >>> I would need to flash Zotero's SQLite instance to a db table on my >>> webserver so the data would be available to scripts. Ideally, my harvesting >>> team could interact with the web application directly so there would be no >>> harvesting/export/import latency. >>> Any ideas if this is something we've already tackled in libraryland? >>> Thanks, >>> Michael Lindsey >>> Law Library, UC Berkeley >>> >>> >>