Last modified: 2012-11-20 18:42:04 UTC
* version of SMW 1.5g-SVN (reason: like to use inverse-feature) * version of MediaWiki 1.14.0 * server setup php 5.2.4-2ubuntu5.7 , MySQL 5.0.51a-3ubuntu5.4, OS ubuntu??, I use redirects to have a solution for word synonyms; the property has data type "page". SMW don't support full functionality handling with wildcards and redirects. (although I tried the Setting $smwgQEqualitySupport=SMW_EQ_FULL) Example: Original page was "Zungenvergrößerung", this page was redirected to "Makroglossie" which is a synonym. {{#ask:[[Symptom::~*Makroglossie*]]}} -> I get the expected result {{#ask:[[Symptom::~*Makro*]]}} -> I get the expected result {{#ask:[[Symptom::~*Zungenvergrößerung*]]}} -> I don't get a result {{#ask:[[Symptom::~*Zunge*]]}} -> I don't get a result without wildcards ->{{#ask:[[Symptom::Zungenvergrößerung]]}} ->I get a result
Yes, I think that wildcard searches on redirect titles are indeed not supported at the moment. A workaround would be to use Type:String properties to specify aliases on a page, and to do wildcard searches with them. I accept this as a feature request for now, but this will require some changes to the SMW query processor and the way in which redirects are treated there.
Thank you
Revisiting this request, I have to say that this is very hard to handle in the current implementation. All query answering is fundamentally based on the notion that each (potential) result has only one title string. This is correct for sorting and exact matching. To allow queries to even consider other alternative titles, one would need to JOIN this information into all queries. This is a major performance threat (we had a similar system of joining in all redirects in early versions of SMW). It is also not clear if this behaviour corresponds to the meaning of redirects, which by definition *refer to* something else. In your example, the information stored by SMW is [[Symptom::Makroglossie]] and nothing else. What you are asking for is that SMW retracts incoming redirects, i.e., evaluates redirects *backwards* to find that this *could* be stated by typing [[Symptom::Zungenvergrößerung]], and takes all of the potential spellings thus obtained into account for pattern matching. This would be a new interpretation of redirects. Currently the pattern search performs string matching over the data that is really stored, and this data does not involve anything that would match [[Symptom::~*Zunge*]]. I leave it open whether we should address this at some point (should we then also do this for sorting comparators? what about {{#ask:[[Symptom::>Z]]}}?). If this ever gets implemented, it should be configurable and probably switched off by default. I think my suggestion of storing synonyms in another way, e.g., using a string property "Synonym", is still a valid workaround.
