Filtering: Hierarchical menus unsuitable for non-hierarchical tags

[matt-wallis]

The following comment was originally made by @matt-wallis in issue #23:

I have a question about the conversion of the flat taxonomy into a tree structure for menus. Apologies if this has already been sorted out - I have not been following this carefully.
The question: Will the tree structure provide different ways to navigate to the same thing. For example, could there be {Food, Fair Trade} and also {Fair Trade, Food}?

The reply from @species was:

@matt-wallis The data structure of the "flat" export would permit this type of relations, but we're not using it right now.
As we're pressed for time at the moment, I'll write the 'conversion library' with support for memberships in a single category only. But everything will be open source, so anyone can improve it later :-)

The reason for asking this question is that the tags (e.g. "Food", "Fair Trade") assigned to an item on the map do not themselves have a natural ordering (containment relationship). Is "Food" a subcategory of "Fair trade", or is "Fair trade" a subcategory of "Food"? Different users can have different answers to this question. In general, the answer is "neither". If we impose an ordering by using a hierarchical menu system, then we have invented a new thing (the ordering) that the user has to understand in order to use the system, and we may not provide the filtering that the user wants.

Alternative UI elements that do not impose ordering should be considered. e.g. checkboxes.

[gandhiano]

I find it very problematic that time pressures make us put resources into developments that are not reusable. A few months ago, in Berlin, we were precisely addressing this structuring problem and have spoken about not using an hierarchical, but flat structure, with simple and flexible API endpoints for the filters/queries.

Lets please focus on building a flat/agnostic structure that was collectively planned, in order to make it reusable in broader contexts. And explain the project partners why some deliverables need to wait for others to get ready, negotiate, esp. @josefkreitmayer, cc @almereyda @species - looking at how much unnecessary complexity and rigid structures we are adding by looking at #23 makes me feel that we are not going the right way.

[josefkreitmayer]

Ah, I think, there is a conceptual misunderstanding.

The structure we are building is actually agnostic. Categories and Subcategories, that any partner wants to build from the stack can be refurbished with any types of initiatives. We devided the data accordingly. Filtersets in Wikibase. Types_of_initiatives with the Geo-Data.

• Filtersets (Relations of Categories, Subcategories and Types of Initiatives) can be built in Wikibase.
• The Filter Menu-Structure built by @keikreutler in relation to a script by @species , that interpretes the JSON output of the respective filterset comming from Wikibase, will be re-usable with other filtersets.

The case we currently do not want to put attention to, is that one Type_of_Initiative is represented in several Categories or Sub-Categories in the same interface. That might be worth a short cosideration, as @species mentioned: "Which of the relating categories will be shown opened, if someone forwards the permalink?". That is the only issue, that is not yet resolved, but as well not as crucial I suppose, as what I interprete, that your - well understandable - concern is.

@matt-wallis does that address and clarify the concern?
Maybe I get it wrong again, but happy to elaborate.
Might need more time for further reply, as I will be off the computer for the rest of the day.

best
Josef

[matt-wallis]

@matt-wallis does that address and clarify the concern?

I don't know @josefkreitmayer, because you have expressed things in terms of the current implementation and I do not have the time to get to grips with this level of detail.

I asked the question in issue #23 because alarm bells were ringing in my head when tree structures were mentioned to model data which may be less structured than this. Perhaps I have misunderstood. If @gandhiano 's comment:

we were precisely addressing this structuring problem and have spoken about not using an hierarchical, but flat structure

has been addressed in this implementation, then I have misunderstood. But the terms "categories" and "sub-categories" leave me in doubt.

The following use-case provides one example, independent of any implementation details:

A user wants to see all the Fair Trade outlets in their city. This may include outlets selling fair trade food, and other outlets selling fair trade clothing. The user then wants to refine her view so that she sees just the Fair Trade clothing outlets, or just the fair trade food outlets, or just the fair trade outlets that are run as co-ops, or just the fair trade clothing outlets that are run as a co-op.

In this example, "Fair trade", "Food", "Clothing" and "Co-op" are not in a natural hierarchy, they are just labels that can be associated with an outlet.

[species]

In this example, "Fair trade", "Food", "Clothing" and "Co-op" are not in a natural hierarchy, they are just labels that can be associated with an outlet.

You are right.
I also like this tag-based classification scheme a lot more than tree-based. May it be because OpenStreetMap is also using an attribute-based tagging scheme? As a side note, in OSM the different tags usually gets sorted into hierarchical structures by the editor-software, because humans are used to that. But every editor implements this structure independently, because it's a pure client-thing. In fact most people use the search-function when tagging objects, because the hierarchical structures are that complex ;-)

---

@josefkreitmayer: @keikreutler will try to work with the 'flat' structure as exported by wikibase (taxonomy.json) from now on, because its format doesn't impose any hierarchical structure. We will meet again in Mumble on Friday, June 10th, 16:00 CEST.

[species]

ping @keikreutler ?

[josefkreitmayer]

implementation and documentation moved here: https://github.com/TransforMap/transformap-viewer