[Data-modeling] More fun with the visual art domain

[Jeff Prucher]

Well, the three methods that I bothered to enter are Bequest, Gift, and
Purchase. This being Freebase, the community can create more instances as
they see fit. :)

Jeff

> -----Original Message-----
> From: data-modeling-bounces at freebase.com 
> [mailto:data-modeling-bounces at freebase.com] On Behalf Of 
> Gordon Mackenzie
> Sent: Thursday, March 27, 2008 10:49 AM
> To: Freebase data modeling mailing list
> Subject: Re: [Data-modeling] More fun with the visual art domain
> 
> So the three methods of acquisition are:
> 
> Bequest
> Gift
> Acquisition
> 
> Will we have the more dubious means of acquisition as in the 
> case of the Elgin Marbles? Nazi-looted works?
> 
> ~ Gordon
> 
> <<< gordon at metaweb.com >>>
> 
> 
> 
> On Mar 27, 2008, at 10:29 AM, Jeff Prucher wrote:
> 
> > If you think it would be of interest, it's easy enough to do.
> >
> > *waves magic wand*
> >
> > There. Have a look.
> >
> > I think the "date last owned" property makes less intuitive 
> sense on 
> > this page than it does on the "art owner" and "artwork" pages.
> >
> > 
> http://sandbox.freebase.com/view/guid/9202a8c04000641f8000000007bd1b9c
> >
> > Jeff
> >
> >> -----Original Message-----
> >> From: data-modeling-bounces at freebase.com
> >> [mailto:data-modeling-bounces at freebase.com] On Behalf Of Faye Li
> >> Sent: Wednesday, March 26, 2008 2:53 PM
> >> To: Freebase data modeling mailing list
> >> Subject: Re: [Data-modeling] More fun with the visual art domain
> >>
> >> Thanks for putting this together, Jeff.
> >>
> >> Have you considered making the "Artwork-owner relationship" a 
> >> reciprocated property of "Art acquisition" type? The CVT 
> makes it a 
> >> little awkward to picture what that will look like, but I think 
> >> there's value in seeing, at a glance, all the artworks that are 
> >> gifts.
> >>
> >> One of the trade-offs of having a single Artwork type for 
> both unique 
> >> artworks, edited artworks and editions of artworks is the 
> confusing 
> >> pair of properties "Edition of" and "Editions" that will 
> be empty for 
> >> 99% of all artworks. It will burn some primitives, but I think it 
> >> might be worthwhile in the interest of cutting down confusion to 
> >> insert the value of "None" for those 99% of artworks. It's also 
> >> regrettable that you can't just query an "Edition" type to see all 
> >> artwork editions, but have to query against the "Artwork"
> >> type for instances that have a value for property "Edition of". Oh 
> >> well. I see the trade-offs and the reasons behind them.
> >>
> >> I'll leave off my regular bits about CVTs not being 
> search-friendly, 
> >> as clearly the need outranks the compromised searchability here. 
> >> Otherwise it looks good.
> >>
> >> -- Faye
> >>
> >>
> >> Jeff Prucher wrote:
> >>> In response to a request on the visual arts discussion boards
> >>>
> >> (http://www.freebase.com/view/discuss/visual_art/artwork#/guid/
> >> 9202a8c
> >>> 040006 41f80000000072fa4ba), I've made some proposed 
> changes to the 
> >>> artwork model, which I'd like to hear feedback on.
> >>>
> >>> There are three changes:
> >>> 1) insertion of a CVT between artwork and location, to 
> track when a 
> >>> piece has been where, and how long (insert standard
> >> discussion about
> >>> time-series data here)
> >>>
> >>> 2) insertion of a CVT between artwork and owner. This 
> includes not 
> >>> only dates, but the method it was acquired (e.g., purchase, gift, 
> >>> bequest), and the purchase price
> >>>
> >>> 3) the addition of an "editions" property on artwork (and
> >> the reverse
> >>> property, "edition of", as well). The idea here is to allow
> >> Freebase
> >>> to display information about editions of a specific artwork
> >> (such as
> >>> casts of a sculpture, or prints of a photograph), which may
> >> have not
> >>> only different locations and owners, but also dimensions,
> >> media, and
> >>> dates of creation. I decided to model edition simply as
> >> "artwork" rather than "artwork edition"
> >>> because of the desire for museums and other art owners to 
> have only 
> >>> one property describing their holdings; an "artwork edition" type 
> >>> would have required two properties -- "artwork owned" and
> >> "artwork editions owned"
> >>> which seemed unnecessarily clumsy. This does mean that 
> the abstract 
> >>> version of the artwork and the individual edition will have
> >> a number
> >>> of redundant properties, but my hope is that these can 
> just be left 
> >>> blank. Naming of editions will be interesting, but that's
> >> an issue every time we model them.
> >>>
> >>> I've entered some casts of "The Thinker" (in bronze and 
> plaster) on 
> >>> sandbox for your perusal. (I put the proposed types in a private 
> >>> domain, so all versions of The Thinker have both the original 
> >>> "artwork" type and a type with only the proposed additions,
> >> "artwork
> >>> (test)"; pretend, if you will, that all the properties are
> >> one a single type. Let me know what you think.
> >>>
> >>> Domain:
> >>> http://sandbox.freebase.com/view/domain/user/jeff/visual_art
> >>> Examples:
> >>> http://sandbox.freebase.com/view/en/the_thinker
> >>>
> >>> Jeff Prucher
> >>> Type Librarian & Ontologist
> >>> Metaweb Technologies, Inc.
> >>>
> >>> _______________________________________________
> >>> 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
>