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
>