Page MenuHomePhabricator

Suggestion to allow more complex filters
Open, MediumPublicFeature

Description

Author: ikehecht

Description:
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.


Version: unspecified
Severity: enhancement

Details

Reference
bz12387

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:59 PM
bzimport set Reference to bz12387.

It sounds like what you're basically asking for is the ability to do ORs, and not just ANDs - is that right?

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.

ikehecht wrote:

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:
[[Category:Cities]]
[[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:

Cities

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!

ikehecht wrote:

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.

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?

ikehecht wrote:

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.

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.

Assigned to extension developer.

@Yaron_Koren, this is one of the oldest tasks assigned to someone. Are you planning to work on it, and is its current priority correct?

@Qgil - sorry, I missed your question until now. I have no immediate plans to work on this task. I also don't know how to judge the priority - I don't consider it that important, but other people might.

Ok, then it is better to leave it unassigned.

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 12:24 PM