For consistency, bookformat / BookFormatType should support audio books

[danbri]

We have a type for audio books in the bib extension:

• http://bib.schema.org/Audiobook

And we have on the Book type in schema.org core a bookFormat property whose values come from the schema.org/BookFormatType enumeration whose members are:

• http://schema.org/EBook
• http://schema.org/Hardcover
• http://schema.org/Paperback

In addition the bib extension defines http://bib.schema.org/GraphicNovel as another enumeration member.

This means that the bookFormat property can be used only with EBook, Hardcover, Paperback and GraphicNovel, but not with Audiobook. This makes things hard for implementors who need to create an entirely different special case structure for audio books.

Proposal: we add a new value to the enumeration.

Problem: do we use the same name as the existing type, or a different name? Either could be considered confusing w.r.t. usability. /cc @rvguha

I had a quick chat with @RichardWallis on this, who noted that if we use different names, the most obvious would be to call it "AudiobookFormat". However it would look a bit odd next to its sibling types. He suggested "Maybe if we added LargePrintFormat and ComicBookFormat at the same time, it wouldn’t look so bad." /cc @dbs

[chaals]

Makes more sense to me that we use the same name as the extension. Isn't that the general idea of how we expect to work with extensions?

[Dataliberate]

For that to work in our flat namespace we would have to make Audiobook a
subtype of BookFormatType (an Enumeration subtype). It is already a subtype
of both AudioObject & Book As Book has the property ‘bookFormat’ we would
end up with the situation where Audiobook could be an enumeration value for
the bookFormat of an Audiobook. - Head explodes ;-)

[danbri]

(I was implementing a strawman for review as you typed this chaals, wasn't ignoring your comment)

The issue about same-name vs different-name here isn't really about extensions. For simplicity pretend everything is still in the classic 'core'. The issue is that schema.org has two different modeling constructs which can be difficult for people to keep clear in their head.

1.) we have the notion of types: things that have members. E.g. dan and chaals are both members of the type Person. Types can have broader supertypes, and narrower subtypes. This is the main organizational structure for schema.org.

2.) we have also enumerated values, which are controlled codes for the expected values of properties. The way these are handled is that we use types to group a set of expected values like EBook, Hardcover, Paperback. However these enumerated values themselves cannot normally be used as types themselves, at least in our habits so far. It may be just fine (I think @rvguha said as much once too) but we didn't really go there. So you couldn't e.g. currently treat http://schema.org/Paperback as a type. But if we do it for Audiobook (since it is already a type thanks to the bib.schema.org effort), this creates an awkward asymmetry. I see @RichardWallis has said much the same while I was typing this.

[danbri]

Queued for review:

• http://webschemas.org/BookFormatType
• http://webschemas.org/AudiobookFormat

I also gave it a longer description than the others, "Book format: Audiobook. This is an enumerated value for use with the bookFormat property. There is also a type 'Audiobook' in the bib extension." ... to avoid confusion.

Implementor feedback: I actually tried implementing it as "Audiobook" (being simultaneously a type, and a member of BookFormatType). This just didn't work in our current codebase as far as I can see. We could doubtless fix that with some care (and python hacking and unit-test writing).

[Dataliberate]

Would extend description even a little further:

There is also a type 'Audiobook' in the bib extension, which includes Audiobook specific properties.

[danbri]

Chatting with @chaals in IRC,

danbri: Can I persuade you to live with http://webschemas.org/AudiobookFormat while we're here?
chaals: sure.

... and thanks @RichardWallis - I've amended the text as you suggest.

[danbri]

Published via http://schema.org/docs/releases.html#v3.1
http://blog.schema.org/2016/08/schemaorg-update-hotels-datasets-health.html

[danbri]

(hmm maybe that was in 3.0 actually.)