- From: Aaron Bradley <aaranged@gmail.com>
- Date: Mon, 26 Jan 2015 12:51:17 -0800
- To: Public Vocabs <public-vocabs@w3.org>
- Cc: Dan Brickley <danbri@google.com>
- Message-ID: <CAMbipBtp5q7dx3=RGrBT5F2QMusz35TQOgsaeN2fqYggQnjD=Q@mail.gmail.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 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://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