[Data-modeling] Products with ingredients

[Jeff Prucher]

----- "Robert Cook" <robert at metaweb.com> wrote:

> > I don'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't know how much we  
> > should rely on the index values, even if the client didn'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.)
> 
> Index values really are semantically relevant (see Film performances, 
> 
> for example, where billing order is a major contractual obligation).  
> 
> Also, I think hand numbered system would lead to madness.  And the  
> client can and should be fixed as well.
> 
> One solution here could be to add a property to the ingredient type, 
> 
> "Contains ingredients", which allows one to store these sub- 
> ingredients when appropriate.  This makes the simple case of data  
> entry straightforward (enter what you see on the package into the  
> product type), while ultimately supporting the allergy use case you  
> mentioned.  And, for the allergy use case, you could add an additional
>  
> property to ingredient to the specific allergy it causes.
 
The trouble there is that it will require users to know *which* "enriched flour" or "chocolate chips" topic to select -- many of these compound ingredients have common names, but it's unreasonable to expect them to be the same from manufacturer to manufacturer (or even from product to product, in many cases).  Unless I completely misunderstand you (which is possible), this actually makes the simple case harder -- rather than simply entering what you see on the box, for all compound ingredients you have to first explore Freebase to determine whether the compound ingredient (with all the same ingredients, in the same order) already exists, and, if it doesn't, to edit the new ingredient topic you've created to add all of its ingredients.  People are far more likely, I think, to grab the first ingredient they find with the right name, and not take the next steps to determine whether it's really the same or not.  (What we really need for this is two-level disambiguation in the cli
 
 ent!)

Jeff


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