How to match items that share the same taxonomy term and and can therefore be considered similar?
Option 1: More Like This based on the taxonomy term field directly.
* Requirements:
Matching is done by taxonomy term id, so first you need to fix the data type for "long" in schema.xml:
- <dynamicField name="im_*" type="tlong" multiValued="true" termVectors="true" />
+ <dynamicField name="im_*" type="long" multiValued="true" termVectors="true" />
Term ids can be short (one character), so you need to decrease the minimum word length in solrconfig.xml:
- <str name="mlt.minwl">3</str>
+ <str name="mlt.minwl">1</str>
* Advantages: Native integration of term ids.
* Disadvantages: Decreasing the minimum word length can affect other fulltext fields that you use for similarity. Short words like "a", "an" etc. will be matched.
Option 2: More Like This based on a related field (name of the taxonomy term).
* Requirements: probably you will need to increase the maximum word length in your solrconfig.xml, if you have term names longer than 15 characters. See #1181260: Increase mlt.maxwl in solrconfig.xml.
* Advantages: You don't need to decrease the minimum word length. You can index the term name as fulltext field and match also parts of term names (e.g. items with the terms "software development" and "software engineering" will be considered similar).
* Disadvantages: If a term name is changed, items with that term need to be re-indexed. Search API does not do that automatically for you. So you either need to do that manually or you can implement a taxonomy term update hook where you schedule the affected items for re-indexing.
So both options are somewhat ugly. Any input on this?
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 1203680-sapi-solr-tlong-tids.patch | 777 bytes | klausi |
Comments
Comment #1
Shadlington commentedIt seems to me that if all you're matching MLT on is taxonomy terms, then option one is best as there will be problem with short words.
This is what I would personally use, as that's all I want to match on.
I think a generic best-compromise is going to be tricky to reach.
I wish there was some way we could find out how most people would want to use it.
Comment #2
drunken monkeyNote that this is unnecessary, as the service class automatically overrides this setting for all non-fulltext fields.
So if we set the type to "long", this works fine? Then we should maybe either think about changing the type completely, or adding another field with the fitting type especially for MLT use, as done for string facets.
Comment #3
klausiGreat, this works for me. So this eliminates the disadvantage of option 1 and I can actually use it. Now we need to fix this "long" datatype, I changed it in schema.xml for now. I leave it up to you where you exactly want to fix this.
Thanks!
Comment #4
drunken monkeyAs it seems
tlongonly speeds up range queries, which probably are much more uncommon than normal filtering, I guess we can just replace the data type there, instead of adding unnecessary complexity.So, I just committed your patch, thanks!