- From: Paul Watson <lazarus@lazaruscorporation.co.uk>
- Date: Sun, 28 Dec 2014 10:15:51 +0000
- To: Niklas Lindström <lindstream@gmail.com>
- CC: Dan Brickley <danbri@google.com>, "public-vocabs@w3.org" <public-vocabs@w3.org>
- Message-ID: <549FD857.7000505@lazaruscorporation.co.uk>
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 >> <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 Sunday, 28 December 2014 10:16:19 UTC