Re: BookFormatTypes

> On 21 Apr 2015, at 23:15, Wallis,Richard <Richard.Wallis@oclc.org> wrote:
> 
> As one of the original proposers of AudioBook, I have some sympathy with proposing that it be a type in its own right.  Referencing the previous discussions it probably be a combination of Book and something like MediaObject.   I will mark this one as ‘L’ deferred to a later release proposal.

OK. What needs to happen for us to move the previous work into a state where it can be added to the extension?

> 
> Ebook could be considered in a similar way.
Agreed

> 
> I don’t think this is true however for the LargePrintBook

Looking at Schema.org again I note that there is an ‘accessibilityFeature’. I’d propose this could be used for large print. The recommendation for accessibilityFeature is to use values from http://www.w3.org/wiki/WebSchemas/Accessibility. The values here include ‘largePrint’. The example at http://www.w3.org/wiki/WebSchemas/Accessibility#Example_1_.28Book.29 shows this property being used for a Book.

I think this covers the need for denoting large print books without the need for a new BookFormatType?

> , 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, I think we could set things going in the right direction.

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.

Owen

Received on Wednesday, 22 April 2015 08:42:17 UTC