Bug 18202

Summary: Define profiles for Z39.50 server targets
Product: Koha Reporter: David Cook <dcook>
Component: Z39.50 / SRU / OpenSearch ServersAssignee: Bugs List <koha-bugs>
Status: NEW --- QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low CC: m.de.rooy
Version: master   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11297
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:

Description David Cook 2017-03-03 01:10:07 UTC
Different Z39.50 servers support different use attributes using different profiles. 

NorZIG: http://www.norzig.no/profiles/profile2.1.html
Libraries Australia (LA): http://www.nla.gov.au/librariesaustralia/services/search/z3950/
Library of Congress (LOC): https://www.loc.gov/z3950/lcserver.html

More profiles: https://www.loc.gov/z3950/agency/profiles/profiles.html

In the case of Libraries Australia and Library of Congress, the profiles are different between bibliographic databases and authority databases, and this can be traced back to differences in the functional areas of the Bath profile: 
http://web.archive.org/web/20080218122658/http://www.collectionscanada.gc.ca/bath/tp-bath2-e.htm

For instance, Libraries Australia claims to support "Functional Area D (Authority Record Search & Retrieval) to Level 1" 
http://web.archive.org/web/20080219085710/http://www.collectionscanada.gc.ca/bath/tp-bath2.18-e.htm#a

It doesn't appear to in reality as it doesn't support use attribute 1002 (while the Library of Congress does support this use attribute).

The Library of Congress appears to be more in line with Functional Area D (Authority Record Search & Retrieval) to Level 2: 
http://web.archive.org/web/20080219085716/http://www.collectionscanada.gc.ca/bath/tp-bath2.21-e.htm

It doesn't look like LOC perfectly adheres to Level 2, but I'd say it does up to 99.99%. It also supports a extra attributes belonging to local indexes.

Anyway, here's the problem:

LOC use attributes 1,2, and 3, but LA does not support these attributes. 

On the other hand, LA supports 1003, 1004, 1005, and 1006, but LOC does not.

LOC supports 1002, but LA does not.

We need to be able to define profiles on a server by server basis. In fact, this is even recommended by Libraries Australia: "Step 4. Configure your Bib-1 Search Attributes (if required):".

--

I don't think it would be that difficult to define profiles. We'd have a table with id, profile name, a name/index/description column, and a use attribute column. Then we could add a foreign key to z3950servers to specify the profile. 

We'd need to do a different query for each server target but that would be easy enough on its own.

The difficulty may lie in what to do about the Z39.50 search form. Not all "names" would be supported by all targets. Bug 18096 (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18096) also mentions some local attributes. We don't have a way of specifying those in the search form at the moment, and obviously those local attributes would be local to that particular server. I suppose we could dynamically create the search form... but again not all names will correspond to all servers. I suppose we could just add that caveat. We could also be better with our presentation of results. If we get an error code of unsupported use attribute from a target server, we could surface that to users.
Comment 1 Marcel de Rooy 2017-03-06 09:55:45 UTC
Not for this specific issue, but note that we have defined a field for SRU search mappings in the z3950servers table. If you add a new SRU server, you can open the admin/sru_modmapping.pl form.
This sounds like something similar for Z3950.
Comment 2 David Cook 2022-12-06 06:35:01 UTC
Closing this due to age
Comment 3 Katrin Fischer 2022-12-06 23:33:57 UTC
I'd still very much like to see this. We have issues with half the search options not working. Having the option to map and maybe also hide some of them would be great for usability.