Folksonomy Engine/Functional use cases and specifications

From Open Food Facts wiki
Revision as of 13:35, 13 September 2021 by Charlesnepote (talk | contribs) (Links)
Jump to navigation Jump to search

Note: to see the prototype of each functional use case, you need to install Folksonomy Engine client script.

Open Food Facts' apps and API share some common basic meta-features:

  • Links create value: every property or value or another thing that make sense should be linked to its documentation and groups it belong to.
  • All lists should be:
    • shown as table: sortable by each column; filterable; with added statistics such as number of occurrences, percentage, etc.
    • downloadable: CSV and XLSX
    • queried with a REST API
  • All product's attributes (property/value pairs) should be queried with a REST API.
  • KISS and wiki principles:
    • Straight to the point.
    • Everything can be modified (properties, values).
    • Lowering the barrier: anyone should be able to do things easily.
    • Accept as much usages as we can: fields are not constrained and anyone should enter anything as a new property or a new value. Organisation will come later.
  • If possible main lists of products should be proposed as facets, with the possibility to be mixed with other Open Food Facts facets [create a non-blocking issue]

1. The user asks the list of properties/values pairs for a given product.

  • The user selects a product (link, search result, etc.).
  • The system shows the product, with the list of properties/values pairs.

Rationale: this is the main usage of Folksonomy Engine. It allows to know that a product has some particular properties which are not in the traditional Open Food Facts data model.

Questions:

  • should this use case allow to download all the property/value pairs at one time: the ones from the traditional data model, and the ones from Folksonomy Engine ?

Prototype (beta): https://world.openfoodfacts.org/product/9310036071174/paul-s-caramel-custard

2. The user enters a new property value pair for a given product

  • The user selects a product (link, search result, etc.).
  • The system shows the product, with a form to enter a new property/value.
  • The user enters the property (see dedicated functional use case 2.1).
  • The user enters the value (see dedicated functional use case 2.2).
  • The user saves the property/value pair.

Rationale: to discover new properties, they have to be entered by people. Open Food Facts is a project opened to any kind of editors.

Prototype (beta): https://world.openfoodfacts.org/product/9310036071174/paul-s-caramel-custard

3. The user asks for the whole list of properties.

  • The user asks for the whole list of properties: links located:
    • somewhere near the list of properties/values pairs for a given product
    • anywhere else
  • The system shows the list of all the properties with, for each property, the number of products and the number of different values.
    • It should be a list for the given context: the list corresponding to the products present in the current context, eg. Open Products Facts (create specific non-blocking issue).

Rationale: the list of all properties allows:

  • To explore the different properties and their usages.
  • To forecast the evolution of properties and their usages.
  • To observe which are the most used and the properties which are not really used.

Prototype (beta): https://world.openfoodfacts.org/keys

4. The user asks for the whole list of products with a particular property.

  • The user asks for the whole list of products with a particular property (link from the list of properties, link from a product's page using this property).
  • The system returns:
    • The list of all products using this property; for each product: the product's barcode, optionally the product name, the product's photo, the last modification date, the editor of the property, the value.
    • The link to the property's documentation.

Rationale: the list of products with a particular property allows:

  • To explore all the product with a particular property.
  • To forecast the evolution of products with a particular property.
  • To observe which are the most used and the properties which are not really used.

Prototype (beta): https://world.openfoodfacts.org/key/packaging:has_character

5. The user asks for the whole list of products with a particular property/value pair.

  • The user asks for the whole list of products with a particular property/pair (link from a product's page using this property/value pair).
  • The system returns:
    • The list of all products using this property; for each product: the product's barcode, optionally the product name, the product's photo, the last modification date, the editor of the property.
    • The link to the property's documentation.

Rationale: this use case allows hundreds of new usages; eg. listing all the products that have been recalled last month; all products that are blue; etc.

Prototype (beta): https://world.openfoodfacts.org/key/packaging:has_character/value/yes

2.1. The user enters a property for a given product.

  • The user starts typing the name of a property.
  • The system suggests back all properties containing these letters (beginning at the second letter).
  • The user selects a property or continues to type.
  • Back to use case 2.

2.2 The user enters the value.

  • If possible, the system suggests some values based on the current values already given for the property.
  • The user starts typing the content of the value.
  • The system suggests back all current values related to this property and containing these letters (beginning at the second letter).
  • The user selects a value or continues to type.
  • Back to use case 2.
Retrieved from "https://wiki.openfoodfacts.org/index.php?title=Folksonomy_Engine/Functional_use_cases_and_specifications&oldid=17291"