Re: extensions and expected values

Thanks, Dan! The answers you gave below are extremely helpful.

I'll definitely be looking into the schemabibex work.

Matt

-----Original Message----- 
From: Dan Scott
Sent: Monday, July 29, 2013 4:49 PM
To: Matt Garrish
Cc: kcoyle@kcoyle.net ; public-vocabs@w3.org ; Graham Bell
Subject: Re: extensions and expected values

On Mon, Jul 29, 2013 at 03:59:38PM -0400, Matt Garrish wrote:
> Hi Karen,
>
> Thanks for sharing that proposal; finding everything that is going
> on in schema.org is also not easy. It does raise another question we
> had, which was whether to extend bookFormatType for audio books,
> braille books, etc. (e.g., is Paperback/Braille an accurate
> presentation of a print braille book, given the three existing
> types).

First, the "/" extension approach is pretty much deprecated, but it's
not clear if there is any officially blessed replacement for it yet.
It's a bit confusing that it's still the documented approach on the
schema.org site; I suppose the "you can always create new schemas that
are not at all tied to those on schema.org" statement being repeated on
that page is a subtle hint :)

Second, as BookFormatType is an Enumeration, and
http://schema.org/docs/gs.html#advanced_enum says "[an enumeration is a
property that can take only a limited set of possible values]", so it
sounds like you might need to argue for additions to the options
http://schema.org/BookFormatType - or to change
http://schema.org/bookFormat to point to an external enumeration,
instead.

> As you likely know, the flexibility of the DAISY formats
> means that publications can take the form of text-only ebooks,
> structured audiobooks, or some combination of both (and now EPUB 3
> allows similar production), so the formats could be extensions of
> both ebooks and audiobooks. These are some of the grey areas of
> metadata application, of course.
>
> I don't speak for the group, but my concern with going by the player
> is that there can be many players that can play open formats like
> DAISY and EPUB (excluding the DRMed walled gardens, of course). When
> searching for accessible formats, there are fewer of them than there
> are players that can play them, which is why people often look by
> format.

The first AudioBook example in the Schema BibExtend wiki used
http://schema.org/playerType because the source markup contained a
declaration along those lines, and we're inheriting from
http://schema.org/AudioObject and hey, why not mark up what you can?
I agree with your concern, though, and _think_ that
http://schema.org/encodingFormat could be more useful for your goal.
But perhaps the expected type of "Text" (and the joys of string
matching) makes that less likely to be useful in practice.

> We're trying to make the most effective use of the existing
> properties in conjunction with the defining access modes, accessible
> media features, etc. to ideally enable users to search for content
> more suitable to their needs, and avoid the current problem of
> having to investigate all search results to find appropriate
> content.

I've been wondering if publishing an enumeration that tracks the ONIX
"Product Form Detail" list[1] and pointing http://schema.org/bookFormat
at that, instead, might be a reasonable alternative to trying to teach
schema.org about all the different possible book formats and keeping it
up to date. (CCing Graham Bell of EDItEUR to see if they have any plans
of publishing the ONIX codelists as linked data themselves)

Matt, please join us in the Schema Bib Extend Community Group [2] where
we're working out schema.org extension proposals for bibliographic
information; your experience and interest would be a great asset!

1. 
http://www.editeur.org/files/ONIX%20for%20books%20-%20code%20lists/ONIX_BookProduct_CodeLists_Issue_22.html#codelist78
2. http://www.w3.org/community/schemabibex/

Received on Thursday, 1 August 2013 01:25:28 UTC