I&#39;d like to ask if it might be worth considering this a little differently. What about a &quot;Detailed product&quot; schema that could include ingredients (more aimed at all products not just food) but also other factors as well? Things like manufacturing process, location, recycling information, etc. Or is that too much in one schema? Also labeling information could be useful, but perhaps that belongs in a &quot;Labeled product&quot; schema.<br>
<br>I&#39;m basing this comment mostly on the ideas presented here <a href="http://www.worldchanging.com/archives/007256.html">http://www.worldchanging.com/archives/007256.html</a>. Also the &quot;embodied energy&quot; information being stored in WattzOn here (<a href="http://www.wattzon.com/stuff">http://www.wattzon.com/stuff</a>) could potentially be pulled in.<br>
<br>paul<br><br><div class="gmail_quote">On Tue, Jun 16, 2009 at 4:37 PM, Jeff Prucher <span dir="ltr">&lt;<a href="mailto:jeff@metaweb.com">jeff@metaweb.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Thanks for your input, everyone!  I&#39;m taking the approach suggested here by Faye (and a bunch of other people), and I like the idea of adding a phylogeny pattern to the Ingredient type. Any suggestions for what the parent/child property names should be?<br>

<br>
I don&#39;t have a good solution to the ordering problem of ingredients-within-ingredients, but unless we insert a CVT and ask people to explicitly enter the ingredient order, I don&#39;t know how much we should rely on the index values, even if the client didn&#39;t have a bug with the indexing.  (Actually, an explicit order property would work if we asked users to enter 1, 2, 3, 3a, 3b, 3c, 4, etc. for ingredients within ingredients.)<br>

<br>
Jeff<br>
<br>
<br>
----- &quot;Faye Harris&quot; &lt;<a href="mailto:faye@metaweb.com">faye@metaweb.com</a>&gt; wrote:<br>
<br>
&gt; From: &quot;Faye Harris&quot; &lt;<a href="mailto:faye@metaweb.com">faye@metaweb.com</a>&gt;<br>
<div class="im">&gt; To: &quot;Freebase data modeling mailing list&quot; &lt;<a href="mailto:data-modeling@freebase.com">data-modeling@freebase.com</a>&gt;<br>
</div>&gt; Sent: Tuesday, June 16, 2009 4:04:31 PM GMT -08:00 US/Canada Pacific<br>
<div class="im">&gt; Subject: Re: [Data-modeling] Products with ingredients<br>
&gt;<br>
</div><div><div></div><div class="h5">&gt; Yay! Glad to see this making it to the data modeling mailing list<br>
&gt; since<br>
&gt; our discussions.<br>
&gt; &gt; There are two things I&#39;m seeing with my example data that don&#39;t<br>
&gt; quite work in the model, though, and I&#39;m not quite sure what the best<br>
&gt; way to resolve them is. One is the Corn Flakes ingredient &quot;Milled<br>
&gt; corn&quot;. Should the Ingredient topic be &quot;Milled Corn&quot;, should it just be<br>
&gt; &quot;Corn&quot;, or do we need a CVT to allow people to modify the ingredient<br>
&gt; (&quot;Corn&quot;, &quot;milled&quot;)?<br>
&gt; I&#39;d be inclined to make &quot;milled corn&quot; a stand-alone topic. My main<br>
&gt; concerns regarding data like this are searchability and reusability.<br>
&gt; Users need to be able to link all products containing &quot;milled corn&quot; to<br>
&gt;<br>
&gt; the ingredient, and searching by that ingredient should turn up all of<br>
&gt;<br>
&gt; the products that use it. Secondly, in cooking and in chemistry, the<br>
&gt; process by which a base ingredient is enhanced or modified is usually<br>
&gt;<br>
&gt; considered part of its identification and not, I feel, a CVT-level<br>
&gt; annotator. A recipe that calls for preserved plums cannot be<br>
&gt; duplicated<br>
&gt; with fresh plums, and for a consumer, fermented tofu becomes an<br>
&gt; acquired<br>
&gt; taste whereas regular tofu is widely accepted. Those, for the purpose<br>
&gt; of<br>
&gt; identification and labeling, constitute completely different<br>
&gt; ingredients<br>
&gt; and should be modeled as such.<br>
&gt; &gt; The toothpaste has this ingredient also: &quot;sodium lauryl sulfate<br>
&gt; (from coconut oil)&quot;, which I think is the same issue.<br>
&gt; &gt;<br>
&gt; SLS can be derived from coconut oil or palm kernel oil. I&#39;m not sure<br>
&gt; if<br>
&gt; either could possibly be less of a skin irritant. Most products (I&#39;d<br>
&gt; say<br>
&gt; 90+%?), however, don&#39;t specify from which their SLS is derived. The<br>
&gt; KISS<br>
&gt; method here would then produce three distinct topics: SLS, SLS (from<br>
&gt; coconut oil), and SLS (from palm kernel oil). But then wouldn&#39;t most<br>
&gt; topics link to the (unannotated) SLS? Almost seems like a hierarchy is<br>
&gt;<br>
&gt; needed to set up a parent-children relationship between SLS and its<br>
&gt; two<br>
&gt; (slight) variations.<br>
</div></div><div class="im">&gt; &gt; The other one is ingredients within ingredients: the toothpaste tube<br>
&gt; lists this ingredient: &quot;fruit extracts (strawberry, banana, and other<br>
&gt; natural flavors)&quot;. Treat as four separate ingredients, and punt on the<br>
&gt; relationship?<br>
</div><div class="im">&gt; +1 on treating as separate ingredients here.<br>
&gt;<br>
&gt; -- Faye<br>
&gt; _______________________________________________<br>
</div><div><div></div><div class="h5">&gt; Data-modeling mailing list<br>
&gt; <a href="mailto:Data-modeling@freebase.com">Data-modeling@freebase.com</a><br>
&gt; <a href="http://lists.freebase.com/mailman/listinfo/data-modeling" target="_blank">http://lists.freebase.com/mailman/listinfo/data-modeling</a><br>
_______________________________________________<br>
Data-modeling mailing list<br>
<a href="mailto:Data-modeling@freebase.com">Data-modeling@freebase.com</a><br>
<a href="http://lists.freebase.com/mailman/listinfo/data-modeling" target="_blank">http://lists.freebase.com/mailman/listinfo/data-modeling</a><br>
</div></div></blockquote></div><br>