- 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