e.g. https://www.wikidata.org/w/index.php?search=haswbstatement%3AP31%3DQ5+haswbstatement%3AP21%3DQ6581097&title=Special:Search currents return no result.
I hope this works too: https://www.wikidata.org/w/index.php?search=haswbstatement%3AP31%3DQ5+-haswbstatement%3AP21%3DQ6581097&title=Special:Search note this is more confusing: it currently returns the same thing as haswbstatement:P31=Q5 and does not work as intended
haswbstatement only works for P31 and string or external-id datatypes. (+ You can use neartitle or nearcoord.)
As I have overlooked it I have changed the title (if it is a duplicate please merge it)
Can you let us know more about what you're wanting to do and any use cases that you're wanting to solve?
In general, I'd recommend to use Wikidata Query Service for queries that only include matches against statement items. It's much better fit for this than CirrusSearch which is primary fulltext search engine.
That said, we do consider extending the list of supported properties. I'll send a mail about it soon.
This may it possible to query by any single property-value pair (which is the original purpose of T54385: Query by one property and one value ("simple queries") (tracking)), and even combination of them. Together with T199886: Support haswbstatement without a value specified it also provides a way to check entities with constraint violation or missing statements.
For these purposes, using Wikidata Query Service may be a better idea, did you try it?
Wikidata Query Service is somewhat complex, especially if you want also to search plain texts (see T141813: Add full-text search support to Query Service).
How difficult there are to add all properties (or at least entity and string based properties, except time, coordinate etc.) to search index?
(at very least P2093 should be indexed, see T179815: Enable searching by author name string)
I see this as less as an alternative to the Wikidata Query Service. SPARQL has to be learned and is slow. This is more similar to ldf. But ldf still lacks a usable user interface. I hope it to fill the gap in the graph here. A fast and easy way to find things based on one to three properties with all the comport that the search provides.
But ldf still lacks a usable user interface.
What's wrong with https://query.wikidata.org/bigdata/ldf ? If you have any suggestions, I'd appreciate to hear them (in a separate task, of course).
LDF though is definitely a structured data access mechanism, not fulltext-search-friendly in any way.
See also discussion under: https://lists.wikimedia.org/pipermail/wikidata//2018-July/012252.html
Change 452956 had a related patch set uploaded (by Smalyshev; owner: Smalyshev):
[operations/mediawiki-config@master] Switch item/property type indexing from opt-in to opt-out
Change 452956 merged by jenkins-bot:
[operations/mediawiki-config@master] Switch entity reference type indexing from opt-in to opt-out
Mentioned in SAL (#wikimedia-operations) [2018-08-21T23:42:07Z] <thcipriani@deploy1001> Synchronized wmf-config: SWAT: [[gerrit:452956|Switch entity reference type indexing from opt-in to opt-out]] T199884 (duration: 00m 57s)
Change 454620 had a related patch set uploaded (by Smalyshev; owner: Smalyshev):
[operations/mediawiki-config@master] Use proper data types for indexing items
Change 454620 merged by jenkins-bot:
[operations/mediawiki-config@master] Use proper data types for indexing items
Mentioned in SAL (#wikimedia-operations) [2018-08-22T23:16:59Z] <thcipriani@deploy1001> Synchronized wmf-config/WikibaseSearchSettings.php: SWAT: [[gerrit:454620|Use proper data types for indexing items]] T199884 (duration: 00m 55s)
Following ML discussion, enabled indexing all entity link properties, except P1433 and P2860. Still needs reindex to fill up old entires.