W3C home > Mailing lists > Public > public-vocabs@w3.org > August 2014

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

From: Yves Raimond <yves.raimond@gmail.com>
Date: Tue, 12 Aug 2014 11:25:26 +0100
Message-ID: <CAA2+3G+sSajw-k2FVs-Rb2iMnA1Qdb8Kxvp=swqabWiY=AabaA@mail.gmail.com>
To: Dan Brickley <danbri@danbri.org>
Cc: David Marland <david.marland@bbc.co.uk>, public-vocabs <public-vocabs@w3.org>, Richard Wallis <Richard.Wallis@oclc.org>, Jean-Pierre Evain <evain@ebu.ch>, Dan Scott <denials@gmail.com>
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?


> 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]
> [3]
> [4] http://lists.w3.org/Archives/Public/public-vocabs/2012Aug/0033.html
Received on Tuesday, 12 August 2014 10:25:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:49:34 UTC