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

Hello Dan,

On 11 Aug 2014 20:07, "Dan Brickley" <> 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,
> colleagues and others this last week. It looks like we are very nearly
> done with the Periodicals (journals etc.)  bibliographic extension for
> [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.
> 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]
> e.g. <span property="position" datatype="xsd:int">3</span>
> [2],_Articles_and_Multi-volume_Works
> [3]
> [4]

Received on Tuesday, 12 August 2014 10:25:55 UTC