(Issue #AV-IS-0209-912) Filtering API needs proper extensible schema

The filtering schema needs a properly defined schema that is extensible and future proof + has no hard coding for a specific site / product types.

On 29 November 2021, Abhishek Rajpoot had mentioned on Telegram:

The plan for implementing product categories is as follow -

1) API to create product categories at the network/platform level.

2) API to query all the categories created at the network/platform level.

3) API to create/update category hierarchies. Such as Electronics -> Televisions -> Curved Television

4) API to assign categories to the products

And then ->

5) The products can be queried for each of the categories.

To which I'd replied:

You need to run this by Barry - he has lots of thoughts on how the filtering should work. I had a longish discussion with him in Oct on the entire filtering thing and he didnt agree to any of my suggestions eg one of the things I'd mentioned is "instead of tags maybe use categories (every product in ST has a category field), so this is 1 level of filtering and will serve well with no complexity until you hit say 5K distinct products."

His reply: Tags are the standard tool for using these. We use tags, as do the other marketplaces, ecommerce sites, etc... we used categories for business because shoptype did not have the structure for tags associated to business, which is a shoptype shortcoming.

All of our vendors use tags. We work with them to incorporate our tags. Some do, some will do, which is why products don't always show up when searching tag. Just because they aren't today, doesn't mean that we should be shortsighted and do that too. We are working based upon industry design principles.

"the industry standard is faceted search, which is what our filter tag menu is"

So essentially lots of filtering facets are needed, which should be extensible, and therefore I suppose a single category field will not suffice.