Re: Proposed new Schema.org type for poetry and fiction

On Fri, Mar 20, 2015 at 3:44 PM, Paul Watson <
lazarus@lazaruscorporation.co.uk> wrote:

> 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.
>

Forming a coherent approach for this was what I was aiming for [1] when the
artform, material and surface properties were introduced on VisualArtwork.
The existing genre property also overlaps in some ways (seen as
"technique"), if you consider how it is used for written text versus in the
wikipedia article I linked to above [2] (e.g. there, Poem and Novella are
"genres" in literature). Just as genre can be confused with form, so can
genre be confused with subject matter.

The content/form dichotomy sometimes breaks down when you look at certain
kinds of expression. Using multiple types is the coarse-grained,
good-enough approach. But I agree that discriminatory properties can be
useful. Not for each specific subclass of CreativeWork though. An approach
inspired by e.g. bibliographic notions of content/media/carrier might be
more useful (though it has historical baggage which we may avoid here).

Defining reusable properties for "kind of content" (genre?), "kind of form"
(artform? multiple types including external enumerations?) and "kind of
material" (material?, perhaps to supersede bookFormat?) could solve this
coherently across all creative works.

Let's avoid defining very specific properties for books, other texts,
visual art, music, performances, movies, games etc. I think we can identify
the shared need across these (for discriminating aspects of content/form),
consolidate what we have, move properties up the class hierarchy if
possible, and then, maybe, introduce some normalizing types to gather the
current jumble of CreativeWork subclasses.

Cheers,
Niklas

[1]: http://lists.w3.org/Archives/Public/public-vocabs/2014Dec/0115.html
[2]: http://en.wikipedia.org/wiki/Genre#Literature



> 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
>>
>
>