Re: TVRadioSchema extension to schema.org

Ah, OK, understood.  But a question...

'string' type for the proposed 'position' property is a need for the
industry.  I understood that.  My 2nd part question was of 'position'
itself.  As my example was not a particular number or even alpha-numeric
positional id, but instead just a phrase describing the order placement of
an episode in a particular line-up sequence.

'Tonight after Midsomer Murders'

If the use can be wider, such as my example above, then make sure to change
the definition to allow for ANY string or phrase that describes an order or
placement of an episode in a sequence of events, or an instance of a unique
TVSeries episode or TVSeason episode.  But it appears the use is more
focused only to give an episode a unique string identifier to give it
placement within a TVSeries or TVSeason, so we should improve the
definition for the 'position' property.

We probably then will need to have an additional flexible way to handle
line-up sequences.  Currently, we are only giving folks a Publication that
can link to a BroadcastEvent and we need more flexibility with line-up
ordering (independent of a database backend to supply that order, or
programmatic date() functions to make comparisons against Start and End,
that apply an order)

I want us to be thinking of how TVRadioSchema structure can be used even
outside of TV and Radio... such as Podcasting lineups, or a line-up of
Videos shown back to back at a Corporate Conference, etc.  Make Sense ?

On Tue, Aug 7, 2012 at 1:40 AM, Jim Helman <jhelman@movielabs.com> wrote:

>  Hi Thad,
>
> At EIDR (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,
>
> --
> -Thadhttp://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> <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> <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> <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> <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
> **************************************************
>
>
>
>


-- 
-Thad
http://www.freebase.com/view/en/thad_guidry