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

By non-integer I guess you mean e.g. string (or else) - then fine

-----Original Message-----
From: Dan Brickley [mailto:danbri@danbri.org] 
Sent: mardi 12 août 2014 15:02
To: Evain, Jean-Pierre
Cc: Yves Raimond; David Marland; public-vocabs; Richard Wallis; Dan Scott
Subject: 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.
------------------------------------------------------------------------------

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

Received on Tuesday, 12 August 2014 13:04:51 UTC