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

[Faye Li]

Yeah...it's what happens when the data doesn't quite fit the schema. The 
art form type was intended to only have "painting" instead of "oil 
painting", "watercolor", "acrylic painting" etc. The materials used are 
supposed to be documented in "Visual art medium", i.e. you can search 
for all artworks with art form "painting" and art media "oil" and 
"canvas". I mean, do you really want to list all of the subtypes of art 
forms an artist can work with.

A photographer should have one art form: "photography". Under the new 
model the art form values may explode: "B&W photography", "color 
photography", "digital photogrpahy", "infrared photography", then we can 
go into what should be in the art genre type and start listing "portrait 
photography", "landscape photography", "nature photography", then get 
the inspiration to multiple the two and start filling in "B&W portrait 
photography", "digital landscape photography", "infrared nature 
photography"... A thousand art forms later ("B&W large format 
cross-processed natural light children's candid portrait photography"), 
guess what? The artist is still a photographer. :) And do you really 
want to write a query to list all art forms contained by the 
super-parent art form of "photography" in order to find all photographers?

That said:
1) I think we do need to capture (hair-splitting) specialties, because 
they exist; and hierarchies help differentiating broad categories from 
narrow niches.
2) It'd be ideal if the top level art form stays true to the name: 
painting, sculpture, photography, etc.

O TypeLibrarian, what words of wisdom do you have to offer us?

-- Faye


Bobby Rullo wrote:
> 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
>>     
>
> _______________________________________________
> Data-modeling mailing list
> Data-modeling at freebase.com
> http://lists.freebase.com/mailman/listinfo/data-modeling
>
>