Re: extensions and expected values

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

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.

But when it comes to making effective use, the existing documentation 
doesn't fill in all the gaps. Some examples in schema.org don't use the 
expected types to express information, for example (author names as strings 
instead of Person types), but is it more or less bad from a search 
perspective to work around unknowns?

Matt

-----Original Message----- 
From: Karen Coyle
Sent: Friday, July 26, 2013 9:51 AM
To: public-vocabs@w3.org
Subject: Re: extensions and expected values

Matt, the Bibliographic group is close to a proposal on audiobook [1].
We were thinking of using "playerType" from audioObject. Whatever
solution you select (because it is more important for accessibility) we
should probably incorporate by sub-classing.

kc
[1] http://www.w3.org/community/schemabibex/wiki/Audiobook


On 7/26/13 5:44 AM, Matt Garrish wrote:
> Hello folks,
> A couple of questions which I hope aren’t too naive, but between reading
> this list and what documentation exists, it’s not always clear what best
> practices are for schema.org.
> First, should we (the accessibility metadata group) be recommending that
> people use the “/” extension mechanism for accessible book formats like
> EPUB and DAISY. The extension page notes
> “http://schema.org/EBook/KindleFormat” as an extension of the
> bookFormatType enumeration, but is that URI syntax expected to last?
> Should we instead recommend using a more basic string like “DAISY3” or
> “EPUB3” to avoid future problems, or is the use of string values with
> bookFormat problematic in itself? Recent discussions on this list have
> cast some doubts.
> And that leads to the other question we have, which is what to do when a
> needed data type doesn’t have an exact match in schema.org? If you have
> adapted a work to make it accessible and want to note that it is an
> adaptation of another, should we indicate an expected value of URL even
> though a URI is wanted, since URNs may be the only usable identifiers?
> In other words, is usage context more important than the expected value?
> For example, if I use link/@href <mailto:link/@href> for URLs and
> meta/@content <mailto:meta/@content> for URNs, does it matter that the
> expected value is URL because it’s expected that most adaptations will
> have a referenceable source on a publisher’s site?
> Thanks in advance for any insights that can be provided,
> Matt

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Received on Monday, 29 July 2013 20:03:15 UTC