Re: BookFormatTypes

> On 22 Apr 2015, at 16:00, Dan Scott <denials@gmail.com> wrote:
> 
> On Wed, Apr 22, 2015 at 4:41 AM, Owen Stephens <owen@ostephens.com <mailto:owen@ostephens.com>> wrote:
> > On 21 Apr 2015, at 23:15, Wallis,Richard <Richard.Wallis@oclc.org <mailto:Richard.Wallis@oclc.org>> wrote:
> <snip>
>  
> > , PrintBook, not seeing any property needs that that would warrant a specific type.
> 
> PrintBook - The most obvious property that a print book has that audiobooks and ebooks don’t is number of pages. Schema.org smushed numberOfPages into ‘Book’ which works only if you assume ‘print’ is the default medium for a book. We can’t directly fix this in the extension but in terms of potential future adoption of work we do in the extension into core schema.org <http://schema.org/>, I think we could set things going in the right direction.
> 
> Hmm. Many ebooks have page numbers. It seems like a perfectly valid property to have at the Book level.

Yeah - weird right? :)
Page numbers are a bit fluid in ebooks (or can be) and often are included in order to reflect the same property of the printed equivalent.
But yes - I’m happy to accept this as a weird real world practice we need to cope with and so numberOfPages has to exist at Book level.

>  
> Even without the numberOfPages there are properties that would only be relevant to a physically printed item - information about the binding, printing format (e.g. folio, octavo), dimensions. This is information traditionally recorded in cataloguing, and has specific relevance for certain types of collection where the printed form is of interest to users (e.g. early printed books)
> 
> Finally given that we agree we should have an Ebook type, this would leave the useful members of the BookFormatType values as ‘Hardcover’ and ‘Paperback’ - which are also properties of the printed book only.
> 
> New types don't need to have distinct properties. There are plenty of types in core schema.org <http://schema.org/> that don't add new properties. For example, https://schema.org/NGO <https://schema.org/NGO> and https://schema.org/GovernmentOrganization <https://schema.org/GovernmentOrganization> both derive from https://schema.org/Organization <https://schema.org/Organization> without adding any new properties.
> 
> Presumably this is so because it makes it more convenient for the consumer to identify the type of resource being described, and for the publisher to get the markup right--particularly inline markup such as RDFa or microdata, where you would need to add in a <link property="bookFormatType" href="http://schema.org/GraphicNovel <http://schema.org/GraphicNovel>">, rather than simply declaring <div typeof="GraphicNovel">.
> 
> I'm happy to go either way with GraphicNovel. I went with the BookFormatType enumeration because there was precedent in core schema.org <http://schema.org/> and Richard had the other three types proposed. I just want to have some way of reliably identifying graphic novels.

Agree with all this and the need to be able to reliably identify graphic novels. So questions:

Is this better done via a Type or a Property
If via a Property, what Property, and what is the range of that Property?

It strikes me that BISAC Subject Headings might provide a way of doing this -https://www.bisg.org/bisac-subject-headings-list-comics-and-graphic-novels

Would having a Property for BISAC Subject Headings work (which opens up the question of subject headings in general I guess)

Owen