W3C home > Mailing lists > Public > public-vocabs@w3.org > December 2014

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

From: Paul Watson <lazarus@lazaruscorporation.co.uk>
Date: Fri, 26 Dec 2014 07:48:57 +0000
Message-ID: <549D12E9.70200@lazaruscorporation.co.uk>
To: Niklas Lindström <lindstream@gmail.com>
CC: Dan Brickley <danbri@google.com>, "public-vocabs@w3.org" <public-vocabs@w3.org>
[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://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>

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://vocab.getty.edu/aat/300047896">
>
> or:
>
>     <div typeof="CreativeWork">
>         An <a property="additionalType" 
> href="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://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 
> <http://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 <http://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://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://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
>
[snip]
Received on Friday, 26 December 2014 07:49:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:46 UTC