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

Hello Dan, Yves,

The larger use of position would probably less marked than things like EpisodeNumber or SeasonNumber. Declaring it as literal or leaving it open makes sense (I often have this dilemma in other applications).

This being said about defining a sequence like periodicals or else, I have been using an object property "nextInSequence" that would link objects and would make numbering oddities like 3, 4-5, 6 just some additional descriptive information without a major impact on establishing relations between objects/publications, etc.

Jean-Pierre


From: Yves Raimond [mailto:yves.raimond@gmail.com]
Sent: mardi 12 août 2014 12:25
To: Dan Brickley
Cc: David Marland; public-vocabs; Richard Wallis; Evain, Jean-Pierre; Dan Scott
Subject: Re: revisiting 'position', 'episodeNumber', 'seasonNumber' modeling and Periodicals


Hello Dan,

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

------------------------------------------------------------------------------

**************************************************
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error, please notify the system manager. This footnote also confirms that this email message has been swept by the mailgateway
**************************************************