[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 17:04:07 CET 2014


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

--- Comment #6 from Frédérick Capovilla <fcapovilla at live.ca> ---
> 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 understood what you were saying in your first reply, and it would be a great
to add this feature in Koha.

I was just explaining that the attached patch should not be used to set "Use"
attributes in its current state, because it would force a single "Use" value
for all searches.

> 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.

Normally, Z39.50 servers should have a default "Structure" value that is
automatically used if the "Structure" attribute is not provided in the search
query. In our case, the BANQ server does not provide a default value and
requires us to always provide this attribute. The new preference added by this
patch is there to force a default value for this server so it actually returns
results. It could be used on other servers with special attribute requirements.

> 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). 

Since the preference is kind of a "power user" feature with rare use cases, I
didn't think it was worth the effort to create a special field structure for
this one feature. And, like you said, the free text field allows more
flexibility.

> I don't mean to sound harsh or overly critical. I'm just trying to add
> another perspective.

I'm happy to receive constructive criticism like yours.

In the end, I agree that you idea of using some sort of "mapping table" would
be the ideal solution for many Z39.50 search problems including ours. In our
case, with that kind of feature, we could simply add "@attr 4=1" to all search
terms in the mapping table for the BANQ server and it would fix our problem.

For now, this patch fixes a problem we are experiencing with one of the Z39.50
servers we use.
It also improves the PQF query generation code of Z39.50 searches so query
attributes can be overwritten on a per-server basis. This patch could be
improved to permit more advanced per-server query manipulations.

-- 
You are receiving this mail because:
You are watching all bug changes.


More information about the Koha-bugs mailing list