Re: BookFormatTypes

On Wed, Apr 22, 2015 at 11:15 AM, Owen Stephens <owen@ostephens.com> wrote:

>
> On 22 Apr 2015, at 16:00, Dan Scott <denials@gmail.com> wrote:
>
>
<snip>


> 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 that don't add new properties. For example,
> https://schema.org/NGO and https://schema.org/GovernmentOrganization both
> derive from 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">, 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
> 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 we're open to adding new types, then making GraphicNovel derive from
Book rather than BookFormatType would be fine with me. Certainly simplifies
the consuming & publishing process.


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

I'm not comfortable with relying on BISAC SH for resolving this; they mix
descriptions of subject matter, intended audience, etc with the format
(e.g. BIB016010 -- BIBLES / New Revised Standard Version / Children).


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

If one wants to use BISAC SH to describe a work, I believe the best
practice is to use schema:about with a reference to the appropriate subject
heading URL. That said, I don't think BISAC has published their
classifications as linked data; I can't find anything with a quick search,
anyway; so that's a bit unfortunate. See also the mini-SKOS in schema.org
proposal.

In any case, I don't see a need for a new property.