[Data-modeling] Visual Art Form - an enumerated type?

Bobby Rullo bobby at metaweb.com
Thu Mar 13 22:03:38 UTC 2008


The danger of _not_ doing an explicit parent-child relationship is  
that it makes it hard to search for all paintings, because you have to  
find all the painting sub-genres and and make sure to search them.  
Finding them might be hard because there's no link from "oil painting"  
back to painting.

Even though you'd still have to do multiple queries in a parent-child  
schema, you'd at least have a way to get to all the subgenres.

bobby

On Mar 13, 2008, at 2:49 PM, Faye Li wrote:

> The "Visual Art Form" type was designed with the intention of holding
> only high-level art forms, of which there are only a handful -- thus  
> the
> enumeration designation. However, people apparently desire specificity
> when talking about art forms. One of the lessons in data modeling is
> that schema needs to grow and adapt to fit the data, not the other way
> around, so perhaps it's time we re-examine the "Visual Art Form" type.
>
> In general, I have to say, I'm cautious regarding creating  
> hierarchical
> data models where the line between hierarchies may be blurred at  
> times.
> I've seen things with genres and sub genres and the same data often  
> end
> up in both buckets. The hierarchy also creates problems in reverse
> properties. Should the expected type be the parent type ("genre") or  
> the
> child type ("sub genre"), or some third type created just to include
> both of them?
>
> Also contributing to the confusion of data belonging to parent/child
> types is that there is no automatic propagation, by which I mean if we
> want to designate Topic C as a sub category of Topic B, even though
> Topic B is already marked as a sub category of Topic A, Topic C is not
> automatically added as a sub category of Topic A, even though the
> relationship is clearly transitive. The data can get messy really  
> quickly.
>
> -- Faye
>
>
> Jeff Prucher wrote:
>> That's a good question. It seems like the art form type is pretty  
>> broad;
>> i.e., it includes not only sculpture but also relief and bas- 
>> relief. I
>> thought at first that this type was only used for the very high-level
>> artform (e.g., sculpture, painting, photogrpahy, etc.), in which  
>> case an
>> enumeration would make more sense -- there are probably only a  
>> couple dozen
>> or so such options.  But since the type really does seem to include  
>> varying
>> levels of specificity, I'd be inclined to say that it shouldn't be an
>> enumeration, either.
>>
>> This also raises the question of whether this type needs a phylogeny
>> pattern. I.e., a pair of parent/child or superclass/subclass  
>> properties.  So
>> we could say that "bas-relief" is a variety of "relief" which is  
>> itself a
>> variety of "sculpture".
>>
>> Jeff Prucher
>>
>>
>>> -----Original Message-----
>>> From: data-modeling-bounces at freebase.com
>>> [mailto:data-modeling-bounces at freebase.com] On Behalf Of Bobby Rullo
>>> Sent: Wednesday, March 12, 2008 6:22 PM
>>> To: Freebase data modeling mailing list
>>> Subject: [Data-modeling] Visual Art Form - an enumerated type?
>>>
>>> Should Visual Art Form be an enumeration? The client doesn't
>>> allow you to add types which are enumerations when you click
>>> "Add a Type", and this seems like something that changes
>>> relatively frequently.
>>>
>>> Bobby
>>> _______________________________________________
>>> 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