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

Getty are moving heavily in the direction of Linked Open Data (or at least
when I look they are- I  could be getting Getty-ered).

The Art and Architecture Thesaurus® (AAT) is currently modeled as
controlled vocabulary.
However, they are using an extension of SKOS that restores the standard
relationships corresponding to "is a kind of", "is a part of", and "is an
instance of".

This allows for an algorithmic mapping from concepts to classes and
individuals; the classes would be suitable for use as types.

sdo could pick a suitably coarse level of detail to sameAs or equivalent
at, and the magic of inheritance can take care of the rest in O(log N)
time.

Simon
On Dec 25, 2014 8:10 AM, "Niklas Lindström" <lindstream@gmail.com> wrote:

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