- From: Paul Watson <lazarus@lazaruscorporation.co.uk>
- Date: Fri, 20 Mar 2015 14:44:23 +0000
- To: <public-vocabs@w3.org>
- Cc: Peter Krauss <ppkrauss@gmail.com>, Niklas Lindström <lindstream@gmail.com>, "Wallis,Richard" <Richard.Wallis@oclc.org>
On 2015-03-20 14:12, Wallis,Richard wrote: > ~Richard > > On 20 Mar 2015, at 13:51, Paul Watson > <lazarus@lazaruscorporation.co.uk> wrote: > >> Hi >> >> This is exactly why I thought I'd open the subject to gather some >> feedback before starting to draft up an idea! ;) >> >> Yes, it's difficult to try to place a wide collection of types such >> as Poem, Short Story, etc into the existing schema.org [1] >> structure. Poems and Short Stories can be (and frequently are) >> published online on websites and not in Books (or ebooks). And a >> Book doesn't have to be a written work (it can be a picture book) >> although obviously the vast majority of books contain writing. > > Agree > >> A list of possible test cases might include: >> >> * A short story, in the science fiction genre, published on an >> aspiring author's website (but never published in any book/ebook) >> * A modernist poem on the subject of cities, published on a poet's >> website (but also included as part of a self-published book) >> * A single chapter of a science fiction novel, published on a >> publishing company's website as a free teaser to entice people to >> buy the whole book (available in paperback and ebook) >> * A short piece of fan-fiction about the 'Harry Potter' universe, >> published on a website that specialises in hosting fan fiction >> * Shakespeare's Sonnet 18 ("Shall I compare thee to a summer's >> day?" etc) published on a website (and obviously available in many >> books) > > Most of these could be covered with the currently available types & > properties (genre, about) supplemented by Poem and Chapter types & a > form property for things like poetry, short-story, fan-fiction, etc. > >> I agree with you (Richard) about the "form" property being needed >> for more CreativeWork types - we included such a property in >> theschema.org/VisualArtwork [2] type that I drafted up and which was >> released a month-or-so ago in the form of the schema.org/artform [3] >> property. But again, I think we need to be clear about the >> difference between a "form" property (which describes the form of >> the item) and the existing "genre" property (which describes the >> content/style of the item). In your examples "self-portrait", >> "landscape", and "graffiti" are more probably covered by genre >> whereas the form properties for such examples might be "oil >> painting", "acrylic painting", "watercolour painting”. > > I hadn’t spotted it before, but several of the example values for > artForm are CreativeWork subTypes - Painting, Sculpture, Photograph > and some candidate subtypes - Print, Collage, etc. Perhaps > VisualArtWork should have been a super type for some of these. "oil > painting", "acrylic painting", "watercolour painting” seem far more > like formatTypes - similar to as as is used in BookFormatType [13]. It's an ever-present dilemma with creating schema.org Types, I think - do you subtype or do you provide what I'd call a "discriminator property" (such as schema.org/artform). Schema.org is aimed at both specialists (e.g. academia, and people with professional expertise in their areas) and generalists (e.g. someone who just wants to blog about a painting they saw while on vacation, and they'd like to mark it up correctly using schema.org). A handful of subtypes is probably enough for the generalist, but the specialist requires a *much* larger selection that, if presented as subtypes, would overwhelm schema.org with thousands of new subtypes. So for the specialist a discriminator property is probably the only viable way to go. For example, while I only provided 7 generic example values in the schema.org/artform documentation (to make it clear for the lay person what the property was for, and to encourage adoption), I use over 40 different values in schema.org/artform (all linked to the Getty AAT LOD URIs) on my website, and my website only hosts the visual artwork of 4 artists! Getty's vocabularies run to thousands of artforms. And to complicate it further, some pieces of artwork on my site have two schema.org/artform values (e.g. "collage" and "acrylic painting") to handle mixed media work. Cheers Paul > > ~Richard > >> Cheers >> >> Paul >> >> On 2015-03-20 13:40, Peter Krauss wrote: >> A note about the "taxonomy" of CreativeWork: >> * I agree that the reuse principle must be adopted when is >> possible: >> http://schema.org/Book [4] [10], http://schema.org/Article [5] [2], >> Blog, etc. >> can be reused with (or before) Poem, etc. >> * I understand that Poem, Chapter, Table, Graphic, Formula, etc. >> can >> be both: "structural part" and/or "type", >> "structural part" of a CreativeWork (Chapter of Book, Section of >> Article, etc.). Ref. NISO JATS standard (the semantic of >> verse-group, >> disp-formula, table, etc. as structural parts) >> "type" of a CreativeWork (Poem is subtype of >> CreativeWork/Literature)... Ex. Poem and Drama subtypes. >> IMPORTANT: about "structural part", there are some confusion about >> "content part" and "concrete part"... I vote to the "content view" >> over the "concrete view" of a CreativeWork... The tendency nowadays >> is >> to use the "content" as reference. See the similar dichotomy at >> "Media >> vs Content" in ISSN: >> > https://en.wikipedia.org/wiki/International_Standard_Serial_Number#Media_vs_Content >> [6] >> [11] >> PS: this personal view make sense? There are some related >> "SchemaOrg >> directives"? perhaps they are in >> http://schema.org/docs/extension.html [7] [12] >> but I not see with clarity... >> 2015-03-20 10:03 GMT-03:00 Wallis,Richard >> <Richard.Wallis@oclc.org>: >> I share the concerns that without care, this could explode in all >> directions. >> I don’t see the logic of putting something as a subType of >> Article >> just to inherit the pagination properties. >> I believe that the subdivision of CreativeWork types being >> considered here (poetry, fiction, sonnet, etc.) is somewhat >> orthogonal to the structures already in place in Schema.org [1] >> [9]. >> Are not a Book, Article, Blog, all examples of written works? >> I believe there is a need for some more CreativeWork subTypes - >> Chapter, & Poem immediately come to mind. >> I also feel that this proposal is expressing the need for something >> such as a ‘form’ property for CreativeWork which in this area >> could be used for novel, poetry, fiction, etc. I would expect that >> such a property would also be useful for other areas of >> CreativeWork >> - perhaps color, B&W, sepia, for photographs - miniature, >> self-portrait, landscape, graffiti for painting. >> ~Richard >> On 20 Mar 2015, at 11:47, <lazarus@lazaruscorporation.co.uk> >> <lazarus@lazaruscorporation.co.uk> wrote: >> On 2015-03-20 10:29, Niklas Lindström wrote: >> Hi, >> On Fri, Mar 20, 2015 at 7:01 AM, Paul Watson >> <lazarus@lazaruscorporation.co.uk> wrote: >> On 19/03/15 08:52, Anke Wehner wrote: >> On 19 March 2015 at 09:01, Paul Watson >> <lazarus@lazaruscorporation.co.uk> wrote: >> Hi >> I am thinking about proposing a new schema.org [1] [1] [1] type for > poetry, > >>> fiction, and other types of creative writing, as a subType of >>> schema.org/Article [5] [2] [2], perhaps with an additional >>> property > that can > >>> be used to classify what type of creative writing it is (e.g. > poem, > >>> haiku, sonnet, short story, fan fiction, etc.). >>> Having ways to categorise creative writing would be a good > thing, > >>> but I don't think defining them as subtype of Article makes > sense > >>> semantically. A poem, novel or movie script is not an article. >>> How about creating CreativeWork > WrittenWork, moving > wordCount, > >>> pageEnd, pageStart and pagination from Article there, and > making > >>> Article and CreativeWriting subtypes of WrittenWork? >>> Regards, >>> Anke >> I went for the least disruptive change rather than the most >> semantically correct one, but if people are happy to create >> WrittenWork and shift Article to be it's subtype then I'd be > happy > >> with that. >> So, the suggestion as it stands is to create a new type of >> WrittenWork as a subtype of Article; move wordCount, pageEnd, >> pageStart and pagination from Article to it's new parent > WrittenWork, > >> then create a new subtype of WrittenWork called CreativeWriting, > with > >> at least one new property (currently unnamed) that can be used > to > >> classify what type of creative writing it is (e.g. poem, haiku, >> sonnet, short story, fan fiction, etc.). Or should we take the >> opportunity to create some subtypes of CreativeWriting while > we're > >> doing this (e.g. Poem, Story, Script, etc.) instead of using a > new > >> property of CreativeWriting to classify the type? >> These seem like (bibliographic) questions I would like to > involve the > >> SchemaBibEx CG [1] in. There is a dedicated mailing list [2] > where we > >> could go into depth on this, unless all feel comfortable hashing > out > >> the options here. (I did not CC the schemabibex group in this > reply.) > >> My spontaneous reaction is that there may be some need for a > subtype > >> for textual works. But I am wary about making it vaguely limited > to > >> "creative" forms (if "creative" here implies excluding > non-fiction, > >> academic essays and such). Anke's basic WrittenWork might be > enough. > >> The specific nature of the text can probably be given using >> http://schema.org/genre [8] [3] [3] (provided a resolution to >> schema > issue 346 > >> [3]) in combination with external enumerations? (See e.g. "genre > in > >> literature" on wikipedia [4] for the motivation to use genre.) > Compare > >> that to the newly introduced property http://schema.org/artform [3] > [4] [4], > >> which (as I previously suggested) might be extended to include > other > >> forms of expression. (To me, it bears a resemblance to genre, > perhaps > >> even being a subproperty thereof.) >> In any case, the multitude of nature-specific subclasses of >> WrittenText can explode just as with specific kinds of > VisualArtwork > >> (which was the motivation for introducing artwork as opposed to > using > >> multiple types directly). I'd really like experienced library > folks to > >> chime in, and that we avoid the introduction of anything overly >> specific here. >> Cheers, >> Niklas >> [1]: https://www.w3.org/community/schemabibex/ [9] [5] [5] >> [2]: http://lists.w3.org/Archives/Public/public-schemabibex/ [10] >> [6] > [6] > >> [3]: https://github.com/schemaorg/schemaorg/issues/346 [11] [7] [7] >> [4]: http://en.wikipedia.org/wiki/Genre#Literature [12] [8] [8] > I'd be very grateful for the experienced library folks to chime > in! > I think we've got to be careful about being confused between form > (e.g. the artform property of VisualArtwork or a new property for > the proposed new type for potery/fiction) and genre. > The former is about the form of the content (for VisualArtwork: > Acrylic Painting, Oil Painting, Drawing, Woodcut), whereas genre > is about the subject matter of the content (Landscape painting, > studio portrait, street scene). > This is probably even more apparent for written works where the > new 'type' property would hold values such as "short story", > "novel", "novella", "Poem", "haiku" (relating to the form of the > written work), while the existing genre property inherited from > CreativeWork would be for the genre of the content of the written > work: "Science Fiction", "Fantasy", "Romance", "Horror", "Literary > Fiction" etc. > Cheers > Paul > >>>>> Links: > ------ > [1] http://schema.org [1] [1] > [2] > http://schema.org/Article [5] [2] > [3] http://schema.org/genre [8] > [3] > > [4] http://schema.org/artform [3] [4] > [5] > https://www.w3.org/community/schemabibex/ [9] [5] > [6] > http://lists.w3.org/Archives/Public/public-schemabibex/ [10] [6] > > [7] > https://github.com/schemaorg/schemaorg/issues/346 [11] [7] > [8] > http://en.wikipedia.org/wiki/Genre#Literature [12] [8] > Links: > ------ > [1] http://schema.org [1] > [2] http://schema.org/Article [5] > [3] http://schema.org/genre [8] > [4] http://schema.org/artform [3] > [5] https://www.w3.org/community/schemabibex/ [9] > [6] http://lists.w3.org/Archives/Public/public-schemabibex/ [10] > [7] https://github.com/schemaorg/schemaorg/issues/346 [11] > [8] http://en.wikipedia.org/wiki/Genre#Literature [12] > [9] http://Schema.org [1] > [10] http://schema.org/Book [4] > [11] > > https://en.wikipedia.org/wiki/International_Standard_Serial_Number#Media_vs_Content > [6] > [12] http://schema.org/docs/extension.html [7] > > > Links: > ------ > [1] http://schema.org/ > [2] http://schema.org/VisualArtwork > [3] http://schema.org/artform > [4] http://schema.org/Book > [5] http://schema.org/Article > [6] > https://en.wikipedia.org/wiki/International_Standard_Serial_Number#Media_vs_Content > [7] http://schema.org/docs/extension.html > [8] http://schema.org/genre > [9] https://www.w3.org/community/schemabibex/ > [10] http://lists.w3.org/Archives/Public/public-schemabibex/ > [11] https://github.com/schemaorg/schemaorg/issues/346 > [12] http://en.wikipedia.org/wiki/Genre#Literature > [13] http://schema.org/BookFormatType
Received on Friday, 20 March 2015 14:44:53 UTC