New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

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

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

This comment has been minimized.

Show comment
Hide comment
@chaals

chaals Apr 6, 2016

Contributor

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?

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?

@Dataliberate

This comment has been minimized.

Show comment
Hide comment
@Dataliberate

Dataliberate Apr 6, 2016

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

Contributor

Dataliberate commented Apr 6, 2016

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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Apr 6, 2016

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Apr 6, 2016

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@Dataliberate

Dataliberate Apr 6, 2016

Contributor

Would extend description even a little further:

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

Contributor

Dataliberate commented Apr 6, 2016

Would extend description even a little further:

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

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Apr 6, 2016

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Aug 10, 2016

Contributor

(hmm maybe that was in 3.0 actually.)

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