- From: Paul Watson <lazarus@lazaruscorporation.co.uk>
- Date: Tue, 26 Aug 2014 21:40:16 +0100
- To: Jarno van Driel <jarnovandriel@gmail.com>, W3C Web Schemas Task Force <public-vocabs@w3.org>
- Message-ID: <53FCF0B0.5040806@lazaruscorporation.co.uk>
Apologies for the slight delay. I've added an example VRA 4.0 XML record that uses the Getty AAT structured vocabulary to the wiki. I've only done it for one of the existing examples (the Magritte painting) after the Microdata, RDFA, and JSON-LD examples. I have missed out a lot of the VRA elements to just concentrate on the elements that map to the new properties proposed for the VisualArtwork type. Direct link to the VRA example on the wiki: https://www.w3.org/wiki/WebSchemas/VisualArtwork#VRA_4.0_XML_using_Getty_AAT_structured_vocabulary In this example: * <work> -> <worktypeSet> -> <worktype> maps to VisualArtwork->artform * <work> -> <materialSet> -> <material type="medium"> maps to VisualArtwork->materials * <work> -> <materialSet> -> <material type="support"> maps to VisualArtwork->surface In hindsight this was a slightly confusing example due to the similarity between the name of the artform (oil painting) and the materials (oil paint), but they are completely separate entries in the Getty structured vocabulary - the former being part of the Visual Works hierarchy of the Objects Facet (used to describe art forms) and the latter being part of the Materials facet and hierarchy (used to describe materials). Other combinations (e.g. "Lithograph" as the artform/worktype, and "Printing ink" as the material) would show that the artform and the material aren't interchangeable names! Regards, Paul On 20/08/14 22:58, Jarno van Driel wrote: > "but I'll try to get some examples of mappings (or at least better > explanations of them)" > > Thanks! > > Oh and one more thing: > > <div itemscope itemtype="http://schema.org/Book"> > <span itemprop="genre">Science fiction</span> > [...] > </div> > > could also be: > > <div itemscope itemtype="http://schema.org/Book"> > <link itemprop="genre" href="https://www.freebase.com/m/06n90"> > [...] > </div> > > As: "it's fine to include just regular text or a URL" > (http://schema.org/docs/gs.html#schemaorg_expected). > > > 2014-08-20 22:29 GMT+02:00 Paul Watson > <lazarus@lazaruscorporation.co.uk > <mailto:lazarus@lazaruscorporation.co.uk>>: > > On 20/08/14 13:23, Jarno van Driel wrote: >> >> "This enables a wide range of types of book to be marked up >> without the need to maintain a lot of new subClasses, and is >> my preferred option as it allows easier mapping to other >> systems such as CDWA, VRA CORE, etc." >> >> >> Agreed that this does help keep it a lot simpler. I guess it >> depends on deciding how far schema.org <http://schema.org> should >> go in being able to express granularity. And let me be clear, I >> don't mind if it's decided that 'artform' is sufficient enough >> for this and that further specification isn't wanted/needed. As >> long as this is a clear decision. > > And I very much value your input (all of which have been > completely valid design considerations) - the more discussion and > analysis this proposal gets, the better the final VisualArtwork > type will be. > >> >> "By using the artform property (which galleries and museums >> would probably populate from one of the existing controlled >> vocabularies)..." & "and is my preferred option as it allows >> easier mapping to other systems such as CDWA, VRA CORE, etc." >> >> >> If it's not too much to ask, could you please provide an example >> that shows how one can go about and map this to something like >> CDWA, VRA CORE, etc? I'd love to know how you'd go about this and >> maybe it also could be of value as an example on schema.org >> <http://schema.org> itself. >> >> > > I'm at a training course away from home until the weekend, but > I'll try to get some examples of mappings (or at least better > explanations of them) posted on the wiki page by Monday evening if > I can, and will post to this list when I've done so. > > I agree that documentation like that is important. I think content > publishers (I'm including myself here!) need a lot more of that > sort of explanation/documentation of how they can use schema.org > <http://schema.org> beyond the basic "follow these steps to get > rich snippets in Google" SEO articles which, while useful, are > quite basic. I'd love to see more resources on extending > schema.org <http://schema.org> with Good Relations, > Productontology, etc. and other more advanced use cases. I've > learnt a lot by being on this list for the past 18 months, but I > feel that I've barely scraped the surface (and it would be nice to > have everything indexed by topic on a website somewhere). > > Paul > > > >> >> >> >> >> 2014-08-20 6:57 GMT+02:00 Paul Watson >> <lazarus@lazaruscorporation.co.uk >> <mailto:lazarus@lazaruscorporation.co.uk>>: >> >> On 19/08/14 22:35, Jarno van Driel wrote: >>> >>> "maintenance would be a nightmare and we'd have a >>> constant stream of new subClasses being proposed" >>> >>> >>> If hundreds are to be added than I'd consider this to be a >>> very valid point of view. But is really to be expected? >>> The same thing has been brought up about Organization and >>> it's subClasses as well but somehow there aren't a lot of >>> requests for new subClasses of Organization coming through >>> here. Something I think a property like 'additionalType' >>> helped prevent. Especially for those types which don't need >>> new properties. For those [Organization > additionalType > >>> Productontology] works quite satisfactory. >> >> That's one way of doing it. The other is to the take example >> of schema.org/Book <http://schema.org/Book> which has a genre >> property which accepts a text string instead of having a >> plethora of subClasses such as ScienceFictionBook, >> FantasyBook, Romance, LiteraryFictionBook, Western, Thriller, >> ReferenceBook, Textbook, Biography, etc. This enables a wide >> range of types of book to be marked up without the need to >> maintain a lot of new subClasses, and is my preferred option >> as it allows easier mapping to other systems such as CDWA, >> VRA CORE, etc. >> >> >>> >>> So if acceptance of new subClasses of VisualArtwork would be >>> limited to those that need additional values, wouldn't that >>> help keep the amount of types needed/expected reasonable? >> >> I'd note that the existing Painting and Sculpture types don't >> have any additional properties, so what would be the premise >> for having them as subClasses? >> >> >>> >>> "They served a purpose in the past, but I think that >>> their purpose has been superseded and are probably due >>> for retirement." >>> >>> >>> Oh, that very well could be, I haven't got any numbers at my >>> disposal which show if these two types are published a lot >>> or not. That's something I don't dare to burn my fingers on. >>> But maybe somebody else, who does have access to those kinds >>> of numbers (let's say one of the sponsors for example) could >>> provide some info to help decide whether depreciation is a >>> valid option or not. ? >> >> Certainly some numbers would help! >> >> >> >>> >>> >>> 2014-08-19 22:54 GMT+02:00 Paul Watson >>> <lazarus@lazaruscorporation.co.uk >>> <mailto:lazarus@lazaruscorporation.co.uk>>: >>> >>> On 19/08/14 21:20, Jarno van Driel wrote: >>>> >>>> "My immediate feeling is that the existing Painting >>>> and Sculpture types should be marked as deprecated >>>> somehow " >>>> >>>> >>>> The only thing about this proposal that really makes me >>>> feel uncomfortable is the 'artform' property. It >>>> already has been established it's a VisualArtwork, >>>> which by itself already is a classification. >>>> >>>> Maybe we therefore could continue on the path of >>>> 'Classification' by having Painting and Sculpture be >>>> subClasses of VisualArtwork? >>>> This would also open up the possibility of adding more >>>> specific types like Collage for example. Which would >>>> need a property/Value pair like: >>>> [sourceMaterial/CreativeWork] (and I can come up with >>>> two or three more easily). >>>> >>>> Using 'additionalType' for further classification seems >>>> a bit too limited for this. Not that there's anything >>>> wrong with using Productontology of course but it would >>>> not provide any additional/specific properties. And I >>>> know from experience that different artforms quickly >>>> require such granularity. >>>> >>>> The following use of 'artform > painting' just doesn't >>>> make sense to me: >>>> >>>> <div itemscope itemtype="http://schema.org/VisualArtwork"> >>>> <link itemprop="sameAs" >>>> href="http://rdf.freebase.com/rdf/m.0439_q"> >>>> <span itemprop="artform">painting</span> >>>> [...] >>>> <div> >>>> >>>> Yet we also have schema.org/Painting >>>> <http://schema.org/Painting> (& Sculpture & anything >>>> else that's requested in the future), which as a >>>> subClass would prevent anything from having to be >>>> deprecated and keeping current implementations valid. >>>> Heck, it would even require less markup: >>>> >>>> <div itemscope itemtype="http://schema.org/Painting"> >>>> <link itemprop="sameAs" >>>> href="http://rdf.freebase.com/rdf/m.0439_q"> >>>> [...] >>>> <div> >>> >>> Hi Jarno, >>> >>> My main concern about that suggestion is a practical >>> one: I can think of 30-40 different types of artform >>> we'd need to create subClasses for off the top of my >>> head (and I could list hundreds more if I start >>> referring to the Getty CDWA or VRA Core) - maintenance >>> would be a nightmare and we'd have a constant stream of >>> new subClasses being proposed on this list for be added >>> to schema.org <http://schema.org>. >>> >>> By using the artform property (which galleries and >>> museums would probably populate from one of the existing >>> controlled vocabularies) we prevent an explosion of >>> hundreds of new subClasses whilst still allowing the >>> degree of precise classification that galleries and >>> museums (and artists like myself) need. >>> >>> I did consider your proposed approach back in early 2013 >>> when I was formulating my ideas, and I alluded to it in >>> my original email to this list proposing the >>> VisualArtwork type in May 2013 >>> (http://lists.w3.org/Archives/Public/public-vocabs/2013May/0024.html): >>> >>> "As you can see, rather than having many different subTytpes of Creative work for paintings, sculptures, prints, drawings, collages, tapestry, etc, the VisualArtwork proposal allows the artform to be designated under the new "artform" property." >>> >>> Also, having Painting and Sculpture as subClasses of >>> VisualArtwork seems to me like keeping them for the sake >>> of it - they don't have any additional properties >>> over-and-above VisualArtwork. They served a purpose in >>> the past, but I think that their purpose has been >>> superseded and are probably due for retirement. >>> >>> Regards, >>> >>> Paul >>> >>> >>>> >>>> >>>> *Jarno van Driel* >>>> Digital Marketing Technologist >>>> >>>> Tel: +31 652 847 608 >>>> Google+: https://plus.google.com/u/0/+JarnovanDriel >>>> Linkedin: linkedin.com/pub/jarno-van-driel/75/470/36a/ >>>> <http://linkedin.com/pub/jarno-van-driel/75/470/36a/> >>>> >>>> >>>> 2014-08-19 21:25 GMT+02:00 Thad Guidry >>>> <thadguidry@gmail.com <mailto:thadguidry@gmail.com>>: >>>> >>>> Hey Dan, >>>> >>>> My main concerns about mixing VisualArtwork with >>>> PeriodicalSeries. (So I was suggesting yet another >>>> type...but...) >>>> >>>> In Freebase, we would probably throw a Incompatible >>>> Type Error when one is asserted against the other. >>>> In Schema.org, we do not have that luxury, and have >>>> hints and definitions to help developers make the >>>> right assertions during Multi-Typing. >>>> >>>> I agree that there are some "Artwork" attributes >>>> that need to be available to developers when >>>> dealing with ComicIssue. >>>> I disagree that there are some "VisualArtwork" >>>> attributes (as currently proposed) when dealing >>>> with ComicIssue. >>>> >>>> There is the distinction and fine line that I am >>>> drawing, but perhaps others do not share my >>>> distinction and have no worries. >>>> >>>> I would like to see VisualArtwork reserved to help >>>> me cut through the weeds later on against other >>>> Types. (hence my concern with someone Multi-Typing >>>> those two if we do not have some warning or good >>>> definition boundaries set) >>>> >>>> >>>> On Tue, Aug 19, 2014 at 1:43 PM, Dan Scott >>>> <dan@coffeecode.net <mailto:dan@coffeecode.net>> wrote: >>>> >>>> On Tue, Aug 19, 2014 at 12:41:51PM -0500, Thad >>>> Guidry wrote: >>>> >>>> My opinion is that many things are >>>> "Collectable" as artwork, i.e., "they >>>> are appreciated as having artistic value to >>>> the owner/seller." >>>> >>>> >>>> Well, yes, pretty much everything could be >>>> considered collectable. I >>>> don't think that's the core set of attributes >>>> to worry about with >>>> comics. >>>> >>>> >>>> >>>> >>>> -- >>>> -Thad >>>> +ThadGuidry <https://www.google.com/+ThadGuidry> >>>> Thad on LinkedIn >>>> <http://www.linkedin.com/in/thadguidry/> >>>> >>>> >>> >>> >>> >> >>
Received on Tuesday, 26 August 2014 20:40:46 UTC