For consistency, bookformat / BookFormatType should support audio books #1081

Closed
danbri opened this Issue Apr 6, 2016 · 8 comments

Projects

None yet

3 participants

@danbri
Contributor
danbri commented Apr 6, 2016

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

@chaals
Contributor
chaals commented Apr 6, 2016

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?

@danbri danbri pushed a commit that referenced this issue Apr 6, 2016
Dan Brickley Added Audiobook as a BookFormatType enumeration.
For #1081
7acf4ee
@danbri danbri pushed a commit that referenced this issue Apr 6, 2016
Dan Brickley AudiobookFormat addition noted, for #1081. 2e6b52b
@Dataliberate
Contributor

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
Contributor
danbri commented Apr 6, 2016

(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
Contributor
danbri commented Apr 6, 2016

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

@Dataliberate
Contributor

Would extend description even a little further:

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

@danbri
Contributor
danbri commented Apr 6, 2016

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 danbri self-assigned this Apr 6, 2016
@danbri danbri closed this Aug 10, 2016
@danbri
Contributor
danbri commented Aug 10, 2016

(hmm maybe that was in 3.0 actually.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment