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

On 12 August 2014 12:23, Evain, Jean-Pierre <evain@ebu.ch> wrote:
> Hello Dan, Yves,

Hi Jean-Pierre, Yves,

Thanks for the quick response!

> 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).

Do you think it would be bad to allow non-integer values on
http://schema.org/episodeNumber and http://schema.org/seasonNumber ?

> 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.

I think you're right that these fields serve equally as descriptive
information (i.e. for display rather than formal ordering) and that
other mechanisms can be used to get a strict order when needed.

> From: Yves Raimond [mailto:yves.raimond@gmail.com]
[...]
>> 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?

I've done some (fairly basic) analysis that seems to confirm this
suspicion. Amongst the largest few sites that are publishing
'position', 'episodeNumber', 'seasonNumber', I didn't find a single
case where 'position' was used alongside either 'episodeNumber' or
'seasonNumber'. It is much more common for episodeNumber and
seasonNumber to be found on the same site. The most popular of these
three properties is episodeNumber; seasonNumber appears on about half
as many domains, and in 1/6 as many triples. The 'position' property
is much less popular (except on the BBC site).

Could we live with:

1.) episodeNumber, seasonNumber, volumeNumber, issueNumber all get
schema.org expected types of both "Text", "Integer"
2.) we declare "position" as their common super-property, and give it
the same expected range.
3.) we add example(s) showing in JSON-LD and RDFa how a strict
datatype of Integer can be written. For example,

    {
      "@type": "TVSeason",
      "datePublished": "2006-05-14",
      "episode": {
        "@type": "TVEpisode",
        "episodeNumber": "1",
        "name": "Episode 1"
      },
      "name": "Season 2",
      "numberOfEpisodes": "27"
    }

becomes

    {
      "@type": "TVSeason",
      "datePublished": "2006-05-14",
      "episode": {
        "@type": "TVEpisode",
        "episodeNumber": 1,
        "name": "Episode 1"
      },
      "name": "Season 2",
      "numberOfEpisodes": "27"
    }

Technically this would allow "episodeNumber" to take strings like
"iii" but they could be distinguished from values like 3 if publishers
preferred to use JSON-LD or RDFa.

Dan

p.s. I notice http://schema.org/numberOfSeasons and
http://schema.org/numberOfEpisodes have expected type of Number rather
than Integer. I don't believe we have been clear on whether there are
any values that count as Number that aren't in the subtypes Integer
and Float.

Received on Tuesday, 12 August 2014 13:02:06 UTC