[Data-modeling] A proposal for consumer products

[Joel Truher]

Hi everybody,

I think there's an opportunity to do something really interesting and
new in this area.  My $0.02 issues to consider:

1. Retail "house brands," which are sometimes relabeled versions of
products sold side-by-side with the house brand.  Obfuscating the
manufacturer is the whole point.

2. Rebadged products, e.g. the Dodge Colt, the Isuzu Hombre, where the
lineage can't be obfuscated.

3. Multi-brand manufacturing.  For example, in the large appliance
category, the same company ("Whirlpool") manufactures appliances sold
under many brands, e.g. Kitchenaid, Maytag.  The product lines under
each brand differ in minor ways from each other, e.g. trim. Another
example would be modern automobile manufacturing, where the
"platform," trim level, and brand all form a kind of mashup.  Another
example is mattress manufacturing; there are surprisingly few mattress
factories in the US, but many brands.

4. Multi-factory manufacturing.  It is common in the apparel category
to contract with multiple sewing shops for the very same garment, each
shop producing a somewhat different level of quality.  The nicer ones
go in the head end of the season, the less-nice ones in the middle.
Sometimes (e.g. in the electronics industry) the factory can be
discerned from the product model number.

5. Channel-specific configuration.  Some products (e.g. appliances,
cell phones) are configured on a per-channel basis, creating
"exclusives" in the feature space.  So, for example, you can get a
Blackberry with WiFi from AT&T, but not from Verizon.  Sometimes these
products have user-visible names (the Blackberry models do), and
sometimes they're invented specifically for the channel, "Maytag
foobar exclusively at Sears".

To me, the new and useful thing to do would be to focus on these
cross-brand commonalities, i.e. to model an items provenance in
addition to its positioning.


Joel


On Mon, Dec 22, 2008 at 12:48 PM, Faye Harris <faye at metaweb.com> wrote:
> +0.5. I'll raise my other hand in full support after I've seen examples
> that showcase real world usage of "product line", "parent product line",
> and "includes sub-lines". But the descriptions sound good.
>
> Thanks for explaining what a manufacturer means in the business world.
> Is there/will there be a way to capture the factories/companies/whatever
> actually contracted to *make*, if not *manufacture*, the physical
> product units?
>
> -- Faye
>
>
> Kirrily Robert wrote:
>> Just talked to Jeff about this and wanted to run it past you all.
>> I'll also crosspost to the Business domain.
>>
>> Currently we have no link between "iPhone" and "Apple" in our schema.
>> That is, the consumer product type has no property for the company
>> that makes that product.  The problem is that if you talk about
>> "Product manufacturer" you get all caught up in the fact that
>> actually, some factory in China manufactures/assembles the iPhone.
>> But I talked to some of our business guys and asked them, and they
>> said that the term manufacturer, though imprecise, is the right term
>> to use.  And we couldn't come up with anythign better.
>>
>> So here's what I propose:
>>
>> 1) A type, "Product manufacturer".  The description for that type
>> should explain that it applies to the company ultimately responsible
>> for producing the product, and isn't intended to capture the actual
>> physical manufacturing of the product eg. by subcontracted factories.
>>
>> 2) On the type "Consumer product", a property called "Produced by"
>> which expects "Product manufacturer".  Calling it "produced by" will
>> discourage people who are looking at the iPhone page from putting in
>> the name of the Chinese factory.
>>
>> 3) Additionally, a type called "Product line" which has the properties
>> "Parent product line" and "Includes sub-lines" (i.e. a phylogeny
>> pattern) as well as "Products in this line" which expects "Consumer
>> product".
>>
>> 4) On "Consumer product", a reverse property called "Part of product
>> line"
>>
>> It's not perfect but it seems good enough for now, and better than
>> nothing.  Thoughts?
>>
>> K.
>>
>>
>>
>
> _______________________________________________
> Data-modeling mailing list
> Data-modeling at freebase.com
> http://lists.freebase.com/mailman/listinfo/data-modeling
>