 |
 |
Thought I'd share this work put together by the folks in charge of our consortium: https://github.com/mcoia/sierra_marc_tools It's a Perl implementation. I haven't used it myself, but I know it can generate MARC records. Josh Welker -----Original Message----- From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Rob Casson Sent: Wednesday, October 16, 2013 1:05 PM To: [log in to unmask] Subject: Re: [CODE4LIB] local APIs atop III's Sierra DB i've done some very ugly, preliminary hacking at getting MARC records out: https://gist.github.com/roblivian/7012077 generally "works", but still need to account for more invalid MARC tags, "on-the-fly" records (non-MARC records, i.e. reserve items, ordered bibs, etc) On Wed, Oct 16, 2013 at 10:49 AM, Thomale, Jason <[log in to unmask]>wrote: > Everyone: You guys are fantastic. Thanks to those who have responded > thus far for being so willing to share. I will be contacting y'all > off-list, if you don't mind. :-) > > Just wanted to tag onto Dave's response here... > > > I've written a decent amount of code against Sierra, but I don't > > know if any of it amounts to an "API". > > > ... > > * I've also started creating little web services with mod_perl for > > use in a web-application I'm working on. Examples: a script that > > spits back item information in JSON when given an item barcode, a > > script that spits back a JSON list of all attached items when given > > a bib record number. Again these are mostly special purpose, but I > > have a notion to find ways to generalize them. > > Yes this is basically where I am right now and where this is coming from. > I've thrown together sort of a prototype app for helping us with some > inventory stuff we're doing, which consists of a really > quick-and-dirty web service that serves up JSON and a bootstrap/jQuery > front-end. For what it is--which at this point isn't much more than a proof-of-concept--it works. > But. In the coming year there are a lot of similar things we plan to > do, and building out a RESTful API to serve up catalog data in > particular ways seems like a logical step right now. > > Julia alluded to "some things you don't want to do when you're > querying the database," which is something I'm interested in talking about as well. > If my experiences are anything like yours, Julia, I'm finding things > just aren't indexed in ways that make it optimal for our use cases. > Namely, querying on most variable field data is out of the question if > you don't want multi-minute response times. It seems the only way to > get this to work well will be to dump portions of the database out to > an external document store / indexer. I'm primarily looking at serving > up JSON at this point, so probably something like Solr or > Elasticsearch. Learning from your experiences building a Sierra driver > for VuFind would be quite helpful and interesting. > > Francis, I'll be interested to see whether you're thinking along > similar lines or if you're going a totally different direction... > > > Sadly, I'm a team of one here and I'm a bit shy about the state my > > code is currently in, so I haven't published it anywhere. ( Also > > the way I use git locally is probably "wrong", not to mention there > > are probably passwords in old commits. ) > > No worries! I completely understand, and I share your shyness. Believe > me, I'm the last person that should judge. > > > Nonetheless, I'd definitely be interested in collaborating on > > anything that might benefit all Sierra users. > > Cool. I really appreciate it. I guess--at this point I'm still looking > at solving local needs first, but making it easy enough to extend to > new use cases. Or...at the very least doing something that will > provide for a good learning experience. :-) I don't know, it's still ideas. > > Thanks, > > Jason >