Re: [CODE4LIB] libxess
Impressive sample. kst Godmar Back [EMAIL PROTECTED] 5/8/2007 5:57 PM On 5/8/07, Karen Tschanz [EMAIL PROTECTED] wrote: Hi, Godmar: I would be interested in receiving links from libraries that has implemented this, so that I could see the results. Thanks for your help! Given that what I propose is still in the design phase/vaporware, asking for examples may be premature yet here is one: http://libx.org/libxess/cue.html shows what a possible application of this technology might look like. Also, keep in mind that what I'm proposing is not a new service that libraries could deploy directly to their users -- rather, it's a piece of infrastructure that would allow libraries to deploy services built on this infrastructure to their users. It's a bit of a chicken and an egg problem, except that we will go ahead and provide an initial chicken (LibX) and an initial egg (David's script.) - Godmar
[CODE4LIB] libxess
Hi, following up on our discussion about how to extract holdings information from a III catalog, and following David's generous offer to share his code, I went ahead and started a sourceforge project: libxess. libxess is intended to bridge the gap between Library 2.0 services and legacy ILS such as III Millennium and others. See the picture at http://libxess.sourceforge.net/ It is intended to provide a simple, yet clean web interface to a set of proxy scripts which in turn handle the specific access to those legacy systems. We have an immediate if mundane use for libxess in LibX: we'd like to show people what their library holds. Although we could have included this functionality via screen-scraping into the client, we felt for various reasons that it may be better to keep this as an optional, server-side service. Our vision is that if a library installs libxess, then it can benefit from all services that are libxess-enabled. - LibX being just one of them. lnstalling libxess should be a low overhead operation, such as uploading a few php scripts to a server. Our target audience are not programmers, they're librarians who may have limited access to their ILS (*), but who usually have access to a web server and a place to run php scripts. I feel that many library-related projects, at least in as much as they interact with existing ILS, would benefit from such a facility, and, to my knowledge, there doesn't seem to be such a facility as of know. For this reason, I'd like to invite interested people to either contribute or give their input. You could contribute by, for instance, providing code for your catalog or whichever system you'd like to see supported. If so, give me your sourceforge account and I'll set you up with CVS access. Let me propose to use the sourceforge forum at http://sourceforge.net/forum/forum.php?forum_id=693773 for discussions. A related question is what the exported interface for this service should be. Right now, there's none. David's script returns MARC-XML. I'm wondering if this may be an application for unapi (and for me finally reason to read through its spec ;-). I had also considered OpenURL v0.1, but as an outsider I really know too little about library APIs and formats, so I'd be grateful for input here. Simplicity is paramount. - Godmar (*) Keeping in mind that in some III-based libraries, you have to have reached a status that's comparable to OT4 just to gain the privilege to contact the vendor's helpdesk.
Re: [CODE4LIB] libxess
Hi, Godmar: I would be interested in receiving links from libraries that has implemented this, so that I could see the results. Thanks for your help! kst Godmar Back [EMAIL PROTECTED] 5/8/2007 3:37 PM Hi, following up on our discussion about how to extract holdings information from a III catalog, and following David's generous offer to share his code, I went ahead and started a sourceforge project: libxess. libxess is intended to bridge the gap between Library 2.0 services and legacy ILS such as III Millennium and others. See the picture at http://libxess.sourceforge.net/ It is intended to provide a simple, yet clean web interface to a set of proxy scripts which in turn handle the specific access to those legacy systems. We have an immediate if mundane use for libxess in LibX: we'd like to show people what their library holds. Although we could have included this functionality via screen-scraping into the client, we felt for various reasons that it may be better to keep this as an optional, server-side service. Our vision is that if a library installs libxess, then it can benefit from all services that are libxess-enabled. - LibX being just one of them. lnstalling libxess should be a low overhead operation, such as uploading a few php scripts to a server. Our target audience are not programmers, they're librarians who may have limited access to their ILS (*), but who usually have access to a web server and a place to run php scripts. I feel that many library-related projects, at least in as much as they interact with existing ILS, would benefit from such a facility, and, to my knowledge, there doesn't seem to be such a facility as of know. For this reason, I'd like to invite interested people to either contribute or give their input. You could contribute by, for instance, providing code for your catalog or whichever system you'd like to see supported. If so, give me your sourceforge account and I'll set you up with CVS access. Let me propose to use the sourceforge forum at http://sourceforge.net/forum/forum.php?forum_id=693773 for discussions. A related question is what the exported interface for this service should be. Right now, there's none. David's script returns MARC-XML. I'm wondering if this may be an application for unapi (and for me finally reason to read through its spec ;-). I had also considered OpenURL v0.1, but as an outsider I really know too little about library APIs and formats, so I'd be grateful for input here. Simplicity is paramount. - Godmar (*) Keeping in mind that in some III-based libraries, you have to have reached a status that's comparable to OT4 just to gain the privilege to contact the vendor's helpdesk.
Re: [CODE4LIB] libxess
I have been working on very similar things for Horizon. I guess Horizon won't be along long, but I'll try to take a look at what you've done and see if I can fit my Horizon stuff into the framework. If it's too much trouble to fit my stuff into your framework though... Jonathan Karen Tschanz wrote: Hi, Godmar: I would be interested in receiving links from libraries that has implemented this, so that I could see the results. Thanks for your help! kst Godmar Back [EMAIL PROTECTED] 5/8/2007 3:37 PM Hi, following up on our discussion about how to extract holdings information from a III catalog, and following David's generous offer to share his code, I went ahead and started a sourceforge project: libxess. libxess is intended to bridge the gap between Library 2.0 services and legacy ILS such as III Millennium and others. See the picture at http://libxess.sourceforge.net/ It is intended to provide a simple, yet clean web interface to a set of proxy scripts which in turn handle the specific access to those legacy systems. We have an immediate if mundane use for libxess in LibX: we'd like to show people what their library holds. Although we could have included this functionality via screen-scraping into the client, we felt for various reasons that it may be better to keep this as an optional, server-side service. Our vision is that if a library installs libxess, then it can benefit from all services that are libxess-enabled. - LibX being just one of them. lnstalling libxess should be a low overhead operation, such as uploading a few php scripts to a server. Our target audience are not programmers, they're librarians who may have limited access to their ILS (*), but who usually have access to a web server and a place to run php scripts. I feel that many library-related projects, at least in as much as they interact with existing ILS, would benefit from such a facility, and, to my knowledge, there doesn't seem to be such a facility as of know. For this reason, I'd like to invite interested people to either contribute or give their input. You could contribute by, for instance, providing code for your catalog or whichever system you'd like to see supported. If so, give me your sourceforge account and I'll set you up with CVS access. Let me propose to use the sourceforge forum at http://sourceforge.net/forum/forum.php?forum_id=693773 for discussions. A related question is what the exported interface for this service should be. Right now, there's none. David's script returns MARC-XML. I'm wondering if this may be an application for unapi (and for me finally reason to read through its spec ;-). I had also considered OpenURL v0.1, but as an outsider I really know too little about library APIs and formats, so I'd be grateful for input here. Simplicity is paramount. - Godmar (*) Keeping in mind that in some III-based libraries, you have to have reached a status that's comparable to OT4 just to gain the privilege to contact the vendor's helpdesk. -- Jonathan Rochkind Sr. Programmer/Analyst The Sheridan Libraries Johns Hopkins University 410.516.8886 rochkind (at) jhu.edu
Re: [CODE4LIB] libxess
Hi Godmar, Just FYI, David's script doesn't work with all III catalogs. Z39.50 might be a slightly better option (our's, for example, seems to produce errors from his test page). I'd be willing to work with you on it, if you're up for trying to figure out why it doesn't work in our case. - adam On Tue, May 08, 2007 at 03:37:16PM -0400, Godmar Back wrote: Hi, following up on our discussion about how to extract holdings information from a III catalog, and following David's generous offer to share his code, I went ahead and started a sourceforge project: libxess. libxess is intended to bridge the gap between Library 2.0 services and legacy ILS such as III Millennium and others. See the picture at http://libxess.sourceforge.net/ It is intended to provide a simple, yet clean web interface to a set of proxy scripts which in turn handle the specific access to those legacy systems. We have an immediate if mundane use for libxess in LibX: we'd like to show people what their library holds. Although we could have included this functionality via screen-scraping into the client, we felt for various reasons that it may be better to keep this as an optional, server-side service. Our vision is that if a library installs libxess, then it can benefit from all services that are libxess-enabled. - LibX being just one of them. lnstalling libxess should be a low overhead operation, such as uploading a few php scripts to a server. Our target audience are not programmers, they're librarians who may have limited access to their ILS (*), but who usually have access to a web server and a place to run php scripts. I feel that many library-related projects, at least in as much as they interact with existing ILS, would benefit from such a facility, and, to my knowledge, there doesn't seem to be such a facility as of know. For this reason, I'd like to invite interested people to either contribute or give their input. You could contribute by, for instance, providing code for your catalog or whichever system you'd like to see supported. If so, give me your sourceforge account and I'll set you up with CVS access. Let me propose to use the sourceforge forum at http://sourceforge.net/forum/forum.php?forum_id=693773 for discussions. A related question is what the exported interface for this service should be. Right now, there's none. David's script returns MARC-XML. I'm wondering if this may be an application for unapi (and for me finally reason to read through its spec ;-). I had also considered OpenURL v0.1, but as an outsider I really know too little about library APIs and formats, so I'd be grateful for input here. Simplicity is paramount. - Godmar (*) Keeping in mind that in some III-based libraries, you have to have reached a status that's comparable to OT4 just to gain the privilege to contact the vendor's helpdesk.
Re: [CODE4LIB] libxess
On 5/8/07, Karen Tschanz [EMAIL PROTECTED] wrote: Hi, Godmar: I would be interested in receiving links from libraries that has implemented this, so that I could see the results. Thanks for your help! Given that what I propose is still in the design phase/vaporware, asking for examples may be premature yet here is one: http://libx.org/libxess/cue.html shows what a possible application of this technology might look like. Also, keep in mind that what I'm proposing is not a new service that libraries could deploy directly to their users -- rather, it's a piece of infrastructure that would allow libraries to deploy services built on this infrastructure to their users. It's a bit of a chicken and an egg problem, except that we will go ahead and provide an initial chicken (LibX) and an initial egg (David's script.) - Godmar
Re: [CODE4LIB] libxess
On 5/8/07, Adam Brin [EMAIL PROTECTED] wrote: Hi Godmar, Just FYI, David's script doesn't work with all III catalogs. Z39.50 might be a slightly better option (our's, for example, seems to produce errors from his test page). I'd be willing to work with you on it, if you're up for trying to figure out why it doesn't work in our case. Let's take the specific issues with your catalog off-list, but let me make one general point on list: I don't mean to prescribe or even propose a particular implementation (screenscraping, Z39.50, proprietary XML interface, etc.) - there could be multiple implementations, chosen by whoever wishes to export their legacy services. All that should be agreed upon is a set of query syntaxes and a set of response formats. Ideally, the cardinality of both sets should be small. As such, a Z39.50 to XML gateway is certainly an option if the produced XML is within the set of useful response formats. I tried using PHP/yaz for this purpose a couple of years ago - this worked so-so - it wasn't particularly fast. It is potentially harder to deploy since not everybody will be able to install libyaz.so on their servers, but for those that could it's certainly an option. I should point out, however, that the XML produced was not the nice MARC-XML that David's script produces, so it would require another conversion step. - Godmar
