Re: TVRadioSchema extension to schema.org

Hi Thad,

At EIDR (www.eidr.org <http://www.eidr.org>), we recently conducted a 
practices survey among our studio members. Integers are sufficient more 
than 98% of the time.  But our members identified a number of use cases 
in which episode numbers are not necessarily integral.

The most common exceptions occur when double length pilot or finale 
episodes are split up for syndication without renumbering the subsequent 
episodes, e.g. the "1a" and "1b" example.  There are also cases in which 
a studio may produce and distribute the two halves of a double length 
episode with separate numbers, e.g. "1" and "2", but then EPGs still 
need to traffic in the combined episode, which they would number "1/2".

EIDR's metadata model was originally just integer for the "public" 
number (broadcast or other primary distribution number... we do also 
track internal studio numbering).  But in light of the above, we've 
decided to extend the public number to allow an integer with a "suffix" 
but still keeping the number as an orderable sequence within the series 
or season.  For example, we do not allow the season number to be 
included, since practices that do, e.g., "s02e01" vs. "0201" vs. "1" 
vary widely and therefor don't serve EIDR's metadata goal of enabling 
automated matching.  We do allow those formats elsewhere in studio or 
distributor specific metadata.

In short, an integer with a suffix within a season or series seems to be 
a good target as a common vocabulary for matching and ID. You could be 
more flexible and allow fully arbitrary strings, but to the extent that 
the semantic web benefits from a common vocabulary, I'd suggest limiting 
the practice.  I'm not completely clear on the "number" vs. "position" 
model, since we don't split the main number.

I'd be happy to discuss further.

Best Regards,

-Jim


On 8/3/12 7:34 AM, Evain, Jean-Pierre wrote:
> Hi Thad,
>
> The main requirement came from MovieLabs and Jim may want to follow up.
>
> In the meantime, one requirement is to allow values such as e.g. 1a, 1b, etc. One can not only define numerical episode numbers but also establish ranks between related material such as with a pilot in different languages or its  different versions for different audiences or medias, etc.
>
> JP
> ________________________________________
> From: Thad Guidry [thadguidry@gmail.com]
> Sent: 03 August 2012 15:24
> To: Evain, Jean-Pierre
> Cc: public-vocabs@w3.org; Dan Brickley; Jim Helman; Yves Raimond; Raymond Drewry
> Subject: Re: TVRadioSchema extension to schema.org
>
> Jean-Pierre,
>
> Can you give a quick text string example of a real-world usage of the proposed new "postition" property that will be used for ranking ?
>
> My thoughts are that your asking to accommodate something like "position" : "following the Late Late Show with Craig Ferguson" ?
>
> Thanks in advance,
>
> --
> -Thad
> http://www.freebase.com/view/en/thad_guidry
>
> On Fri, Aug 3, 2012 at 1:12 AM, Evain, Jean-Pierre <evain@ebu.ch<mailto:evain@ebu.ch>> wrote:
> Hi Dan, all,
>
> We had one last open issue about ranking episodes and other content resources using other than purely numerical values (e.g. as provided by the episodeNumber). EBU, MovieLabs and BBC have discussed the requirements and we have come with the following proposal, i.e. define a new “position” property, additional to episodeNumber. The “position” property is a string. This solution avoids changing the datatype of Episode Number.
>
> ;;;;;;;;;;
> * Create new property called 'position' of type “string”
>
>    with description "to define other than pure numerical ranking of an episode or other content resource in an ordered list of items (further formatting restrictions may apply within particular user groups)"
> ;;;;;;;;;;
>
> Changes have been reflected in  www.w3.org/wiki/WebSchemas/TVRadioSchema<http://www.w3.org/wiki/WebSchemas/TVRadioSchema>
>
> With these final changes, EBU, MovieLabs and BBC suggest that this is added to the next release (0.98?) of schema.org<http://schema.org>.
>
> Best regards,
>
> Jean-Pierre
> And on behalf of Jim, Yves, and Raymond
>
>
> EVAIN Jean-Pierre
> EBU - Technology and Development
> L'Ancienne Route 17A
> CH-1218 Grand Saconnex (GE)
> Tel: +41 22 717 27 34<tel:%2B41%2022%20717%2027%2034>
> Fax: +41 22 747 47 34<tel:%2B41%2022%20747%2047%2034>
> evain@ebu.ch<mailto:evain@ebu.ch>
>
>
>
>
> ________________________________
>
> **************************************************
> 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
> **************************************************
>
>
> ------------------------------------------------------------------------------
>
> **************************************************
> 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
> **************************************************
>