Re: schema.org sdo-venkman release is now live as v1.92

Paul, Dan,

On Mon, Dec 22, 2014 at 6:15 PM, Dan Brickley <danbri@google.com> wrote:
>
> On 22 December 2014 at 11:58, Paul Watson
> <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 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.)

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.)

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 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> 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]
> >> Sent: Tuesday, December 16, 2014 10:39 AM
> >> To: Paul Watson
> >> Cc: W3C Web Schemas Task Force
> >> Subject: Re: schema.org sdo-venkman release is now live as v1.92
> >>
> >> On 16 December 2014 at 18:26, Paul Watson
> >> <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> 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 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
> >>
> >>
> >>
> >> --
> >
> >
>