New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Properties related to non-food products should not be returned for food products (and vice-versa) #128
Comments
Solution 1The first solution is to use prefixes to identify which things the property applies to. There are no changes in the API. When suggesting properties, the UI can filter the relevant ones. Case 1: the property is dedicated to food products. Eg.
Case 2: the property is dedicated to general products and beauty products, but not food products. Eg.
PROs:
CONs:
Solution 2Create another DB which lists all properties and their targeted products.
PROs:
CONs:
Solution 3Create a taxonomy for the properties. A taxonomy allows complex cases. Eg.:
PROs:
CONs:
|
Do you think that we could have option to add a column in the database for the sources (Open Food Facts, Open Beauty Facts, etc.)? Like this, flammable entered in both Open Food Facts and Open Beauty Facts would lead to 2 rows in the database. Then, we could either look at flammable for Open Food Facts or for Open Beauty Facts or for both. |
I like the idea of @benbenben2 because it does not require more work. It just separates usages. Until a property is added to a product type, it won't be suggested. And API call can decide to filter or not on database type. |
@benbenben2 @alexgarel yes this solution is quite simple, it's a bit like solution 1, but with an extra field.
It does:
Solution 1 seems more simpler: we only need to modify the front-end (+ perhaps move few wiki pages). But it has the drawback to use long names, which can be different in the database and in the front-end... |
Maybe I do not get the point of the folksonomy engine. |
@benbenben2 this is the way openStreetMaps works ! (as we democratize Folksonomy Engine, we may also add some widgets for common properties) |
@benbenben2 like in OpenStreetMap project, everyone can create his/her own properties, but the properties are much efficient if they are also used by other people. Documenting the properties is not mandatory, but the undocumented properties get less chance to be reused. |
There are now more than 75 properties created by users (2023-01).
Some of them are dedicated to food products.
Some of them could be used for many, or even nearly any, kind of products:
Some of them could be used for different kind of products including food:
And some of them are clearly not relevant for food products and even sometimes exclusively dedicated to some categories:
These properties are visible at three places:
I think that deploying Folksonomy Engine to sister sites (see #62) will quickly lead to anarchy if we don't address this topic.
The text was updated successfully, but these errors were encountered: