http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11297
--- Comment #5 from David Cook <[email protected]> --- (In reply to Frédérick Capovilla from comment #4) > Unfortunately, I cannot provide a use-case you could reproduce because we > encountered our search problems on a private server requiring a subscription > with a username and a password. > Sorry for the confusion, Frédérick. I didn't mean a test case. Rather, do you have any other examples (than your current case) where a person might want to provide arbitrary attributes at the server level? > In our case, the BANQ server would not return results if we did not specify > a value for "@attr 4". > With this patch, we can set default PQF attributes for a all searches on > this Z39.50 server without affecting search results on other Z39.50 servers. > This is useful if we want to do a single Z39.50 search on multiple servers > at the same time, each with their own supported or required attributes. > > For example, specifying "@attr 4=1" on server 1 will not cause an error on > server 2 if this one doesn't support "@attr 4" attributes. That's fair enough. I've noticed that a lot of Z39.50 servers have very different levels of implementation of Bib-1 attributes. It would be unfortunate to find the solution for one server causing an error on another. > > -- > > Finally, what you are describing affects "Use" (@attr1) attributes. The main > use of this patch is to set the other attributes which won't change > depending of the used search terms. > > However, the same methods could be used to implement a "mapping table". This > patch changes the PQF query generation technique to use an Array instead of > a String, so each part of the query can easily be overwritten to fit each > server's requirements. Yes, I know that I was describing "Use" attributes. I'm fairly familiar with Bib-1 attributes. I was referring to configuring the "Use" attributes at the server level (since different servers sometimes use different "Use" attributes for the same access point), as you were mentioning setting "Structure" attributes at the server level. In theory, you would map attributes to access points. In this case, maybe one would map @attr 1=4 @attr 4=1 to "Title" so that the default Z39.50 "Title" search would be a "Title Phrase" search. You could also do something like @attr 1=1016 @attr 4=6 to do a "Keyword" search. Since the mappings would be at the server level, you wouldn't have to worry about servers that couldn't support "Structure" attributes. I disagree that the "@attr 4" "Structure" attributes won't change depending on the search terms. As I mention in the above paragraph, you might want to use @attr 4=1 (phrase) for a phrase search, but you might want to use @attr 4=4 (4 digit year) for a year search. Or maybe @attr 4=6 (word list) where you you're performing a more "Google-like" search. That said, Bib-1 attributes are quite esoteric. Most staff users probably wouldn't know that they could even provide them. Of course, it's probably more likely to have Koha admin than a staff members setting up Z39.50 servers, so it might not matter. After looking at the patch, it looks like it would work for your use case, but it seems like a bit of a hack to me. I also wonder how many people will use it incorrectly. Maybe it does make sense to make all queries for a server use one structure attribute like 6 (word list), but I think it makes more sense to use a drop-down menu than a free text field. That said, the free text field is more flexible (albeit more error prone). I don't mean to sound harsh or overly critical. I'm just trying to add another perspective. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
