[Koha-bugs] [Bug 11297] Add support for custom PQF attributes for Z39.50 server searches.

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Tue Feb 18 01:42:17 CET 2014


http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11297

--- Comment #5 from David Cook <dcook at prosentient.com.au> ---
(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.


More information about the Koha-bugs mailing list