Project:Food Rescue/Data types
Contains the latest version of the proposals for data types to be agreed on between this project and the Open Food Facts core team. These proposals are being actively discussed in the Open Food Facts Slack channel #expirydates.
On-product data
Multiple recordings of the data printed on individual product items should be recordable. That prevents having to introduce versioning for the whole product data records, and makes such data more accessible compared to versions. Namely, all recordings are accessible as a set, which makes it simpler to make automatic calculations (maximum observed expiration period etc.).
The proposed data type would be a hierarchy like this:
expiration_type
(options: best_before, use_by, no_date)item_info
(because this is about information relating to individual items rather than the product type)0
(array start, recording no. 0)entry_date
(when the information recorded below was entered; filling fields below meant for derived content later would not change its value)itemtext_picture
(a picture of the text contained on a product, similarly to pictures of ingredient lists etc.)itemtext_prefix
(the text that is part of the packaging print and introduces the print-on information, such as "Best before:")itemtext_fulltext
(verbatim text as contained initemtext_picture
)production_date
(derived from a part ofitemtext_fulltext
, normalized to a date datatype)expiration_date
(derived from a part ofitemtext_fulltext
, normalized to a date datatype)expiration_period
(derived from a part ofitemtext_fulltext
, normalized to a duration datatype)expiration_period_calculated
(taken over fromexpiration_period
if available, otherwise calculated fromentry_date
andexpiration_date
)- (later, various fields for food traceability codes would also be added here, each decoding a part of
itemtext_fulltext
just as the other fields above do)
1
- …
- …
[TODO; relates mostly to per-category articles about storage life, edibility assessment, storage conditions, use after expiry etc.]