- From: Paul Watson <lazarus@lazaruscorporation.co.uk>
- Date: Tue, 23 Dec 2014 11:01:58 +0000
- To: Niklas Lindström <lindstream@gmail.com>, Dan Brickley <danbri@google.com>
- CC: "public-vocabs@w3.org" <public-vocabs@w3.org>
- Message-ID: <54994BA6.3000205@lazaruscorporation.co.uk>
On 23/12/14 10:38, Niklas Lindström wrote: > Paul, Dan, > > On Mon, Dec 22, 2014 at 6:15 PM, Dan Brickley <danbri@google.com > <mailto:danbri@google.com>> wrote: > > On 22 December 2014 at 11:58, Paul Watson > <lazarus@lazaruscorporation.co.uk > <mailto:lazarus@lazaruscorporation.co.uk>> wrote: > > Hi Niklas > > > > Yes, there was some discussion some months back, I think. My > view is that > > Painting and Sculpture should be deprecated, but there is a case > for keeping > > Photograph for non-artistic uses (e.g. documentary photography). > > > I recall this, and my position is somewhat different. Although > defining VisualArtwork as based on intent more than on concrete form > can be defended, I wonder if this pattern is somewhat different from > the more "naive realism" of schema.org <http://schema.org> in general. > While CreativeWork might seem to be about "art", taking its definition > and other specific subclasses into consideration, I see a concrete > pattern most compatible with keeping Painting, Sculpture and > Photograph, and *adding* some evidently missing ones, such as Drawing > and Collage (and limit neither to strictly artistic creations). Given > the choice, I'd rather have that than delegating this aspect to > uncontrolled string values of the artform property. (Although I'd also > like VisualWork or Image as a superclass for Paining, Photograph and > Drawing.) Hi Niklas The problem with creating specific subclasses for the hundreds of different artforms that galleries, academics, and artists use to describe the various media that an artist can work in is simply that - there are literally hundreds of them, which would necessitate the creation and maintenance of hundreds of different schema.org subclasses. When I was trying to work out how to model Visual Artworks using schema.org I looked at existing systems such as the Getty Art & Architecture Thesaurus (http://www.getty.edu/research/tools/vocabularies/aat/) and the number of art forms surprised me (and I'm a practising artist as well as a web developer). Additionally new art forms are being invented all the time, especially digital/software forms - which is exciting for artists and art lovers, but for us would mean that new schema.org subclasses would need to be added almost continuously if we were to go with the "specific subclasses for each artform" model, adding to the chaos of maintaining hundreds of subclasses. The final advantage of a generic VisualArtwork class with a "free text" artform property is that it allows the artform property of VisualArtwork to be easily populated from existing and widely used (in academia/museums) controlled vocabularies for art such as Getty AAT stored in "industry-standard" formats such as VRA Core 4. An example of this mapping between schema.org/VisualArtwork and VRA Core 4/AAT is provided on the wiki: https://www.w3.org/wiki/WebSchemas/VisualArtwork#VRA_4.0_XML_using_Getty_AAT_structured_vocabulary I understand where you're coming from, and your approach is much "neater" in theory, but in practice I just don't think it would be viable, especially if we would like art institutions who already use VRA/AAT etc. for their records to be able to implement schema.org on their websites without needing to remap all their existing data. Cheers, Paul > > But given the latter as the only choice, I'd still prefer something > using controlled Intangibles, akin to bookFormat. At least as a clear > option from the start, even if only using external enumerations. > > We discussed Sculpture before, as not being purely a visual thing. If > you search around you'll find plenty of articles about sculpture as a > tactile experience, e.g. (but not only) created by, or for > appreciation by, people who are blind or with visual impairment. With > 3D printing technologies rising fast it seems reasonable to assume > "look don't touch" attitudes to sculpture might fade further in the > face of cheap and accurate object replication. In general I don't see > a need to throw out perfectly serviceable types (Painting too) just > because we've generalised them. Although I'll acknowledge that having > two ways of saying the same thing does add complexity, having a short > form as a simple type can also often be handy. > > > I certainly agree to keeping them. I do feel some discomfort with the > two ways of saying the same thing, at least by adding artform and > material at this level of specificity. You might as well add something > like workForm and workMaterial (or to use the RDA equivalents, > contentType and carrierType) directly on CreativeWork, with a choice > of Text or Intangible. That could supersede bookFormat as well. > > (I do admit that my meager attempt at "normalization" here is rather > incomplete, as we still have MediaObject and its subclasses which > might bee seen as at odds with this approach. Still, I think these > options are worth considering, to avoid divergent overspecializations > in new corners of schema.org <http://schema.org>.) > > Cheers, > Niklas > > > cheers, > > Dan > > > Cheers, > > Paul > > > > > > On 22/12/14 11:54, Niklas Lindström wrote: > > > > Hi all, > > > > Has there been any more thoughts about resolving the "artform as > distinct > > property" vs "subclasses per form" divergence introduced here? > By which I > > mean whether the existing classes Photograph and Painting should be > > deprecated in favour of this distinct (and textual) notion of > artform? > > > > And depending on that, would it be reasonable to at least extend > the range > > for artform, material and surface to include Intangible > alongside Text? It > > can be quite useful to be able to point to e.g. a class or > (external) > > enumeration for these values if possible, to support controlled > value > > coordination (and e.g. internationalization of labels) when > presenting > > collections. > > > > ... Or unless we'd want to go down the same route as for e.g. > > BookFormatType, I suppose the schema.org <http://schema.org> way > of doing things would be "Text > > or URL" (although in my Linked Data mindset, I think "Text or > Thing" when I > > see that...) > > > > Cheers, > > Niklas > > > > > > On Sat, Dec 20, 2014 at 8:20 AM, Paul Watson > > <lazarus@lazaruscorporation.co.uk > <mailto:lazarus@lazaruscorporation.co.uk>> wrote: > >> > >> Hi Tom > >> > >> The colorPalette property/type never achieved consensus - it was > >> problematic in several respects. As such it has been dropped - > at least from > >> this initial launch of the VisualArtwork type. > >> > >> I agree that "materials" should be "material" - this was > discussed about a > >> year ago, but I must have forgotten to make the change on the > wiki. I've > >> made that change in both the main file and the examples on > github, and > >> submitted pull requests for both. > >> > >> Regards, > >> > >> Paul > >> > >> > >> On 19/12/14 23:36, Tom Marsh wrote: > >> > >> It looks like sdo-stantz is missing the colorPalette property and > >> ColorPalette type. Are those still to be incorporated? > >> > >> Also, should materials be singular (material) instead? I > thought we were > >> avoiding plurals. > >> > >> -----Original Message----- > >> From: Dan Brickley [mailto:danbri@google.com > <mailto:danbri@google.com>] > >> Sent: Tuesday, December 16, 2014 10:39 AM > >> To: Paul Watson > >> Cc: W3C Web Schemas Task Force > >> Subject: Re: schema.org <http://schema.org> sdo-venkman release > is now live as v1.92 > >> > >> On 16 December 2014 at 18:26, Paul Watson > >> <lazarus@lazaruscorporation.co.uk > <mailto:lazarus@lazaruscorporation.co.uk>> wrote: > >> > >> On 15/12/14 17:27, Dan Brickley wrote: > >> > >> On 15 December 2014 at 17:09, Paul Watson > >> <lazarus@lazaruscorporation.co.uk > <mailto:lazarus@lazaruscorporation.co.uk>> wrote: > >> > >> On 12/12/14 09:28, ☮ elf Pavlik ☮ wrote: > >> > >> On 12/11/2014 04:37 PM, Dan Brickley wrote: > >> > >> We have just 'soft launched' the large package of improvements > >> recently circulated as the 'venkman' release. While they are > >> intended as the foundation for a "version 2.0" release we wanted > >> to get the vocabulary improvements out there ASAP without rushing > >> to v2 prematurely. There's a lot more that could be said about > >> each set of changes (Music, Video games, Sports, ItemList / > >> breadcrumbs, etc etc.) than we can say today, so for now we'll > >> stick with a simple "thank you!" to all who have participated in > >> this effort. Thanks :) > >> > >> As always our issue tracker is open to all for any bugs that have > >> crept in. You'll find it linked from: > >> > >> Release notes: http://schema.org/docs/releases.html#v1.92 > >> > >> Great work! + kudos to everyone who contributed ☆ > >> > >> also glad to see on github a *milestone* for the next one \o/ > >> > >> +1 great work > >> > >> Would be great if we could get schema.org/VisualArtwork > <http://schema.org/VisualArtwork> released as > >> some point - it's been waiting for a very long time and seems > to get > >> ignored from every release > >> > >> Funny you should mention that! Vicki and I were just chatting about > >> it earlier. Sorry this is taking so long, ... but here we go: > >> > >> > >> > https://github.com/danbri/schemaorg/commit/97b9c5c1d35ad9cd911c300402 > >> 5e5678467183b9 http://sdo-stantz.appspot.com/VisualArtwork > >> > >> Where 'stantz' is the codename for whatever the next release > ends up > >> being called, i.e. the milestone in Github that elf Pavlik spotted. > >> > >> We need to translate the examples to other formats but other than > >> that I think this looks good. > >> > >> I've opened a bug in github to track this (things are slowly > >> migrating over from W3C wiki/tracker), > >> https://github.com/rvguha/schemaorg/issues/204 > >> cheers, > >> > >> Dan > >> > >> That's excellent news! > >> > >> I attempted to add the Microdata and JSON format examples in Github > >> today, as well as adding the missing artEdition property. > >> > >> You should have pull requests for those two changes (so long as I > >> worked on the correct branches) > >> > >> Yes I think that workflow makes sense - I pulled those edits > into my > >> sdo-visualwork then from there I made a new pull request that > puts them into > >> sdo-stantz. That's maybe a bit indirect but keeps things clear. > I don't > >> live-and-breath Git(hub) workflow methodologies so there's a > certain amount > >> of making-it-up-as-we-go-along happening here. Anyway, I've > merged it in > >> via > >> https://github.com/danbri/schemaorg/pull/33 "danbri wants to > merge 4 > >> commits into sdo-stantz from sdo-visualwork" > >> > >> http://sdo-stantz.appspot.com/VisualArtwork > >> http://sdo-stantz.appspot.com/artEdition ... seem to show the > changes just > >> fine, thanks :) > >> > >> Dan > >> > >> > >> > >> -- > > > > >
Received on Tuesday, 23 December 2014 11:02:33 UTC