Re: BookFormatTypes

On 22 Apr 2015, at 09:41, Owen Stephens <owen@ostephens.com> wrote:

>> 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?

I’m working on a Wiki page for bib.schema 1.1 which I’ll move unresolved for 1.0 issues to.  We can then start a separate thread on once we’ve got this first release out of the door.

> 
>> 
>> 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?

I think you are right - I’ll defer this as a place holder on to 1.1 - resolution will probably only need an example creating.

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

Again I think we need to defer this one to 1.1 and discuss further the subtleties of the differences in approaches.

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

Remembering that all properties are optional I don’t see that being a particular issue

~Richard.

Received on Wednesday, 22 April 2015 10:02:20 UTC