Page MenuHomePhabricator

Support haswbstatement in other properties
Closed, ResolvedPublic


e.g. currents return no result.

I hope this works too: note this is more confusing: it currently returns the same thing as haswbstatement:P31=Q5 and does not work as intended

Event Timeline

matej_suchanek changed the task status from Open to Stalled.Jul 18 2018, 9:40 AM
matej_suchanek added a subscriber: matej_suchanek.

haswbstatement only works for P31 and string or external-id datatypes. (+ You can use neartitle or nearcoord.)

Bugreporter renamed this task from Support multiple haswbstatement in one query to Support haswbstatement in other properties.EditedJul 18 2018, 9:43 AM

As I have overlooked it I have changed the title (if it is a duplicate please merge it) works well

Bugreporter changed the task status from Stalled to Open.Jul 18 2018, 9:45 AM

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.

Smalyshev triaged this task as Medium priority.Aug 2 2018, 10:32 PM

But ldf still lacks a usable user interface.

What's wrong with ? 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.

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.

debt claimed this task.

The reindex work has been added to T147505