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

On Tue, Dec 23, 2014 at 12:01 PM, Paul Watson <
lazarus@lazaruscorporation.co.uk> wrote:

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


Hi Paul,

I think see I your point of view as well. However, I believe some fairly
minor tweaks (e.g. extension to the ranges) could make this proposal more
widely applicable. Admittedly, I work with data at a library, not a gallery
(though I've dabbled some in visual art). :)

Have you looked into what Getty are currently working on with Linked Data?
See <http://vocab.getty.edu/> (especially <http://vocab.getty.edu/doc/> for
an in depth explanation of the data).

This at least suggests that the range of the proposed textual properties
should include URL or Intangible, since Getty are publishing URIs for each
of the concepts in your example. You could then do:

    <a property="material" href="http://vocab.getty.edu/aat/300015050">oil
paint</a>
    on <a property="surface" href="http://vocab.getty.edu/aat/300014078
">canvas</a>

, thereby providing actual links to AAT (instead of textual "hints" with
little means of disambiguation).

(The Getty URIs all provide conneg-able HTML or SKOS data in RDF when
dereferenced, with e.g. labels in a bunch of languages.)

Have you considered vocabularies other than VRA? It is interesting to
compare it to the basic vocabularies such as Dublin Core [1], BIBO [2], and
to the more bibliographically high-resolution alternatives such as RDA [3]
or BibFrame [4] (work-in-progress).

I can see that "material" and "surface" are very usable (though quite
specialized). I also think that "material", as a basic property providing
"material or substance of the work" could work for all kinds of
CreativeWorks (possibly based on dc:format). And if "surface" is renamed to
"support" (as it is named in VRA), it too can be generalized to
CreativeWork. (I'd also consider making it a subproperty of "material".)

Regarding the basic typing of the work, like Karen said, it seems feasible
to use the "multiple types" mechanism for that information, using Getty
concepts as external enumerations:

    <div typeof="CreativeWork http://vocab.getty.edu/aat/300047896">

or:

    <div typeof="CreativeWork">
        An <a property="additionalType" href="
http://vocab.getty.edu/aat/300047896">installation</a>

After all, in VRA, you have "workType" for this, which seems close to a
basic type notion. But perhaps a distinct property for this is called for,
unless you'd settle for using "additionalType" with string values (or
anonymous types with strings in "name"), in cases where a controlled
vocabulary is missing. At least, "artwork" is distinctive enough, as
opposed to e.g. dc:type, or RDAs "contentType", which are at times
indistinguishable from "just type". I do wonder if "artform" really should
be specific to "visual art" though, or if it can be moved up to
CreativeWork. But that could be a future step.

In any case, it is certain that all the gazillion variants that artists can
(and should) come up with are beyond anything schema.org should model.
Still, that doesn't preclude it from judiciously introducing some more
common notions. I have missed at least a basic Image in schema.org, and
possibly Drawing, since Painting already exist. I wouldn't mind some kind
of Collage/MixedMaterial as well. Some more basic work types, combined with
a "material" property (with Text *or* Intangible), might be able to capture
all kinds of pastel drawings, acrylic paintings, digital compositions,
assemblages and installations.

I do see how VisualArtwork works as a base class though. Granted, like Dan
said, "visual" seems to preclude various tactile forms of works. (And while
AATs "installation" has "visual work" as a parent in AAT, I presume
installations really can be any combination of visual, auditory and
tactile?) But I assume that "visual" should be interpreted more widely
(like "relating to gestalt")? It would be good to elaborate on this in the
definition, possibly borrowing from wikipedia:s definition of art [5]
(which does include sculpture).

Finally, as is mentioned in the proposal, it seems unnecessary to limit
edition information to the notion of "art". I'd rather see just "edition"
(based on e.g. bibo:edition or bf:edition), applicable to CreativeWork in
general.

I'm really not aiming for neatness and perfection here (well, maybe, but
I'm quite aware that there is no tractable way of slicing the world that
way). I'm mostly looking for some rough distinctive shapes, and properties
applicable in a general way to many various notions of works of various
forms and materials. With the optional possibility of being very precise,
as in linking to advanced external enumerations (such as AAT) when
possible. And certainly I think this proposal can be aligned with these
goals.

Best regards,
Niklas

[1]: http://purl.org/dc/terms/
[2]: http://bibliontology.com/
[3]: http://rdvocab.info/
[4]: http://bibframe.org/
[5]: http://en.wikipedia.org/wiki/Art



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