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

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