VuFind
  1. VuFind
  2. VUFIND-295

Perform VuFind searches in response to Z39.50 protocol requests

    Details

    • Type: New Feature New Feature
    • Status: Reopened
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: Wishlist
    • Component/s: Search
    • Labels:
      None

      Description

      Add the ability for VuFind to respond to Z39.50 search requests.

        Activity

        Hide
        David Maus added a comment -
        Superseded by VUFIND-122
        Show
        David Maus added a comment - Superseded by VUFIND-122
        Hide
        Demian Katz added a comment -
        There is a lot of confusion between this ticket and VUFIND-122. They are not intended to track equivalent functionality.

        This ticket is about VuFind being able to respond to Z39.50 requests. (PROVIDER functionality).

        VUFIND-122 is about VuFind being able to present results retrieved from a Pazpar2 system. (CONSUMER functionality, which may or may not be using Z39.50 somewhere under the hood; Pazpar2 is a generic federated searching environment).

        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.
        Show
        Demian Katz added a comment - There is a lot of confusion between this ticket and VUFIND-122 . They are not intended to track equivalent functionality. This ticket is about VuFind being able to respond to Z39.50 requests. (PROVIDER functionality). VUFIND-122 is about VuFind being able to present results retrieved from a Pazpar2 system. (CONSUMER functionality, which may or may not be using Z39.50 somewhere under the hood; Pazpar2 is a generic federated searching environment). 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.
        Hide
        Filipe M S Bento added a comment - - edited
        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! :)
        Show
        Filipe M S Bento added a comment - - edited 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! :)
        Hide
        Filipe M S Bento added a comment -

        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
        Show
        Filipe M S Bento added a comment - 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
        Hide
        Demian Katz added a comment -
        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.
        Show
        Demian Katz added a comment - 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.

          People

          • Assignee:
            Unassigned
            Reporter:
            Demian Katz
          • Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated: