revisiting 'position', 'episodeNumber', 'seasonNumber' modeling and Periodicals

Hello TV/Radio schema people! David in particular re BBC usage, also
Jean-Pierre and Yves regarding the original design. We're looking for
any advice you can offer on a related schema for periodicals, based on
the TV/Radio experience.

I've been talking with Richard Wallis, Dan Scott, schema.org
colleagues and others this last week. It looks like we are very nearly
done with the Periodicals (journals etc.)  bibliographic extension for
schema.org [2].  The last concern is that it has a couple of proposed
properties that are similar to constructs already used for TV/Radio,
as well as proposed for Music. (All these things touch on the ItemList
discussion too, but I would rather leave that aside for now.)

I've collected an overview together [3] where Dan, Richard and I have
been exploring options and issues.

Schema.org for TV/Radio currently has 'episodeNumber', 'seasonNumber'
whose values are defined to always be an Integer, alongside a
'position' property whose values are more flexible. A very similar
issue occurs in bibliographic datasets, where strings like 'iii' are
quite commonly mixed in.

Dan Scott comments in [3] that  "It would be nice if periodicals were
consistent on this front but even periodicals that are normally
consistent about numeric identifiers will occasionally end up
combining issues, e.g. "3-4", or publishing "Summer special 2003", and
other such creative approaches. Having *Number have a Number range,
resulting in issueNumber "1", "2" then position "3-4", then back to
issueNumber "5" isn't going to help ordering at all and will just make
both publishing and consuming harder."

The TV/Radio design was discussed here 2 years ago [4]. At the time,
the wish was for "position" as a kind of overflow property, so that
'episodeNumber' and 'seasonNumber' could stay purely numeric and we
use "position" for non-numeric cases. However I can't help noticing
that the usage on the BBC site seems to support Dan's observation that
a single property might be more publisher friendly.

It's also worth noting that at least in RDFa and JSON-LD, local
datatyping can be used if needed so that a single property that
accepts both strings and numbers can still be used unambiguously. The
BBC site does this with RDFa, but JSON-LD also makes a distinction
between e.g.

a)   "issueNumber": 9734 and
b) "issueNumber": "9734".

We're trying in [3] to bring the Periodicals proposal closer to
TV/Radio's model, but I wanted to check back to see how people feel
post-deployment re TV/Radio. Is there any implementor feedback on the
"position" (Text), "episodeNumber"(Integer) distinction that can help
guide our decisions on Periodical?

One model to consider would be to liberalize all these properties to
allow the possibility of non-integer values, while noting that JSON-LD
and RDFa datatyping could be used for extra precision when needed. We
could also perhaps consider "position" to be a common super-property.

Thanks for any thoughts,

Dan


[1] http://www.bbc.co.uk/tv/programmes/genres/factual/schedules/2013/11/25
e.g. <span property="position" datatype="xsd:int">3</span>

[2] https://www.w3.org/wiki/WebSchemas/Periodicals,_Articles_and_Multi-volume_Works

[3] https://docs.google.com/a/danbri.org/document/d/15xWBPGdygMicCCzMw7D0JzgqXMRSTeTKoGohl1HK5oE/edit?usp=sharing

[4] http://lists.w3.org/Archives/Public/public-vocabs/2012Aug/0033.html

Received on Monday, 11 August 2014 18:07:56 UTC