Last modified: 2012-10-29 17:23:54 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 12387 - Suggestion to allow more complex filters
Suggestion to allow more complex filters
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
SemanticDrilldown (Other open bugs)
All All
: Normal enhancement (vote)
: ---
Assigned To: Yaron Koren
Depends on:
  Show dependency treegraph
Reported: 2007-12-23 06:01 UTC by Ike Hecht
Modified: 2012-10-29 17:23 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Ike Hecht 2007-12-23 06:01:43 UTC
I thought it would be nice to be able to do more with filters than just cover attributes. My idea was to have filters be able to run queries. Any query language will do but I think the simplest, most consistent implementation would be to use Semantic's <ask> queries - although they are very limited. The filter's definition would say: show all pages that meet this query's criteria for value X. Those values could either come from a category or possibly a list. On the simplest level, it would enable using ANDs and ORs for filtering. Perhaps it can be implemented in a way that would allow for nested queries too.
Comment 1 Yaron Koren 2007-12-26 22:13:11 UTC
It sounds like what you're basically asking for is the ability to do ORs, and not just ANDs - is that right?
Comment 2 Yaron Koren 2007-12-27 04:27:15 UTC
Oh, I see - you also want to be able to filter on secondary values - properties of properties. Okay, now I get it. Well, the hardest part of this might be coming up with an interface to support such greater complexity without leading to a lot more confusion. If you can come up with something, let me know.
Comment 3 Ike Hecht 2007-12-27 04:40:33 UTC
I was thinking broader than that. One of the strengths of Semantic is the ability to put together information based on attributes that may come from different pages. I've realized what I'm suggesting is fairly complicated so I've included a lengthy example. Here's an example from Semantic's documentation. I'll try to explain how it could potentially be implemented with filters: 

Assume that we are interested in all cities of the European Union. This is done by the following query:
[[located in::<q>[[Category:Country]] [[member of::European Union]]</q>]]

Using this example, a semantic wiki can have a page for London, and that page may say nothing about it being in the European Union, just that it's [[located in::England]]. There's a separate page called England which mentions it's a [[member of::European Union]]. 

If I wanted to drilldown on category cities, I currently wouldn't be able to filter based on whether it's in the European Union or the African Union because that information is not contained in the pages of Category:Cities. (Or at least I haven't been able to figure it out.) I think that would be a very useful feature, taking full advantage of the semantic concept.

A filter's page could look something like this: (I've simplified the above query somewhat.)

Filter:Supranational union
This filter covers the query [[Covers query::[[located in::<q>[[member of:: [[Has value:=European Union]], [[Has value:=African Union]], [[Has value:=Central Asian Union]] ]]</q>]]]].

I realize this looks very complicated but it would be easy to generate this with Special:Create filter.

The View Data page would then look like:


Supranational union: European Union (8) · African Union (34) · Central Asian Union (33)

Of course there are an infinite number of ways the filter page could look that are probably much better than my pitiful example, but it's my best attempt at describing what I have in mind. Once this query type system is implemented, there would be no need to make specific AND and OR filters, or filters similar to the new "date ranges" filter. They could all be implemented by queries. Of course, the most common filters may require their own tags for simplicity, but this would greatly extend the drilldown potential. Hope it makes sense!
Comment 4 Ike Hecht 2007-12-27 04:43:27 UTC
Oops. We were both posting at the same time. It seems you got the idea before I posted the example. Is the above suggestion simple enough and consistent with the existing code? I'll see what else I can come up with. 
Comment 5 Yaron Koren 2007-12-27 04:58:55 UTC
I suppose a nested query (i.e., a property of a property) wouldn't be that confusing to users in "view data" (though letting "create filter" support it might be tricky). But what would OR queries look like in the drilldown?
Comment 6 Ike Hecht 2007-12-27 19:39:11 UTC
I've thought about this some more from the standpoint of fitting in to the existing system and I've come up with a totally different approach. Maybe best way is to actually HAVE filters on filters. That is, have one filter get its values from another filter. Again using the overly long and complicated example:

Filter:Supranational union
Property that this filter covers: Member of union
Get values for filter from this category: Countries

Filter:Cities in supranational union
Property that this filter covers: located in country
Get values for filter from this FILTER: Supranational union
Label for this filter: Supranational union

By selecting European Union, the extension would send that input to Filter:Supranational union which would generate an output of England, France, etc. Those values would be used as input into Filter:Cities in supranational union which would output London, Birmingham, Paris, Marseille, etc. The final result would be a list of cities in the union the user selected.

I've been thinking about how ORs would work and realized I was probably overreaching with my queries idea. Especially with the new suggestion, it would require a different solution. I've got some ideas which should probably get a feature report of its own.
Comment 7 Yaron Koren 2007-12-27 20:34:52 UTC
I like that idea of filters using filters - it eliminates the need for a complex query language, which makes things easier for both users and developers. Let's say that that's how nested queries will be implemented, whenever that happens.
Comment 8 Siebrand Mazeland 2008-08-11 09:12:53 UTC
Assigned to extension developer.

Note You need to log in before you can comment on or make changes to this bug.