-
Notifications
You must be signed in to change notification settings - Fork 844
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
Add Suitability to Restricted Diets to Recipe #845
Comments
This carves off a piece of #458. As mentioned in that thread, it follows the suggestion of airline meal codes (such as listed by vktravels), with certain irrelevant codes like Baby Meal removed. That thread also brought up allergens in the context of proposed Unicode emoji for common allergy-sensitive ingredients. This proposal is related, in that some diets focus on avoiding ingredients due to sensitivity, such as lactose intolerance. However, this proposal focuses on more coarse-grained categories of foods that users might want to avoid -- anything with gluten, anything with lactose, etc. It seems that many recipe sites offer categories at this more coarse-grained level. |
There is also overlap here with some comments in #607. This proposal ( As discussed above, |
Thanks for this and for the pull request including examples (often we miss out on getting examples with new vocab). Let me just lift out the main terms from the pull request here for wider visibility: a property suitableForDiet and an enumerated type, RestrictedDiet whose enumerated instances are currently: DiabeticDiet, GlutenFreeDiet, HalalDiet, HinduDiet, KosherDiet, LowCalorieDiet, LowLactoseDiet, LowSaltDiet, VeganDiet, VegetarianDiet. I'm personally a big fan of this proposal, but would encourage at least a little consideration here of scope and potential overlaps before proceedings. If we do something like this for Recipe we should at least consider whether it can also improve other areas of our schemas that touch on this issue. For example http://schema.org/FoodEstablishmentReservation and http://schema.org/FoodEstablishment - perhaps now or later we might add a catersForRestrictedDiet property linking a FoodEstablishment to these same values. Or perhaps home-cooked recipes and professional restaurants use different terminology, different granularity? Similarly there is the question of food-oriented Product description, medical/health etc. I do not want to encourage us to attempt to solve everything relating to food, nutrition and diets in one set of schema changes. However we should have a rough sense how these areas fit together. @mgh128 and @ekgs1 may be able to comment from the GS1 perspective. My feeling is that these proposed terms are useful, and may also be relevant to describing 'food establishments' and potentially products. And that they will be complemented later by richer food packaging label -style product data most likely in an external extension to schema.org from GS1. Pinging schema.org steering group: @scor @mfhepp @pmika @chaals @tilid @shankarnat @ajax-als @rvguha @vholland --- any views? |
Is this pull request #846? It looks good to me. I am assuming we will just wave our hands at the idea of "kosher" and not get into the nitty details about different distinctions of kosher. Adding something like catersForRestrictedDiet to FoodEstablisment makes sense as well. |
Yes, this is pull request #846. About the various types of kosher, I see this as a trade-off between being as accurate as possible and reducing burden on the publishers. I felt like including too many sub-types would make it more likely that publishers would either get it wrong or not bother at all. There is a similar trade-off with vegetarianism. |
Thanks for alerting me and Eric Kauz at GS1 to this discussion and proposal. Within the GS1 web vocabulary, we have a few ways of indicating diet type: We currently have a code list gs1:DietTypeCode with instances representing: COELIAC The property gs1:dietCode links a gs1:FoodBeverageTobaccoProduct to an instance of gs1:DietTypeCodeDetails, which in turn links via gs1:dietType to one or more instances of gs1:DietTypeCode above and may also link via gs1:dietTypeSubCode to a free-text localised string (rdf:langString) that indicates a specific diet sub-type, such as a Pareve diet type sub code of Kosher. We also have a property gs1:dietTypeDescription that expects a free text (rdf:langString) description of the diet if this is not stated in the list of diets. We have another code list gs1:PackagingMarkedDietAllergenCode with instances representing dietary/allergen information marked on the packaging of a product, with the following instances: APPROVED BY ASTHMA AND ALLERGY ASSOCIATION We also have a code list gs1:PackagingMarkedFreeFromCode with instances corresponding to freedom from: ARTIFICIAL COLOURING as well as other instances for where the packaging indicates reduced levels of: LACTOSE A further code list gs1:PackagingMarkedLabelAccreditationCode indicates various national and global certification marks present on the packaging - not only related to diet but also sustainability (e.g. FSC, MSC) and ethical and environmental considerations (e.g. Leaping Bunny / cruelty-free cosmetics etc., RSPO mark for certified sustainable palm oil) All of these values have been derived from previous work on the GS1 Global Data Dictionary, GDSN data model and GS1 Global Product Classification, all of which are the result of a global multi-sector industry-driven consensus-based standardisation process over the last 40+ years, involving over 1 million companies including most manufacturers and major retailers. I hope this info is useful for filling in some of the gaps - but I realise that there may also be some gaps we need to fill. We do have a fairly extensive set of nutritional information properties which are used in combination with an explicit gs1:nutrientBasisQuantity so that there is no ambiguity about whether the nutritional values are expressed per pack, per serving, per 100g / 100ml of product. We have already shared that info with the ScheMed folks who are developing a healthcare extension to schema.org. I have attached a PDF document that we recently shared with them, which gives an indication of the coverage and some draft examples using JSON-LD. Thanks to the alert from Dan Brickley last week, we're also looking into extending the GS1 web vocabulary to support provision of nutritional information for meals at restaurants and takeaways, building on the requirements from the forthcoming FDA legislation in the USA - so we should have a further draft update to our GS1 web vocabulary to support that very soon. Best wishes,
On 22 Oct 2015, at 16:35, Dan Brickley notifications@github.com wrote:
|
In the GS1 standards around diet types, we decided not to try to manage the sub-types around Kosher since there are so many varieties some of which are managed regionally (for example CRC Kosher which is a Chicago based certification). Instead we established a Diet Type of Kosher using a code list and managed specific types of Kosher using a Diet Sub-type which is an open string. As mentioned below, this concern can also apply to other diet types. Best Regards Eric From: Benjamin Douglas [mailto:notifications@github.com] Yes, this is pull request #846#846. About the various types of kosher, I see this as a trade-off between being as accurate as possible and reducing burden on the publishers. I felt like including too many sub-types would make it more likely that publishers would either get it wrong or not bother at all. There is a similar trade-off with vegetarianism. — CONFIDENTIALITY / DISCLAIMER: The contents of this e-mail are confidential and are not to be regarded as a contractual offer or acceptance from GS1 (registered in Belgium). |
Thanks @mgh128 . Could you perhaps post the PDF somewhere in the public Web so that it can be found from Github too? The (presumably emailed) attachment didn't seem to get linked from the issue automatically. This confirms my suspicion that we are dealing here with overlapping domains but very different levels of detail. I propose that we continue with these efforts in (communicative) parallel - looking for opportunities to align each list but not attempt any 'grand reconciliation' into a single effort. It may be useful to create a table of equivalences and perhaps make those machine-readable in some way. At least for humans a simple 'see also' table that compares/contrasts would be useful. But considering "NATURAL GLUTEN" and "GlutenFreeDiet" for example, there are often close but indirect matches. For the record we have a precedent for similar but related terms between restaurants and recipes: http://schema.org/recipeCuisine and http://schema.org/servesCuisine. Aside to @mgh128 re "APPROVED BY ASTHMA AND ALLERGY ASSOCIATION", "APPROVED FOR TUBE FEEDING" - on the former, there appear to be several such associations. On the latter, ... approved by whom? (we should probably move the GS1 details to a separate issue when you're ready for such things). |
Hi Dan, Yes - I'll check with Eric if we can host that PDF document somewhere on Yes, I agree that continuing the development in parallel and keeping the Regarding 'approved for tube feeding', our rdfs:comment says 'The item is For 'approved by the asthma and allergy association', the rdfs:comment is Thanks - this is all very useful feedback. Best wishes,
On Thu, Oct 22, 2015 at 6:58 PM, Dan Brickley notifications@github.com
|
Sorry - the link to the PDF file I previously attempted to post is now http://tinyurl.com/GS1webVocabNutrition Best wishes,
On 22 Oct 2015, at 18:58, Dan Brickley notifications@github.com wrote:
|
I also like the idea of applying these labels to restaurants and restaurant reservations. I did some browsing around restaurant review and reservation sites and it looks like the granularity level is roughly similar. There is little consistency among these sites in terms of organization of filters/facets, but at least the terminology and granularity level of restricted diet types is similar to what recipe sites use. Yelp has a filter on restaurant "Category", which mixes cuisine (New American and Asian Fusion), meal type (Breakfast & Brunch and Dessert) and other features. Included in this list are diets "Gluten-Free", "Vegan" and "Vegetarian". Opentable has a "Cuisine" filter that mostly aligns with regional food types such as Brazilian Steakhouse and Contemporary Asian. Included in this list are diets "Halal", "Kosher", "Vegan" and "Vegetarian/Vegan". Zagat has a "Cuisine" filter that mixes a number of concepts such as restaurant type (Bistro and Gastropub), region (German and Argentinian) and representative foods (Burger and Ramen). Included in this list are diets "Gluten Free", "Kosher", "Vegan" and "Vegetarian". |
Thanks all for the discussion and attention to detail. I have merged in #846 from @bbdg (technically via #957 as it needed to target sdo-deimos instead of sdo-phobos branch), so that we can handle any 'final polish' tweaks against a concrete proposal. I've also published this as work-in-progress for our next release candidate:
One specific concern on the wording of the suitableForDiet property. The meaning is clear enough overall but "Followers of this diet are allowed to eat the dish." has a top-down feel to it. Can we say the same thing in a way that covers dietary choices that are not externally imposed? |
How about "A dish which follows the guidelines of this diet"? |
That describes the inverse relationship pretty well |
Could we live with "Indicates a dietary restriction for which this recipe is suitable, e.g. diabetic, halal etc." /cc @bbdg |
The wording "Indicates a dietary restriction..." sounds fine to me. |
Ok, updated to "Indicates a dietary restriction for which this recipe is suitable, e.g. diabetic, halal etc.". |
Hi, minor comment. diets are sometimes based on religious guidelines and are not necessarily deemed as restrictions which have a stronger meaning. Guidelines can be observed more or less closely. Perhaps "Indicates a dietary restriction or guideline for which this recipe is suitable, e.g. diabetic, halal etc." |
Thanks @ekgs1, I wasn't conscious of that nuance but it makes sense - I have amended the definition. |
@scor @shankarnat @mfhepp @tmarshbing @pmika @chaals @ajax-als @vholland @rvguha - please take a look; I'm queuing this for our next release. |
+1 |
re-ping: @scor @shankarnat @mfhepp @tmarshbing @pmika @chaals @ajax-als |
it's on my to-do list |
This is on my to-do list too, would respond by Monday. Thanks! |
I am fine with just approaching the dietary restriction separately and I look at the pull request at #846 . I have some observation on the enums http://sdo-deimos.appspot.com/RestrictedDiet -> Also wanted to add a set of vegetarian food where people do not eat Onions, Garlic etc. This is called as Jain Food. https://en.wikipedia.org/wiki/Jain_vegetarianism . There are specific restaurants which do that. Not sure if it is a large enough phenomenon to add Jain Diet as one of the values in Enum. Rest all look good to me. @danbri Let me know if there anything else that you need us to look at. Thanks, |
Thank you for your comments, Shankar. On the issue of Hindu Diet, admittedly there are not as uniform a set of rules as for Halal or Kosher, but it seemed appropriate to add it for completeness. It is naturally up to the recipe creator to determine this, but it most likely would at least imply avoiding beef. Also, when combined with Vegetarian, it would likely imply lacto-vegetarian as opposed to the ovo-lacto variant more common in Europe. As a practical matter, one of the inspirations for this list was the set of airline meal types offered by international airlines. Many carriers with flights to and from India include Hindu Diet as a category of special meal, for example in this list by Singapore Airlines. As for Jain vegetarianism, I considered it but left it out of this list because the global population is relatively small and I wanted to start with coverage of major diets. We could certainly add it later if this attribute gains traction and a need for further specialization was evident. There are a number of flavors (excuse the pun) of vegetarianism that could be added in the future as well if the need arose, including pareve kosher, raw vegan, etc. For the first iteration, I didn't want to muddle the vegetarian story too much. |
Currently, "A diet conforming to Hindu dietary practices." How about A diet conforming to Hindu dietary practices, in particular, beef-free." ... or similar. We might also benefit from an example and wording tweak for Recipe that shows multiple dietary restrictions on a single recipe. |
@bbdg Thanks for the explanation, the vegetarian definition is quite complex . I just wanted to be sure on what we are saying by Hindu diet and now it makes sense, given it is a more international definition used by Singapore airlines etc. |
re-pinging @scor @mfhepp @tmarshbing @pmika @chaals @ajax-als for more views. Based on this discussion and looking around a bit, my inclination is to deal with vegetarian/vegan distinctions in more detail in future revisions, but make the amendment I propose above for Hindu diet, mentioning beef-free. That said if there is a clear, small, and stable set of vegan/veggie-related codes we could adopt quickly that would be fine by me too. Reminder, current proposed list is http://sdo-deimos.appspot.com/RestrictedDiet : DiabeticDiet |
In the GS1 web vocabulary, we define the following instances of DietTypeCode:
We also define the following instances of PackagingMarkedFreeFromCode: FREE_FROM_ ...
We also define various instances of AllergenTypeCode to refer to specific allergens that may be present or are known to be present. I hope that the above are useful to consider. As far as I understand it, these are based on terms in the GS1 Global Data Dictionary and have been compiled based on input from multiple manufacturers regarding the diet markings for their products. More info, instances and definitions at:
Best wishes, Mark Harrison On 27 Jan 2016, at 18:15, Dan Brickley notifications@github.com wrote:
CONFIDENTIALITY / DISCLAIMER: The contents of this e-mail are confidential and are not to be regarded as a contractual offer or acceptance from GS1 (registered in Belgium). |
I think that referring to representations of food that are controlled by For example, Organic in the United States is a regulatory certification Kosher is a similar thing. The Orthodox Union certifies Kosher (and And even on the medical ones like allergies, it might be better to allow By helping to add a few of the many tags, you may be making identifying Daniel Bennett On 1/27/2016 1:44 PM, Mark Harrison wrote:
|
I believe Kosher can be viewed as a general term for a diet although it is useful to also have a means to include the specific type of Kosher that applies to a product. In the GS1 Vocabulary, we used a diet type which is a general diet classification with a managed code list and a diet sub-type which is a string field which allows for very specific types of kosher that can be locally managed. |
The fact that ultimately we are pointing at recipe Web pages does take the pressure off somewhat
Perhaps linking from each of our codes to relevant Wikipedia entry will help indicate the subtleties |
I think that using links/URLs instead of strings may be better generally
I have found that if you pretend to know the proper term for things that Do you really want to get in the middle of Organic wars, where there are Daniel Bennett On 1/27/2016 2:38 PM, Dan Brickley wrote:
|
@citizencontact I agree that using URL's represents higher accuracy, but I am not sure they serve the ultimate purpose of this markup. I am imagining the recipe publishers on one side, the users on the other side, and search engines in the middle. The markup then serves to bind all of these agents together. URL's add extra burden on the publishers to find a site that accurately and authoritatively represents their assumptions about the dietary restrictions of their recipes. The publishers, sometimes small companies or even casual bloggers, have a wide range of backgrounds in such things and this presents a potentially large burden to research. URL's would also add to the fragmentation of the space. Even if there are multiple authorities on what constitutes Kosher, if one publisher prefers one authority and a different publisher the other, we have opened up a distinction for something that many users would consider practically equivalent. For a given query or filter, a user then may be only seeing a partial set of relevant results. Finally, from the search engine's perspective, the ecosystem has becomes harder to manage with URL's. A search engine is not going present URL's for users to filter on, nor require users to explicitly search for URL's as recipe modifiers. So the onus is on the search engine to map query terms with markup. This process is more stable and complete with a fixed vocabulary as opposed to arbitrary URL's that will change over time according to fads and developments in the various authority organizations. At the end of the day, users are trying to find recipes and recipes are trying to be found. That process now often takes the form of recipe publishers using keywords in recipe titles and categories, sometimes in unnatural ways. This markup is meant to replace titles like "Yummy Lentil Soup (Kosher)" with simply "Yummy Lentil Soup" and a separate markup of "Kosher". Providing a fixed vocabulary reduces the guesswork on the part of the publishers and increases the efficacy of search engines to tailor search results to users. The trade-off, for sure, is accuracy, but in a browsy space such as recipes I would argue that it is worth it. |
Hi Daniel, I totally agree. In fact we are already using web URIs throughout our GS1 web vocabulary for code lists and their instances. At present the initial release of the GS1 web vocabulary only has definitions in English but we are using language tags (e.g. @en ) in the vocabulary definition file and do have national GS1 member organisations in over 100 countries who already take care of translating many of our technical standards and guidelines into local languages, so hopefully we'll be adding multi-lingual labels and comments in a future release. You can already see the code lists I mentioned at: http://gs1.org/voc/DietTypeCode The codes within http://gs1.org/voc/PackagingMarkedLabelAccreditationCode do reference external accreditation / certification agencies, which I think aligns with the very good point you were making in your previous e-mail about which agency is defining whether something is organic, kosher etc. I wasn't intending to claim that we have a comprehensive list - just letting people know what is already available in the GS1 web vocabulary to help with dietary indications. Our focus is often more on describing products (including food products) rather than recipes, although we have recently updated our nutritional information properties to support not only nutritional information specified in EU 1169/2011 but also more recent US FDA requirements for nutritional information about meals in restaurants and takeaway food establishments. I hope this helps. Best wishes,
On 27 Jan 2016, at 21:33, Daniel Bennett notifications@github.com wrote:
CONFIDENTIALITY / DISCLAIMER: The contents of this e-mail are confidential and are not to be regarded as a contractual offer or acceptance from GS1 (registered in Belgium). |
The proposal looks reasonable to me. The only concern I have is whether it is correct to use airline types of food as primary sourse for closed set of dietary restrictions. |
Thank you @ajax-als for your input. I had not heard of the Pevzner diets, and that is a good example of how different cultures organize diets in different ways. It is partly for this reason that my proposal does not try to define a detailed hierarchy, but only covers very broad concepts. The issue of a closed versus open set was a critical decision, and there are pros and cons to each side. Certainly an open set of keywords allows regional flexibility, arbitrary granularity, expansion beyond traditional meanings of dietary restriction, and adaptability to current trends. However, it is just this freedom that I think hurts searchability. It becomes a guessing game on both the part of the recipe publishers and end users to align their terminology. A closed set simplifies the task of the publishers and gives search engines the tools for presenting coherent and complete results to users. This set will certainly not cover every facet of every diet and it is not meant for honing in on very specific dietary attributes. Searching for recipes is inherently a process of looking through many options, picking a favorite, and then tuning to individual needs. These categories are aimed at making the first browsing step more effective by weeding out obviously poor candidates while including a wider range of good candidates. The list tries not to be too airline-centric, but instead took its inspiration from airline meal codes mostly because they are practical and field-tested. As for more open-ended tagging of recipe attributes, there is always the existing http://schema.org/keywords attribute that could be used for more specific traits. I feel that would be a good place to put the Pevzner category, should one want to include that. I worry that including a large taxonomy underneath dietary restrictions will increase the burden on the part of the recipe publishers and make erroneous markup more likely. |
Let's try to wrap this discussion up; I think we're pretty close to consensus. There is clear value in having a predictable enumerated list, as well as showing how this practice can be extended to capture a broader and more nuanced range of food practices. I like the idea of using 'keywords', but note that it won't get used unless we encourage it via examples and definitions. How about:
We might also add that "Other more complex or subtle dietary issues may be addressed within the full text of the recipe, or directly during the food preparation process.". - I believe this would bridge this work with the issues around food packaging that are explored much more comprehensively in the GS1 vocabulary. |
OK, we now have the following:
Note that the applicability of 'keywords' is because recipes are creative works, so the additional explanatory text was attached to Recipe rather than to RestrictedDiet. The existing description for Recipe was simply the two words "A recipe.". Adding two sentences on this particular issue seemed like the most we should say on the topic. As always, more examples illustrating this vocabulary would be very welcome. Can everyone live with this design? /cc @scor @mfhepp @pmika @chaals @tilid @shankarnat @ajax-als @rvguha @vholland |
… be used to add additional information. See #845
+1 |
2 similar comments
+1 |
+1 |
Relaying a "sure!" from @pmika |
+1 |
Closing per http://webschemas.org/docs/releases.html#g845 |
I am slightly confused with the Ideally we could have:
Or is this alternative viable?
Would have to allow and use |
Many recipe sites that already use schema.org markup have tags or categories for restricted diets such as Gluten Free or Low Fat but no way to markup those attributes formally. I would like to propose a closed set of common dietary restrictions that could be used to tag such recipes.
Here are some examples of where these kinds of concepts are used on popular, existing recipe sites.
In addition to these large, general purpose recipe sites, there are smaller boutique sites that address specific dietary needs.
While there are a many different types (and sub-types) of diets, providing a small list of common ones should cover most of the prevalent use cases and simplify the task of the recipe publisher. The list I propose (in a forthcoming pull request) was inspired by the meal types offered by major airlines. While there is no official standard as to the specific list of dietary names, there is a large degree of overlap among the world's major international airlines. The list was adapted to suitability to the recipe domain and use of those dietary types in major recipe sites.
The text was updated successfully, but these errors were encountered: