[VUFIND-295] Perform VuFind searches in response to Z39.50 protocol requests Created: 27/Jul/10 Updated: 30/May/23 |
|
| Status: | Reopened |
| Project: | VuFind® |
| Components: | Search |
| Affects versions: | None |
| Fix versions: | Wishlist |
| Type: | New Feature | Priority: | Minor |
| Reporter: | Demian Katz | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 2 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Description |
|
Add the ability for VuFind to respond to Z39.50 search requests.
|
| Comments |
| Comment by Demian Katz [ 18/May/11 ] |
|
For future reference: Z39.50 specification - http://www.loc.gov/z3950/agency/document.html Existing Z39.50 software - http://www.loc.gov/z3950/agency/resources/software.html |
| Comment by Filipe MS Bento [ 18/May/11 ] |
|
:: EDIT :: Comment moved to the proper entry, http://vufind.org/jira/browse/VUFIND-122 (consume, not provided z39.50 services) |
| Comment by David Maus [ 23/Sep/12 ] |
| I would call this a Won't Fix: AFAIK z39.50 is not based on HTTP transport. In order to support z39.50 /requests/ we would have to implement an entire z39.50 server -- in PHP. No way. |
| Comment by Filipe MS Bento [ 23/Sep/12 ] |
|
David, hi! Yes, native Z39.50 would require a gateway (but there are plenty out there) to do the S&R and then we would need to parse the results. But, that is gone by now: please refer to http://vufind.org/jira/browse/VUFIND-122 (mentioned above): Z39.50 via a SRU/SRW service like, lets say, using PazPar2 "passe par tout" (French). Thanks, Filipe EDIT: for the record Christopher Hallberg (V.Univ) and Mohan Pradhan (HealthNet Nepal) are already working in implementing a Pazpar2 module for VuFind 2.0 (ZF2), as mentioned by Demian in this e-mail: from: Demian Katz demian.katz@villanova.edu via lists.sourceforge.net sender-time: Sent at 1:24 PM (UTC). Current time there: 12:30 PM. to: Hugo Agud <hagud@>, vufind-tech <vufind-tech@lists.sourceforge.net> cc: Christopher Hallberg <challber@>, "mpradhan@" <mpradhan@> date: Fri, Sep 21, 2012 at 1:24 PM subject: Re: [VuFind-Tech] Developing Vufind: Sponsoring |
| Comment by David Maus [ 24/Sep/12 ] |
|
Hi Filipe, Okay, so I call it a won't fix, superseded by |
| Comment by David Maus [ 24/Sep/12 ] |
|
Superseded by |
| Comment by Demian Katz [ 24/Sep/12 ] |
|
There is a lot of confusion between this ticket and This ticket is about VuFind being able to respond to Z39.50 requests. (PROVIDER functionality). As a result, I am reopening this ticket. There may still be a need for a VuFind system to respond to Z39.50 requests. I understand that this is a non-trivial task; that is why this is on the wishlist rather than assigned to a particular version. I also don't advocate attempting to write a Z39.50 server in PHP -- if this problem really needs to be solved, it may need to be done by writing connectors for an existing third-party system. Perhaps what we need is not new VuFind code but rather a recipe for combining existing tools. In any case, until some kind of solution is devised, I'm going to leave this open for tracking comments on the problem. I am also renaming both tickets in an effort at improving clarity. |
| Comment by Filipe MS Bento [ 24/Sep/12 ] |
|
Demian, David, hi! Yes, I knew that once, the diference between these two tickects but totally forgot about so that’s why I linked both. Yes, I remember this one was about providing z39.50 support (make available VuFind index to be searched via external clients using z39.50 protocol). This would be great for a lot of purposes, mainly to use within our official (UA) reference manager software, Thomson Reuters’ EndNote, to perform queries in our local VuFind (or others) within it, and retrieve the desired records, as the other integrated local sources, besides the OPAC, do not offer such capability (DSpace and OJS – but they do allow export to Endnote). Making a simple google search, https://www.google.pt/search?q=z39.50+solr, one finds at the first entry, although from 2008, a possible way to do it; I mean it’s better to connect the service to SOLR than to a VuFind layer over it, right? Thanks and sorry, but I totally forgotten about the purpose and difference of these two tickets; their new name make much easier to identify their purpose. Filipe EDIT: and I see that I've placed that difference in my comment above, dated 18/May/11 3:05 PM... :| Thank you, Demian, for your above average (to say the least) memory! :) |
| Comment by Filipe MS Bento [ 24/Sep/12 ] |
|
Looking at http://k-int.blogspot.pt/2008/05/exposing-solr-services-as-z3950-server.html it seems something I can actually do... just a question of remembering the Z39.50 mapping / attributes, consult its documentation. Btw Z39.50 has an ISO norm that is ISO23950 (see the resemblances? “Z” > “2”, but I believe ISO stopped at the 1998 version of it and LOC carried on developing it into the most current one, Z39.50:2003 --- althought there is also a NISO version, that I believe is the same: http://www.niso.org/standards/resources/Z39.50_Resources (the link in LOC’s page gives a 404, not available anymore). The question is just one: time and commitments made that have to honor… :| Filipe |
| Comment by Demian Katz [ 24/Sep/12 ] |
|
Thanks, Filipe! A couple of thoughts: 1.) I wouldn't want you to waste time on this if nobody actually needs it. For now, I think this is more of a theoretical need than an actual one. If anybody really needs this, it would be helpful if they could post here and explain their use case. If nobody posts a use case, I would recommend using your time on other projects for the moment. 2.) Routing Z39.50 requests directly to VuFind's Solr index certainly sounds like an easy approach... but then you lose the benefits of VuFind's intermediate processing (record drivers, etc.). It's probably good enough for many use cases, but it may be lacking in others. Again, without a real-life use case, it's hard to comment on the best solution. And, just for the record, one possible future real-life use case: a number of libraries are going to be switching over to a new open source ILS called Kuali OLE in the next year or two. OLE does not include a user interface -- tools like VuFind will be recommended to serve as the front end. It is unclear at this point if OLE will also have Z39.50 support. If it does not, there may be a demand for support through VuFind. If it does, this may be a non-issue. |
| Comment by Ere Maijala [ 08/Dec/22 ] |
| As I happened to stumble on this I’ll just add a quick note that it might make sense to implement an SRU server instead, and provide instructions on how to set up something like [Metaproxy|https://www.indexdata.com/resources/software/metaproxy/] on top of it. Or implement a Metaproxy connector for the VuFind search API. |
| Comment by Demian Katz [ 08/Dec/22 ] |
| Agreed: I don’t think it makes any sense to try to build Z39.50 natively, but it would be good to have a documented best practice solution. |
| Comment by Demian Katz [ 30/May/23 ] |
| See [https://openlibraryfoundation.atlassian.net/browse/VUFIND-1530|https://openlibraryfoundation.atlassian.net/browse/VUFIND-1530|smart-link] for notes on a metaproxy-based solution that may help with both SRU and Z39.50 use cases. |