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
>>>
>>>        
>>