Difference between revisions of "Labels hierarchy"

From Open Food Facts wiki
Jump to navigation Jump to search
Line 64: Line 64:
 
== Implementation ==
 
== Implementation ==
 
Do we need a hierarchy or can some aspects be handled by properties? When to decide for one, and when to decide for the other?
 
Do we need a hierarchy or can some aspects be handled by properties? When to decide for one, and when to decide for the other?
 +
 +
 +
Possible implementations:
 +
 +
* Using taxonomy parents to add "structuring" parent entries
 +
** stephane: We use taxonomies a lot for analysis / parsing. It's important that we differentiate "actual" entries from "structuring" entries. e.g. if there's some regexp that looks for [a label] [an ingredient] --> we don't want parents that are not in fact labels to be recognized. One way around it could be to have a property to indicate that an entry is just "structuring", and that it should not be used for analysis, as a suggestion in autocomplete etc.
 +
* Using properties to indicate entries belong to specific categories
 +
** aleene: Proposal: lets remove all parent entries from the taxonomy and only keep the actual labels we want to detect. Each label has a property that specify the category. This category is listed in another taxonomy (label categories), where all the relations between categories are listed.
 +
 +
 +
To be considered:
 +
 +
* It would be good to implement a solution that could work for other taxonomies than labels
  
  
 
[[Category:Taxonomies]]
 
[[Category:Taxonomies]]
 
[[Category:Labels taxonomy]]
 
[[Category:Labels taxonomy]]

Revision as of 10:02, 13 October 2022

Introduction

The current Labels taxonomy does not have much structure. Only some specific labels have been structured. This document outlines a proposal to add structure to the entire taxonomy. All labels should be able to fall under this hierarchy. (We can dream).

Use cases

Why do this in the first place? What could we do with it?

  • Being able to display if a label is backed by a certification (useful also for the green-washing project, but not only)
  • Being able, on display, to group labels by type (health / social / ecology) - (although a label like organic, might be classified in health + ecology ?)
  • Being able to list all products that have a label from a specific labels category, like health claims
  • Being able to navigate up and down labels (like we do for categories)
    • see all labels with a specific parent
    • see parent labels

Main level

The labels can be split into two groups:

  • Product: every label that describes some aspect of the consumable part.
  • Packaging: in braille. (anything that is not related to the shape, material or recycling of the packaging)
  • Supply Chain, describing each process from creating to having it at the consumer (Life Cycle). There is a relation with the process implementor (farmer, producer, packager, transporter, distributor). A label might cover multiple processes.

Second Level

Product

The labels in this group describe features of the consumable part. We can distinguish:

  • Ingredients: like No Palm Oils, Natural ingredients,... (we should be able to link to the ingredients taxonomy), New recipe, AOP
  • Nutritional Values: less sugar, with vitamin A, ...
  • Non-consumable parts: the rind of the cheese, etc.
  • Dietary fit: like Halal, Kosher, Vegetarian, Not advised for pregnant women, etc.
  • Health claims: lowers cholesterol

Packaging

Not sure what to add here. But there is a Braille label.

Supply Chain

Before a product reaches the consumer it goes through multiple steps or processes. We can distinguish the following processes:

  • Production: organic, dredge fishing
  • Sourcing: Fair trade
  • Transformation:
  • Packaging:
  • Distribution
  • Transportation

Each process has its own characteristics:

  • Location: made in Italy, eggs laid in France, some ingredients not from France, EU Agriculture
  • Ingredients sourcing: natural flavors, natural product, No GMO's

Properties

Several properties can be distinguished in this taxonomy (see also Taxonomy properties):

  • country:en: - the area where the logo is applicable
  • image:en: - the corresponding logo image
  • ingredients:en: - ingredient (from Ingredients Taxonomy) to which the label pertains.
  • label_categories:en: - the (perpendicular?) categories, i.e
    • en:animal welfare - on how animals (pork (pig), beef (cattle), poultry) should be treated
    • en:certified
    • en:environment
    • en:food safety
  • origins:en: - the origins of an ingredient
  • web:en: the corresponding webpage in English
  • wikidata:en: - the corresponding wikidata entry
  • wikipedia:en: the corresponding wikipedia page in English

Other aspects

A producer or distributor can be put anything he wants on a label. What is the value of the claim he makes? We can distinguish the following:

  • Certified labels: labels that are certified by third parties.Sometimes the label of this third party appears also on the packaging. i.e. Ecocert
  • Verifiable: claims that the user can verify by checking the ingredients or nutritional values
  • Unverifiable: marketing speak. There is a section on Distributor labels.

Implementation

Do we need a hierarchy or can some aspects be handled by properties? When to decide for one, and when to decide for the other?


Possible implementations:

  • Using taxonomy parents to add "structuring" parent entries
    • stephane: We use taxonomies a lot for analysis / parsing. It's important that we differentiate "actual" entries from "structuring" entries. e.g. if there's some regexp that looks for [a label] [an ingredient] --> we don't want parents that are not in fact labels to be recognized. One way around it could be to have a property to indicate that an entry is just "structuring", and that it should not be used for analysis, as a suggestion in autocomplete etc.
  • Using properties to indicate entries belong to specific categories
    • aleene: Proposal: lets remove all parent entries from the taxonomy and only keep the actual labels we want to detect. Each label has a property that specify the category. This category is listed in another taxonomy (label categories), where all the relations between categories are listed.


To be considered:

  • It would be good to implement a solution that could work for other taxonomies than labels