Re: [CODE4LIB] local APIs atop III's Sierra DB
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:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Rob Casson Sent: Wednesday, October 16, 2013 1:05 PM To: CODE4LIB@LISTSERV.ND.EDU 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 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 >
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 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 >
Re: [CODE4LIB] local APIs atop III's Sierra DB
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
Re: [CODE4LIB] local APIs atop III's Sierra DB
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 built some utility code that has grown into a handful Perl modules that I use regularly in creating new reports. Most of these are special-purpose for applications we have in-house but I'm trying to find ways to generalize them. Examples: wrapper functions around the Patron Update Web Service, functions to look-up shelf location names, find/clean up patron data entry errors, etc * 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. I'm aware of two github repo's that might be of interest in this conversation: * https://github.com/mcoia/sierra_marc_tools * https://github.com/geekmuse/sierra-perl-scripts 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. ) Nonetheless, I'd definitely be interested in collaborating on anything that might benefit all Sierra users. Feel free to contact me off-list if you want to chat more. ~Dave On Tue, Oct 15, 2013 at 5:36 PM, Julia Bauder wrote: > Jason, > > To expand on Becky's answer a bit: we haven't written our own APIs yet, but > I did write a Sierra driver for VuFind, so I do have some notes that might > be useful to you that I'm happy to share. At least, I've learned the hard > way some things that you don't want to do when you're querying the > database. ;-) > > Julia > > * > > Julia Bauder > > Social Studies and Data Services Librarian > > Grinnell College Libraries > > Sixth Ave. > > Grinnell, IA 50112 > > > 641-269-4431 > > > > > > On Tue, Oct 15, 2013 at 2:41 PM, Becky Yoose wrote: > > > Hi Jason, > > > > We haven't planned to write our own APIs for Sierra at this point (we're > > still working on getting Sierra to work in the first place), but Grinnell > > would be interested in seeing how the process goes for you in terms of > > local API building. > > > > As for the Sierra APIs - III just hired a new API project manager (the > one > > that attended #c4l13 has since left the company) so I'm not sure what's > all > > going on. They are still saying that patron facing APIs will be out by > > winter, though I'd wish the staff facing APIs would get some love too... > > > > Thanks, > > Becky > > > > - > > Becky Yoose > > Discovery and Integrated Systems Librarian > > Grinnell College > > > > > > On Tue, Oct 15, 2013 at 2:29 PM, Thomale, Jason > >wrote: > > > > > Hello Code4lib, > > > > > > I'm wondering if any III Sierra users out there have worked on building > > an > > > API for accessing their ILS data on top of Sierra's Postgres database. > > > Right now I'm looking into possibly building something to serve local > > needs > > > and use cases, as we're not terribly confident that III's forthcoming > > > APIs--if they are indeed forthcoming--will really fit the bill. > > > > > > If this is something you're doing or have considered doing and wouldn't > > > mind comparing notes, please drop me a line! Thanks. > > > > > > Jason Thomale > > > Resource Discovery Systems Librarian > > > University of North Texas > > > > > >
Re: [CODE4LIB] local APIs atop III's Sierra DB
Jason, To expand on Becky's answer a bit: we haven't written our own APIs yet, but I did write a Sierra driver for VuFind, so I do have some notes that might be useful to you that I'm happy to share. At least, I've learned the hard way some things that you don't want to do when you're querying the database. ;-) Julia * Julia Bauder Social Studies and Data Services Librarian Grinnell College Libraries Sixth Ave. Grinnell, IA 50112 641-269-4431 On Tue, Oct 15, 2013 at 2:41 PM, Becky Yoose wrote: > Hi Jason, > > We haven't planned to write our own APIs for Sierra at this point (we're > still working on getting Sierra to work in the first place), but Grinnell > would be interested in seeing how the process goes for you in terms of > local API building. > > As for the Sierra APIs - III just hired a new API project manager (the one > that attended #c4l13 has since left the company) so I'm not sure what's all > going on. They are still saying that patron facing APIs will be out by > winter, though I'd wish the staff facing APIs would get some love too... > > Thanks, > Becky > > - > Becky Yoose > Discovery and Integrated Systems Librarian > Grinnell College > > > On Tue, Oct 15, 2013 at 2:29 PM, Thomale, Jason >wrote: > > > Hello Code4lib, > > > > I'm wondering if any III Sierra users out there have worked on building > an > > API for accessing their ILS data on top of Sierra's Postgres database. > > Right now I'm looking into possibly building something to serve local > needs > > and use cases, as we're not terribly confident that III's forthcoming > > APIs--if they are indeed forthcoming--will really fit the bill. > > > > If this is something you're doing or have considered doing and wouldn't > > mind comparing notes, please drop me a line! Thanks. > > > > Jason Thomale > > Resource Discovery Systems Librarian > > University of North Texas > > >
Re: [CODE4LIB] local APIs atop III's Sierra DB
Hi Jason, I've started looking into using ActiveRecord in Rails to plug into the Sierra Postgres tables. I'm still learning how to work with Ruby and Rails, but initial experiments are working: https://github.com/jamesvanmil/ActiveSierra (really have just written a few simple models with some relationships) James Van Mil Collections & Electronic Resources Librarian University of Cincinnati Libraries Telephone: (513)556-1410 vanmi...@ucmail.uc.edu -James -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Thomale, Jason Sent: Tuesday, October 15, 2013 3:29 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: [CODE4LIB] local APIs atop III's Sierra DB Hello Code4lib, I'm wondering if any III Sierra users out there have worked on building an API for accessing their ILS data on top of Sierra's Postgres database. Right now I'm looking into possibly building something to serve local needs and use cases, as we're not terribly confident that III's forthcoming APIs--if they are indeed forthcoming--will really fit the bill. If this is something you're doing or have considered doing and wouldn't mind comparing notes, please drop me a line! Thanks. Jason Thomale Resource Discovery Systems Librarian University of North Texas
Re: [CODE4LIB] local APIs atop III's Sierra DB
On Tue, Oct 15, 2013 at 07:29:01PM +, Thomale, Jason wrote: > Hello Code4lib, > > I'm wondering if any III Sierra users out there have worked on building an > API for accessing their ILS data on top of Sierra's Postgres database. Right > now I'm looking into possibly building something to serve local needs and use > cases, as we're not terribly confident that III's forthcoming APIs--if they > are indeed forthcoming--will really fit the bill. > > If this is something you're doing or have considered doing and wouldn't mind > comparing notes, please drop me a line! Thanks. Very early days but I am. As b.yoose@ mentioned it looks like a Fall timeline for that (December 31st is my prediction) I will share notes with you if not outright do a proposal for IUG 2014. Otherwise contact me directly. Cheers, ./fxk > > Jason Thomale > Resource Discovery Systems Librarian > University of North Texas -- Q: How many Martians does it take to screw in a light bulb? A: One and a half.
Re: [CODE4LIB] local APIs atop III's Sierra DB
Hi Jason, We haven't planned to write our own APIs for Sierra at this point (we're still working on getting Sierra to work in the first place), but Grinnell would be interested in seeing how the process goes for you in terms of local API building. As for the Sierra APIs - III just hired a new API project manager (the one that attended #c4l13 has since left the company) so I'm not sure what's all going on. They are still saying that patron facing APIs will be out by winter, though I'd wish the staff facing APIs would get some love too... Thanks, Becky - Becky Yoose Discovery and Integrated Systems Librarian Grinnell College On Tue, Oct 15, 2013 at 2:29 PM, Thomale, Jason wrote: > Hello Code4lib, > > I'm wondering if any III Sierra users out there have worked on building an > API for accessing their ILS data on top of Sierra's Postgres database. > Right now I'm looking into possibly building something to serve local needs > and use cases, as we're not terribly confident that III's forthcoming > APIs--if they are indeed forthcoming--will really fit the bill. > > If this is something you're doing or have considered doing and wouldn't > mind comparing notes, please drop me a line! Thanks. > > Jason Thomale > Resource Discovery Systems Librarian > University of North Texas >
[CODE4LIB] local APIs atop III's Sierra DB
Hello Code4lib, I'm wondering if any III Sierra users out there have worked on building an API for accessing their ILS data on top of Sierra's Postgres database. Right now I'm looking into possibly building something to serve local needs and use cases, as we're not terribly confident that III's forthcoming APIs--if they are indeed forthcoming--will really fit the bill. If this is something you're doing or have considered doing and wouldn't mind comparing notes, please drop me a line! Thanks. Jason Thomale Resource Discovery Systems Librarian University of North Texas
