 |
 |
The distributed library, where all patrons are both lenders and borrowers, is an intriguing concept, and it's great that you have a rudimentary system up to experiment with it. Aside from the unusual requirements of a distributed library, you have one thing which separates you from the masses of small libraries who set up systems for their resources: you're not using MS Access. I applaud your decision to build a webapp, though some might call this overkill. As long as your patrons are able to use the system, and you're having fun with the challenge, charge on ahead. I have a few questions and comments. I see you're storing only the title and location of each book in the Django database, and tying into MarcEdit for the rest of the record. I assume you're using MarcEdit for the Z39.50 client and the editing interface, but you might want to look into exporting the records from MarcEdit (as MARCXML, most likely) and ingesting them into the webapp database. Keeping the two databases in sync and communicating with each hit, especially once the webapp is on its own server, could become difficult. Also, you may want to allow for remote cataloging at some point. If you're really feeling adventurous, you might look into wrapping PyZ3950 into a cataloging app. I agree that a collection of that size doesn't warrant a search engine like Solr. Some icontains queries are probably enough if browsing alone doesn't suffice. Most circ apps don't display the history of patrons who have checked out an item, or a patron's history of checked-out items, for privacy reasons. Some even drop those records from the database, or anonymize them. Another thing that differentiates you from other small libraries attempting this sort of thing is your contacting of this list. Most of the readers here are used to big-data problems, where they're trying to make sense of the storage, maintenance, and display of millions of records, so it's a bit of work to scale the mind down to a situation such as yours. Also, most of us spend much of our time working around legacy systems, so the troubles of a small, young app are both foreign and envied. That's my way of explaining why you might not get much response here. And for heaven's sake, point a subdomain or something at that machine. No reason to pass around IP addresses in this day and age. On Sat, Apr 23, 2011 at 5:27 PM, Elliot Hallmark <[log in to unmask]> wrote: > All, > > It was at the end of last year that I came here saying I was writing an open > source ILS for a distributed (book sharing) library. While I had lots of > enthusiasm and time for it at the time, our development computer didn't have > the capacity to run a solr based discovery front end. Even though the back > end was ready for feedback (though still very alpha), I dallied in posting > the IP because there was no discovery layer. > > In the interest of moving forward, and since a complex discovery layer may > not be necessary for a while (not for < 100 books), here is the IP. Please > check it out and give feed back. Play around with whatever, this data isn't > real. > > http://72.48.75.76 > > If this IP changes, I'll let y'all know on this thread. > > Soon I would like to use this system at our private alternative > school<http://www.clearviewsudburyschool.org>in hopes that it would > facilitate folks letting us use their excellent > books, since they would be lending them, not donating them. Having a > database keeping track of who owns the books would give a little peace of > mind. in the future, setting up a network of libraries would be easy. > > notes: > > 1. This is a distributed library, where a book enters the system through a > primal loan (from owner to library), and is due back at some point. The > book or item can be further lent to a regular borrower, or to another > library (which inherits lending privilages). extending lending privilages > must be done through the administrative back end, so it wouldn't happen > accidentally. > > 2. The "discovery layer" is severely crippled because I don't want to write > a indexer for our MARC records unless it becomes necessary (ie, better > searching is needed but writing a VuFind driver or integrating with Kochief > isn't yet feasible). All books entered in this system also have MARC > records associated with them, so a solr or other front end can be added > later. > > 3. If you'd like to try uploading a MARC record, email it to me and I'll put > it up for anyone to enter through the cataloging app. > > 4. This is written in django. Hooray for python! > > 5. This is not at all perfect yet. here is my todolist so far (please add > to it): > > when checking a book out, do not allow a due date later than the current > lease on the book. > subtitle, does this really need to be limited to 100 characters? > create an end of day script that: > sends emails to books that are due back soon > sends emails to books that are overdue > activate fines model and add an Fine.calcuate() method > make a legit zipcode field. current one accepts <5 digits > > thanks for reading, > Elliot >