To recreate: - create itemtypes BK, EBK, and E-BK - catalog one bib in each itemtype, all with the same title - perform a search for that title, see all 3 bibs in your results and all 3 itemtypes in your facets - limit your search to just the BK itemtype - confirm both the BK and E-BK records still show in your results but the EBK record does not Somewhere in the execution of this search, we're failing to properly parse "E-BK" as distinct from "BK."
Confirmed this behavior with both Zebra and ES.
This is just an educated guess, but "E-BK" is probably being normalized as "E BK" and then tokenized into "E" and "BK". I don't know about ES but I'm confident Zebra doesn't have any way to avoid normalization/tokenization for selective indexes. I'd say the solution would be to try to avoid allowing itemtypes that can be normalized/tokenized to be the same, but that won't help with data migrations. I suppose it could be yet another check in about.pl...
Hi Andrew, I think this has been filed several times already and David is right. The - is treated like a space and so BK will also find E-BK because it contains the same word. We always recommend not using - or _ or spaces in itemtype codes and authorised values used in bibliographic or item records for that reason. There is no really a good fix I think. Exact filed search with ,ext could be an option but not sure how that translates to ES and at least some older Zebra versions didn't support ext with ICU (I am not even sure it works now).
> I'd say the solution would be to try to avoid allowing itemtypes that can be > normalized/tokenized to be the same, but that won't help with data > migrations. I suppose it could be yet another check in about.pl... Thanks, David and Katrin. I knew I'd run into this before, but couldn't remember seeing a bug about it. If we know these characters cause problems when used in itemtype codes, then I'd be inclined to somehow not permit their use, but I don't have a solution for keeping that tidy in migration. If we don't block these characters, then some sort of warning text might be helpful, but I'm not sure where we'd put it that users would actually see and respect.
I have to admit I kind of made use of that in the fact to create a "group search" for locations and collections. A warning might be nicer than a hard block and also some documentation on the manual.
I suppose it's rarely a priority for me, as it's something that isn't too difficult to fix up on the backend manually for a sysadmin...
(In reply to Katrin Fischer from comment #5) > I have to admit I kind of made use of that in the fact to create a "group > search" for locations and collections. That's interesting. Could you talk more about that?
I think the use case was something like items in several rooms/areas outside the library. So what you could do is use a common prefix and number then like: loc-1 loc-2 loc-3 etc. then you can find them all searching for location:loc and individually using location:loc 1
We do have a grouping feature for itemtypes - so more useful for locations and collections.