When the UK started using OFN we decided to keep the category structure that our food hubs in the UK were currently using and diverge from the Australian categories. As our structure becomes increasingly divergent and we work with more data I’m thinking this was the wrong strategy.
It seems to me that prioritising the interoperability between OFN instances will be a huge strength down the line.
To begin this conversation, I’m interested to know which instances, if any, have implemented a taxonomy structure different to Aus. And if so what this is? @MyriamBoure@enricostn@CynthiaReynolds@tschumilas@harsha@eric@anyone else
Also interested to hear how people find the Aus taxonomy, currently:
Bakery
Boxes
Bulk Buy
Dairy
Drinks
Fruit
Herbs and Spices
Household
Meat + Fish
Nuts + Dried Fruits
Oils + Spreads
Pickles + Preserves
Poultry + Eggs
Prepared meals
Pulses + Grains
Specials
Vegetables
From the UK perspective we also have:
Alcoholic Drinks (Important to separate from drinks in our opinion)
Tea + Coffee
Health + Beauty (important for many producers to value add)
Flowers, Plants + Garden (important for many of our producers)
Tasty Treats (which isn’t working really)
We’ve also been asked for a Craft category.
Plus some of the Aus categories have been split in two or merged eg:
Fruit + Veg
Meat
Fish
Oils + Vinegars
Preserves, sauces + spreads.
Then there are the difficult to place items, like Tofu? Meat/dairy alternatives? Chocolate bars? Snacks? Baked Beans?
@lin_d_hop I set up a document on the global drive so we can compare taxonomies here.
I used the terms that we have on our instance but added english translation as comments in each field.
The first ones on our list that stand out that I am not seeing elsewhere are:
DIY (as opposed to Craft)
Courses
Membership (which works well for CSAs etc…)
Garden will be an excellent addition to our list
will look into the other points you bring up and add more info when I get a chance
I added Canada’s taxonomies. We’ve had lots of dicussion on these. I think its the first way a new hub connects with OFN - I guess its a logic thing - they think first about their products. So eventhough we don’t have much trading going on here, we have lots of discussion about taxons.
A few differences from the Aus original - culturally we sell eggs and dairy together (in stores, and everywhere). Versus eggs and poultry. Its totally illogical - but its the way our food guides… have always been structured. Poultry is assumed in meat and fish (where we have lots of sub-categories like lamb, chicken, pork…). We also pulled out ‘sweeteners’ for honey and syrup into its own category (big items in food hubs here.) . And we pulled flours out into its own - lots of artisan flour happening here.
ONe of our experimenting hubs carries lots of prepared foods. She pleaded for more categories and I caved. We changed the Aus ‘prepared meals’ to ‘prepared foods’ so it is more general, but added: snack foods (esp popcorn in Canada), vegan substitutes and dry goods (that aren’t pulses, or flours or oils - so things like noodles and rice )
I think we would use (but aren’t yet): specials, alcholic drinks (esp craft beer which is big here), Good suggestion on adding ‘garden’ to flowers and plants, we could do that. I also like the diy or craft category. Love the membership and courses/workshop categories - don’t know why I didn’t think of this as a temporary csa solution until we have that more developed.
I think there will always be some differences in taxons - things that are culturally specific. Imagine once asian and african countries come along (or even when our first food hub specializing in international foods joins here, we have a few of those). So I’m not convinced we’ll be able to standardize completely - must be some way to move to interoperability by having the taxons in a given instance roll up into much broader ‘meta categories’ that are standardized - does that make sense?
Interesting question @lin_d_hop, we have worked a lot and are currently still working on it on the interoperability project Data Food Consortium. Because the interoperability issue is not only between OFN instances but also between OFN and other platforms, as lots of producers do sell to hubs using different systems (OFN, The Food Assembly, and others).
So the learnings from the consortium are:
1- There is no way one taxonomy will fit every need, and lots of food hubs want to keep with their existing taxonomy, or be able to choose their own (especially when we start talking about standalone website plugged on OFN instances. I have a concrete example with the french potential big user that we are still discussing with :-)).
2- We already had various requests also to be able to have sub-categories, which today is not possible in the OFN as all categories appear on the same level in the list.
3- In order to make various platforms interoperable we need to find some form of “pivot table” so that we can “match” in which category a product from platform A will be sorted in platform B. We discussed a lot about what should be that pivot table, and we came to the conclusion that it shouldnt be a table but a “facets approach”, meaning that to describe a product there are various facets and each combination of facets make a unique product identifier (of course you can then have a flat list of all the combination, but you can choose what are the entry point…). So every platform/hub can decide how they sort the products (in which of their own category) given the facets they want. Some might have a dedicated category for organic products, some might have two categories for vegetables (root vegetables and leaf vegetable), or some just one “fruits and vegetable” category.
I don’t think we should try to have a single taxonomy, for me we should aim at making it possible for every hub to define their own category, and just build that pivot format to interoperate them.
To answer on the French ontology, we had to go more into details and fully customized the taxonomy for our own need and what was more logical / asked by the local users. We have an ongoing discussion on the French forum so that if there is an issue with a user he can ask a modification, but any modification in the taxonomy is really a mess as it impacts all the existing products. So that’s why I think every hub should have its own taxonomy and we should just a well though pivot taxonomy that enable the information to flow in any direction I’ll share our taxonomy on the file later today, but wanted to share about the interoperability reflexion as you open the topic Lynne, if you are interested there is a dedicated channel on Slack
Thanks Myriam.
I agree that one taxonomy cant be exhaustive, and fully understand the interoperability approaches and conversations from that perspective.
However, I also see that if OFN internally remains split with multiple taxonomies it is going to make development of specific features much more difficult and expensive. The kind of features that we might like to explore could be:
Offering products for trade across instances eg bananas, coffee.
Automatic box builders for food hubs that want to offer a veg box with the veg available that week from their producers.
Automatic suggestion of replacement for unavailable items from a standing order.
Combining produce from different suppliers to be able to fill larger procurement contracts.
All of these features could use taxonomy in a sophisticated way.
The key difference with OFN internal compared to the interoperability project, is that internally we need to be able to minimise the cost of new developments. If we don’t, others certainly will. Cost of development is a key thing that impacts our ability to have a “place at the interoperability table”.
There will always be a trade off between flexibility and cost of development. I think it would be dangerous to prioritise flexibility in every case. So I do think it is important to at least consider if this is a necessary complexity or not.
I can see how this is a complex issue. @MyriamBoure’s approach is interesting and would presumable allow each shop to choose its own categories, with the software doing the allocation and putting anything unallocated into an “other” category.
The only simple solution I can think of is not to use taxons at all.
Ok, ok, it’s radical but let us seriously consider if taxons are the future in an interconnected world.
If we do want them, then something like Myriam’s approach seems unavoidable. It would also come into the product import function, where the uploading of 1000s of items with their own category structure would need a way of converting to OFN categories.
I wondered the same thing - but thought maybe I was being naive or missing something. But - is it possible that instead of taxons searches for products, and linkages to products across hubs, can happen just with key word searches? So I search for ‘organic’ and all the hubs (in my instance and/or across linked instances) come up that have organic products. I search for ‘organic’ + ‘asparagus’ - and all the hubs with organic asparagus come up. If I want to include hubs that use languages other than English, maybe there is a utility that asks if I wanted my search terms translated to search in those hubs too. (Seems like a dream)
‘Asparagus’ is a taxon. (edit: or rather a product )
I see the future taxonomy the way Myriam describes it, and as an ever-evolving database, interconnected through APIs. Importing product lists would be no issue as the taxons not already in the database are added to it and synchronized over time with other platforms through the APIs.Then we could have extra features suggesting standard (more used) taxons to those deviating, so the db doesn’t diverge exponentially
Cool, ok, based on the feedback from the community this is not something that is wanted.
I also like the sound of @MyriamBoures approach, but am getting increasingly nervous that we are creating something in OFN that is so complex it will become obsolete. But I guess we cross that bridge when we come to it eh?
I added what I’m proposing for the USA taxons based on what other folks are doing - there are 29 of them. Too many? I think it will work well for us and maps pretty closely to other instances. Here’s the list:
Baked Goods
Boxes & Shares
Fruit
Vegetables
Dairy, Cheese, Yogurts
Eggs
Meat, Fish, and Poultry
Vegan Protein (or maybe it should be “plant based protein” - talking about tofu, tempeh, seitan, etc)
Nuts & Dried Fruit
Herbs and Spices
Oils & Condiments
Beverages
Tea and Coffee
Canned Goods, Preserves, Pickles & Sauces
Fermented Items
Household Items
Flours, Grains, and Beans
Rice and Pasta
Sweeteners
Snacks
Prepared Meals
Other Foods
Flowers
Plants & Seeds
Bath & Body
Crafts
Books & Courses
Pet Food
Other Non Foods
@yuko asked me the other day about how many we needed to support and I guessed about 20. Now that I look at this I see that on other instances, particularly USA it looks like creeping up to more like 30 . . is the design proposal that we’re looking at actually going to handle that? Seems like it could be a lot of filter scrolling to handle - especially on mobile?
I am not sure how much of the solution to this is UX/presentation and how much is a deeper question of categorisation and if/when we should support nested categories or more user-defined tags. I would like to be able to make a decision on ux / mobile quick-win without having to open all that up but not sure if we can . .
Just re. this @lin_d_hop (and I realise I’m a year late to the discussion) - couldn’t we build features that just require the instance to map which taxons they want those features to use? It seems like most examples above - except the top one - are most likely intra-instance features?
I"ve commented on the design proposal above, but just to also put this here… Right now a super-admin is able to set up categories as well as sub-categories. BUT the sub-categories do not function properly. They just function as more top level categories. (So, unwittingly, I ended up setting up TONS of same-level categories and its a mess.) But limiting to 20 top level categories is not a solution either. The reality is there are too many products within one category (like: vegetables) and filtering becomes useless anyway. It still results in pages and pages of scrolling. So - we can limit the number of filtering categories and sentence the user to death by scrolling, or we can proliferate dozens of categories/filters and make the shopfront look ridiculous. I’m wondering what we know about why the sub-categories in the platform now are not functioning correctly. If we fixed that - wouldn’t it be better? Does anyone know if we’ve sorted this out?
Hmm, if the display of the subcategories doesn’t function now but might in the future, I am feeling like going with these 17 categories with subs, which for now makes for a potentially long list, but in future might be a less chaotic display. Questions:
If there are no products in a category, then the category isn’t displayed to a shopper - correct?
How do you put a product in two categories?
Proposed shorter category list:
Baked Goods
Boxes & Shares
Produce (subs fruit and vegetables)
Dairy, Cheese, Eggs
Meat, Fish, and Poultry (with sub for each plus plant based protein)
Nuts & Dried Fruit
Herbs and Spices
Oils & Condiments (subs for Preserves, Pickles, Spreads, Sauces)
Beverages (subs for tea, coffee)
Ferments
Flours, Grains, Beans, Rice, Pasta
Sweeteners
Snacks
Prepared Meals
Other Foods
Flowers, plants, and seeds
Nonfoods (subs for household, bath & Body, crafts, books and courses, pet food, other)
@lauriewayne1 you can’t put a product in two categories. You have to choose.
@tschumilas making sub category work might be something needed, but let’s try top capture the need first
From my understanding, there are three needs:
The customer needs to be able to easily find products and buy whatever type of product they search, without getting lost in a long list of products.
-** The hub manager needs to be able to properly organize the products of his shop to make it easier for her customers to find the products they search for**. The categories and maybe sub-category needed vary from hub to hub.
Ex 1: an online shop selling only meat items. They don’t care putting all their products in a big “meat” category, that means offering no filtering option. They want their categories to be “beef, veal, poultry, pork, etc.”
Ex 2: a buying group sells around 50 products, but a large diversity, like 3 soaps, 10 vegetables, 5 fruits, 3 meat, etc. For them they absoluterly don’t want specific categories, they don’t want to associate the type of meat with a specific sub-category.
The general visitor of the platform have the need to be able to search products over the all OFN shops, so there is a need for some “pivot category table” enable interoperability of hub taxonomies If I search “meat - veal” if the buying group has only veal, they need to have associated somehow to “veal” so that I can see the item in my general search.
etc.
That’s what we learn in DFC: as far as taxonomy are concerned, we need to map at the most precise level to be able to interoperate.
So there are two different type of answers for me:
1- Every product SHOULD be associated toa pivot category with menus and sub menu (or we could have a facets approach, but might be a bit complicated at that stage… so let’s forget about it for now)
2- Then every hub should be able to build their own custom categories and map it to our standard pivot taxonomy. Like the buying group selling veal will setup veal as “veal” in pivot category (main platform category). But if they build their own taxonomy, they can decide as well to associate it to “meat” in there taxonomy, and when build their taxonomy tells that “veal” in pivot taxonomy is included in “meat” in custom taxonomy.
There might be some easier way to envision custom category with tagging. Maybe adding a tag to a product, and then having some possibility to display in which order we want the tag to display in the shop to enable product filtering. And when creating a tag it can be associated to a product category in the pivot taxonomy.
You are correct that the categories that cover off the products in the shop are the ones that show in the shop. (So if I have no products categorized as ‘baked goods’ , then ‘baked goods’ will not show.
When you create a new product, I THINK, you can only classify it under one category. (And you MUST in fact classify it.) (Anyone know different - can you classify it in 2 categories at creation? Will be be able to with product upload feature?)
So unfortuantely, its 3 screens to add a second category to a product. So thats why no one does it. Start on the bulk products mgmt screen, edit the product you want to modify and that takes you to a spree detailed screen. From there you select to see further description details on the product - and you can add categories on that third screen. See below:
