[Data-modeling] Visual Art Form - an enumerated type?
Jeff Prucher
jeff at metaweb.com
Thu Mar 13 23:43:08 UTC 2008
I think a traditional phylogeny pattern is our best (possibly only) choice
-- add parent/child properties to the existing type. Otherwise we need to
model something like "art form", "sub-art form", "sub-sub-art form" for
however many levels deep we decide is appropriate.
That said, sculpture may be the outlier here. For painting, photography, and
works on paper, the media and genre (watercolors, landscape) will
differentiate the "subforms". Even for most sculptures, the main additional
piece of information is media; it may only be the "relief" types that are
messing with us. So perhaps we really SHOULD maintain the high-levelness of
the "art form type" and garden out the genres/subtypes, after all.
Jeff
> -----Original Message-----
> From: data-modeling-bounces at freebase.com
> [mailto:data-modeling-bounces at freebase.com] On Behalf Of Faye Li
> Sent: Thursday, March 13, 2008 3:48 PM
> To: Freebase data modeling mailing list
> Subject: Re: [Data-modeling] Visual Art Form - an enumerated type?
>
> 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
> >
> >
>
> _______________________________________________
> 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