[Data-modeling] [Developers] Modeling question
Robert Cook
robert at metaweb.com
Tue Jan 8 03:36:24 UTC 2008
I think there is an ongoing debate about whether to have a central
product/brand type pairing or do something more ad hoc. Here's an
example of the first product type I worked on quite awhile ago, a
Computer manufacturer/brand:
http://www.freebase.com/view/apple_inc
In this case, because we have a more product specific type, we get
properties that are more well defined. In apple's case, the computer
models would be distinct from phone models in the topic view because
they appear in distinct properties (from distinct co-types).
Also, to illustrate an idea I introduced earlier in this thread, the
type "Computer" defines a "phylogeny pattern" through a property that
defines a hierarchy between instances of that type. For example:
http://www.freebase.com/view/macintosh_quadra
where the "parent model" property on the "computer" type reciprocates
the "includes models" property.
The phylogeny pattern can be arbitrarily deep, unlike well-defined
product-specific hierarchies. Ultimately, a transitive closure
capability in the API would make this very useful if people would like
to ask, for instance, "find me all of the macintosh models based on
the 68040".
So, as you can see, I've debated the general vs. specific with myself
over time, and I'm still not sure. I do like the idea of a *very*
generic product type that includes properties for web links, but
beyond that I do worry that most things we could imagine in such an
abstract type would probably be of limited utility and confusing to
many users. To that end, I'm now less convinced that the product-
brand relationship type should be captured in the abstract type(s).
R
On Jan 7, 2008, at 6:58 PM, Kavitha Srinivas wrote:
> Is there a plan to connect the brand/product to a company? Maybe I'm
> missing something in this example, but I didn't see it.
> Kavitha
> On Jan 7, 2008, at 7:42 PM, Alec Flett wrote:
>
>> Robert Cook wrote:
>>> I've taken a couple stabs at modeling the abstract product type and
>>> eventually concluded that it should be very simple. My latest straw
>>> man is in my "mobile phones" domain:
>>>
>> I really like that this started in Mobile Phones.
>>
>> At the first (and only?) US-based freebase usergroup, Jamie
>> presented a
>> really important process for modeling apparently abstract ideas. The
>> general idea is to start very specific, and make things more
>> general by
>> "borrowing" properties.. so in the case of coke, you start by
>> creating a
>> "Beverage Manufacturer" and a "Beverage" and setting up the single
>> bidirectional relationship between them. Over in another domain,
>> someone
>> may have set up "Mobile Phone Manufacturer" and "Mobile Phone".
>>
>> Over time, these two mostly-unrelated domains may converge ever so
>> slightly by incrementally working their way towards a general
>> "product"
>> model which may include UPC, physical dimensions and such... or maybe
>> they don't converge because the Beverage domain has deemed that a
>> beverage company's product is a thing like "Coke" and "Diet
>> Code" (which
>> doesn't even have physical dimensions) and a "Beverage SKU" is a more
>> specific thing like "2 liter Diet Coke, plastic bottle"
>>
>> but you can imagine how this evolution could happen: the "portable
>> media
>> player" domain notices similarities between it and mobile phones, and
>> the "handheld device" domain is created with some of the shared
>> generalities between them. The Audiophile, computer, and handheld
>> device
>> domain notice they have similarties and join together to create the
>> even
>> more abstract Consumer Electronics, again pulling up a tiny
>> fraction of
>> whats shared between mobile phones, iPods, stereos, and computers.
>>
>> The point is that these domains don't have to be completely modeled
>> from
>> the top-down. They can start small, and grow more abstract only as
>> needed. I mean ultimately I'm not sure there is much value in a
>> real top
>> level "product" domain - I mean what is it's purpose? So that I can
>> say
>> "Give me all products weighing less than 1lb that are longer than
>> 10 feet"?
>>
>> the problem with high-level abstract domains is that it becomes
>> harder
>> for enthusiasts in individual areas to adapt their domain into this
>> abstract domain. I mean in the beverage domain, the soda enthusiasts
>> decide that a "product" is "Coke" but the mobile phone domain decides
>> that a product is the "US-english version of the Nokia N770, release
>> 2B2007.4" - you have this disjoint between uses of the same domain,
>> making queries within that abstract domain useless.
>>
>> This goes on - "brand" is only one example of where shared terms
>> really
>> break down when you try to apply them globally. The concept of a
>> "brands" and "products" really mean different things to different
>> people.. the "brand" NBC is a TV channel owned by NBC-Universal
>> productions, itself a brand, owned by the GE corporation with it's
>> own
>> brand, GE. From the TV channel's perspective, the show "Friends" is/
>> was
>> a product, as is the Season 4 DVD boxed set of that same show. But
>> what
>> about Friends-branded merchandise produced by some sweatshop in
>> china?
>> Who owns that product?
>>
>> I guess what I'm saying is - it makes a lot of sense to me to start
>> specific and work up, property by property, to more general
>> uses.. .when
>> applicable.
>>
>> Alec
>>
>>> http://www.freebase.com/view/schema/user/robert/mobile_phones/
>>> product
>>>
>>> The idea here is that products have a brand (as opposed to a
>>> manufacturer or producer) and different kinds of web resources
>>> such as
>>> support webpages and online reviews. Obviously, this is intended
>>> for
>>> a tangible product and not a service, which I think could be handled
>>> with the "Product service"/"Service brand" pairing.
>>>
>>> My rule of thumb is if a type is very general, then it should be
>>> simple and have few properties.
>>>
>>> My mobile phone type includes the product type:
>>>
>>> http://www.freebase.com/view/schema/user/robert/mobile_phones/
>>> mobile_phone
>>>
>>> R
>>>
>>> On Jan 6, 2008, at 9:45 PM, Ed Laurent wrote:
>>>
>>>> I guess it's growing on me and Shawn's definition helps quite a bit
>>>> except I would replace "organization" with "person, company, or
>>>> other
>>>> organization". My concern is that the product <-> producer concepts
>>>> are so general that they should be well thought out and modeled as
>>>> generally as possible so that they support all relevant co-types
>>>> now
>>>> and in the future. For example, are UPC, weight/volume, and cost
>>>> universal properties of a product? Coca-cola for example has
>>>> different combinations of ingredients depending on where it is
>>>> sold.
>>>> Similarly, my motorcycle model has a different gear ratio when sold
>>>> in Japan compared to the U.S. Maybe these versions have different
>>>> UPCs but their differences in weight/volume are insignificant and
>>>> you
>>>> might be able to sell each version for the same price. I don't know
>>>> how many topics in Freebase can/will be considered products but
>>>> it's
>>>> probably a bunch. Any problems later on could have big
>>>> implications.
>>>>
>>>> -Ed
>>>>
>>>>
>>>> On Jan 7, 2008 12:19 AM, Shawn Simister <narphorium at gmail.com
>>>> <mailto:narphorium at gmail.com>> wrote:
>>>>
>>>> I would define a Product as a tangible object which is sold
>>>> by an
>>>> organization under a specific brand name. Therefore corn or
>>>> people are not products but Corn Flakes and People Magazine are.
>>>> I know that there are more general definitions of products,
>>>> but I
>>>> think they could be accommodated by additional types like
>>>> Commercial Service, Commodity etc.
>>>>
>>>> Shawn
>>>>
>>>> Ed Laurent wrote:
>>>>> The "Products producer" type with a "Products produced"
>>>>> property
>>>>> sounds pretty good to me. The "Product" type a little less so.
>>>>> Would every tangible topic (including people) need to be typed
>>>>> as a product? What defines a product that separates it from
>>>>> other tangible topics? I agree that this kind of type could be
>>>>> very useful and there should be reciprocation between product
>>>>> and producer but I'm not excited about this approach to
>>>>> doing it.
>>>>>
>>>>> -Ed
>>>>>
>>>>> P.S. This conversation is probably more relevant to the Data
>>>>> Modeling list so I'm cc'ing it.
>>>>>
>>>>>
>>>>> On Jan 6, 2008 10:05 PM, Daniel E. Renfer < duck at kronkltd.net
>>>>> <mailto:duck at kronkltd.net>> wrote:
>>>>>
>>>>> It would probably make sense to have some sort of "products
>>>>> producer"
>>>>> co-type. The producers would have a "products produced"
>>>>> link
>>>>> to the
>>>>> "producer" field of the corresponding "product" type.
>>>>>
>>>>> Not every company produces products, and there are some
>>>>> products that
>>>>> are produced by groups other than companies.
>>>>>
>>>>> Other than that, it sounds like great information to track.
>>>>>
>>>>> Kavitha Srinivas wrote:
>>>>>> For companies, is there any interest in linking companies
>>>>> to their
>>>>>> major products (e.g., Pfizer to its key pharma products)
>>>>> as listed in
>>>>>> Wikipedia? I don't mind adding it, but there is no
>>>>> appropriate slot
>>>>>> to add it.
>>>>>> Key products seems to be important information for a company.
>>>>>> Thanks!
>>>>>> Kavitha
>>>>>> _______________________________________________
>>>>>> Developers mailing list
>>>>>> Developers at freebase.com <mailto:Developers at freebase.com>
>>>>>> http://lists.freebase.com/mailman/listinfo/developers
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Developers mailing list
>>>>> Developers at freebase.com <mailto:Developers at freebase.com>
>>>>> http://lists.freebase.com/mailman/listinfo/developers
>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------------------------------------
>>>>> -----
>>>>> _______________________________________________
>>>>> Data-modeling mailing list
>>>>> Data-modeling at freebase.com <mailto:Data-modeling at freebase.com>
>>>>> http://lists.freebase.com/mailman/listinfo/data-modeling
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Data-modeling mailing list
>>>> Data-modeling at freebase.com <mailto:Data-modeling at freebase.com>
>>>> http://lists.freebase.com/mailman/listinfo/data-modeling
>>>>
>>>>
>>>> _______________________________________________
>>>> Data-modeling mailing list
>>>> Data-modeling at freebase.com <mailto: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
>
> _______________________________________________
> Data-modeling mailing list
> Data-modeling at freebase.com
> http://lists.freebase.com/mailman/listinfo/data-modeling
More information about the Data-modeling
mailing list