Re: schema.org sdo-venkman release is now live as v1.92 from Dan Brickley on 2015-01-26 (public-vocabs@w3.org from January 2015)

From: Dan Brickley <danbri@google.com>
Date: Mon, 26 Jan 2015 21:18:23 +0000
To: Aaron Bradley <aaranged@gmail.com>, Public Vocabs <public-vocabs@w3.org>
Message-ID: <CAK-qy=6ze8Gz1W9cmieE8TzT337bZwWF8e9wRi00t1AvegPjpQ@mail.gmail.com>
Thanks! Am working on wiring in Gregg's linter to avoid such things in
future. In meantime,

https://github.com/schemaorg/schemaorg/issues/289

Cheers

Dan




On Mon, 26 Jan 2015 20:51 Aaron Bradley <aaranged@gmail.com> wrote:

Quick note that one of the microdata examples for schema.org
<http://schema.org/VideoGame>/ <http://schema.org/VideoGame>VideoGame
<http://schema.org/VideoGame> contains RDFa syntax.

The "Monopoly" example has this for microdata:

<body vocab="http:// <http://schema.org/>schema.org/ <http://schema.org/>"
itemscope itemtype="http:// <http://schema.org/VideoGame>schema.org
<http://schema.org/VideoGame>/ <http://schema.org/VideoGame>VideoGame
<http://schema.org/VideoGame> http:// <http://schema.org/MobileApplication>
schema.org <http://schema.org/MobileApplication>/
<http://schema.org/MobileApplication>MobileApplication
<http://schema.org/MobileApplication>">

This should simply read:

<body itemscope itemtype="http:// <http://schema.org/VideoGame>schema.org
<http://schema.org/VideoGame>/ <http://schema.org/VideoGame>VideoGame
<http://schema.org/VideoGame> http:// <http://schema.org/MobileApplication>
schema.org <http://schema.org/MobileApplication>/
<http://schema.org/MobileApplication>MobileApplication
<http://schema.org/MobileApplication>">

On Sun, Dec 28, 2014 at 2:15 AM, Paul Watson <
lazarus@lazaruscorporation.co.uk> wrote:

Just a quick note: as per the thread below, I have added the data types of
"URL" and "Intangible" to the existing "Text" type for the properties
artform, material, and surface on the wiki (https
<https://www.w3.org/wiki/WebSchemas/VisualArtwork#Vocabulary>://
<https://www.w3.org/wiki/WebSchemas/VisualArtwork#Vocabulary>www.w3.org
<https://www.w3.org/wiki/WebSchemas/VisualArtwork#Vocabulary>/wiki/
<https://www.w3.org/wiki/WebSchemas/VisualArtwork#Vocabulary>WebSchemas
<https://www.w3.org/wiki/WebSchemas/VisualArtwork#Vocabulary>/
<https://www.w3.org/wiki/WebSchemas/VisualArtwork#Vocabulary>
VisualArtwork#Vocabulary
<https://www.w3.org/wiki/WebSchemas/VisualArtwork#Vocabulary>) and in
github (pull request #38)

Paul

On 26/12/14 07:48, Paul Watson wrote:

 [snip my post because it's getting a bit long]

  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:// <http://vocab.getty.edu/>vocab.getty.edu/
<http://vocab.getty.edu/>> (especially <http://
<http://vocab.getty.edu/doc/>vocab.getty.edu <http://vocab.getty.edu/doc/>
/doc/ <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://
<http://vocab.getty.edu/aat/300015050>vocab.getty.edu
<http://vocab.getty.edu/aat/300015050>/
<http://vocab.getty.edu/aat/300015050>aat
<http://vocab.getty.edu/aat/300015050>/300015050
<http://vocab.getty.edu/aat/300015050>">oil paint</a>

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

  Oh, I like this idea. I like this idea a lot!

Presumably the only change we'd need to implement on the current proposal
would be to add URL as an "expected type" to the "material" and "surface"
properties so that they have expected types of  Text, Intangible,  or URL.


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

  No, I've only looked at specialist Art resources rather than generalist
resources such as DC etc.


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

  I can see the possibilities in this, but I'd suggest that any such change
to CreativeWork is discussed separately and *after* VisualArtwork is
launched as there may be issues that people not following this particular
thread could point out.


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:// <http://vocab.getty.edu/aat/300047896>
vocab.getty.edu <http://vocab.getty.edu/aat/300047896>/
<http://vocab.getty.edu/aat/300047896>aat
<http://vocab.getty.edu/aat/300047896>/300047896
<http://vocab.getty.edu/aat/300047896>">

or:

    <div typeof="CreativeWork">

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

  Rather than use additionalType I'd suggest we retain the VisualArtwork
class and follow the great logic you suggested for "material" and "surface"
at the top of this email to the "artform" property, extending the expected
types to include URL/Intangible as well as the existing Text. Example as
follows:

<div typeof="VisualArtwork">

        An <a property="artform" href="http://
<http://vocab.getty.edu/aat/300047896>vocab.getty.edu
<http://vocab.getty.edu/aat/300047896>/
<http://vocab.getty.edu/aat/300047896>aat
<http://vocab.getty.edu/aat/300047896>/300047896
<http://vocab.getty.edu/aat/300047896>">installation</a>

I think this balances the needs of individual artists who aren't interested
in (or aware of) Linked Data, and just want to mark a VisualArtwork up on
their website with a textual property of "installation" or "oil painting"
etc., but also allows institutions and individuals with the
knowledge/resources to implement Linked Data solutions.


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.

  bibo:edition is very different from the artEdition proposal. bibo:edition
is (as I understand it) like the edition of a book - e.g. this is the 1st
edition of the book (of which 1000 may have been printed) - whereas in art
"edition" is the NUMBER of copies of that piece of artwork (an edition of
20):

>From http:// <http://en.wikipedia.org/wiki/Edition>en.wikipedia.org
<http://en.wikipedia.org/wiki/Edition>/wiki/Edition
<http://en.wikipedia.org/wiki/Edition>:

 "In printmaking, an *edition* is a number of prints struck from one plate,
usually at the same time. This is the meaning covered by this article. This
may be a *limited edition*, with a fixed number of impressions produced on
the understanding that no further impressions (copies) will be produced
later, or an *open edition* limited only by the number that can be sold or
produced before the plate wears. Most modern artists produce only limited
editions, normally signed by the artist in pencil, and numbered as say
67/100 to show the unique number of that impression and the total edition
size."


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:// <http://purl.org/dc/terms/>purl.org <http://purl.org/dc/terms/>
/ <http://purl.org/dc/terms/>dc <http://purl.org/dc/terms/>/terms/
<http://purl.org/dc/terms/>

[2]: http:// <http://bibliontology.com/>bibliontology.com/
<http://bibliontology.com/>

[3]: http:// <http://rdvocab.info/>rdvocab.info/ <http://rdvocab.info/>

[4]: http:// <http://bibframe.org/>bibframe.org/ <http://bibframe.org/>

[5]: http:// <http://en.wikipedia.org/wiki/Art>en.wikipedia.org
<http://en.wikipedia.org/wiki/Art>/wiki/Art
<http://en.wikipedia.org/wiki/Art>



  Cheers,

Paul


[snip]
Received on Monday, 26 January 2015 21:18:54 UTC