Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
For consistency, bookformat / BookFormatType should support audio books #1081
We have a type for audio books in the bib extension:
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:
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
For that to work in our flat namespace we would have to make Audiobook a
(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.
Queued for review:
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).