W3C home > Mailing lists > Public > public-vocabs@w3.org > January 2015

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

From: Aaron Bradley <aaranged@gmail.com>
Date: Mon, 26 Jan 2015 12:51:17 -0800
Message-ID: <CAMbipBtp5q7dx3=RGrBT5F2QMusz35TQOgsaeN2fqYggQnjD=Q@mail.gmail.com>
To: Public Vocabs <public-vocabs@w3.org>
Cc: Dan Brickley <danbri@google.com>
Quick note that one of the microdata examples for schema.org/VideoGame
contains RDFa syntax.

The "Monopoly" example has this for microdata:
<body vocab="http://schema.org/" itemscope itemtype="
http://schema.org/VideoGame http://schema.org/MobileApplication">

This should simply read:
<body itemscope itemtype="http://schema.org/VideoGame

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://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://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 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://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 Monday, 26 January 2015 20:51:44 UTC

This archive was generated by hypermail 2.3.1 : Monday, 26 January 2015 20:51:46 UTC