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

Hello Dan,

On 11 Aug 2014 20:07, "Dan Brickley" <danbri@danbri.org> wrote:
>
> 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".
>

That would be a good option imho - a single 'position' property which does
not enforce a datatype.

Just out of curiosity,  do you know how often publishers mix the two
properties (my guess would be that this almost never happens), and which
one is used the most?

Best,
Yves

> 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