Program vs Episode and the programme element

[Mike Pilone]

I'm mapping an internal domain model which has the concept of program and episode into RadioDNS RPG which has the concept of programme and programme group. I'm trying to figure out the best way or the intended way to map these concepts.

As a rough example, a program might be "Sherlock" while an episode might be "The Blind Banker". In the EPG, I could:

1) Create a ProgramGroup named "Sherlock" with a Program named "The Blind Banker" linked to the group.

OR

2) Create a Program (medium) named "Sherlock" and (long) named "Sherlock: The Bllnd Banker".

OR

3) Create a Program named "Sherlock" with a mediaDescription entry of something like "Episode 2: The Blind Banker".

If clients are expecting a recurring program to appear as a program group, then option 1 makes sense. But if a client is simply displaying an interactive program guide, I would expect that it will just display the programs and not the program group information or the group information would be in the details but not on the guide overview. 

That makes 2 or 3 better solutions. Because we don't know how much information can be displayed in the program guide, option 2 might be confusing because the episode name could appear directly in the guide rather than just a program name while option 3 would prevent that but bury the episode information in a generic description field. Option 2 also gets confusing if the program name already has a colon in it because you end up with multiple levels of detail being represented in the program name.

I'm thinking of a situation where a client may want to setup a "season pass" or "series recording" in which case it would want all episodes for a given program. In this case, 1 and 3 make the most sense because with 1 the program group could be used as the series key and with 3 the program name is consistent so it could be used as the key. However my experience as a TV EPG user is that series recording is based on program name when matching and there isn't really reliable group/series/program level information (but I could be wrong).

Has anyone put any thought into this? Is there a recommendation based on how device manufacturers are using the data and what they are expecting? I'm inclined to go with option 3 unless I know device manufacturers are expecting program groups to carry the program/series information and each "programme" element to be titled for an episode.

Thanks,

-mike

[Ben Poor]

Hi Mike, 

Good question, and my short answer is: No.3 with a touch of No.1 if you can, but dont forget about implicit series linking.

I'm taking my cue from experience in how certain EPG platforms work here in the UK and hopefully maps through pretty well to other places. 

In terms of display, having multiple instances from the same series with the same Programme name makes most sense. So, for instance, in the case of 'Sherlock', the user would see multiple similar instances in the EPG. The mediaDescription field would be filled in with information specific to that episode, so for instance:

shortName/mediumName/longName: Sherlock

mediaDescription.shortDescription: Episode 2: The Blind Banker

There is functionality to fill out more information for series, strands, brands and collections - the GI file. One can state in a PI file that a Programme is a memberOf a particular grouping, and then use the GI file to expand on the details of that group - additional names, descriptions, logos, etc.

However, one can still imply grouping even without the GI file - you just mark up every Programme in the group with the same memberOf value.

For example, I could say that each episode in the series of Sherlock programmes has the element:

<memberOf id="http://npr.org/series/15787" shortId="15787"/>

A client would then be able to associate programmes in the same series, and implement functionality like "series recording". You could then also provide additional metadata for that series, if you like.

Device Manufacturers are mindful of the use cases for programme group membership, although it is fair to say that practical examples of this are currently few in number.

Ben

--
You received this message because you are subscribed to the Google Groups "RadioEPG developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to radioepg-developers+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mike Pilone]

Ben,

I hadn't realized you could use memberOf without a group definition for implicit linking but that definitely makes the most sense. #3 with a bit of #1 it is.

As I mentioned in other posts I'm evaluating RadioDNS EPG for providing metadata from the central distributor to the affiliate stations. In this scenario the member stations would use middleware to pull the EPG data directly from the distributor and relay it out over various transports and potentially host their own listener facing EPG information in the future. The middleware would let stations setup a schedule that normally includes playing the same program at the same time during the week such as "All Things Considered" at 0600 M-F. I want to make sure they can easily identify the same program/series in the EPG as they fetch new PI data from day-to-day after the schedule has been established. This is B2B but it isn't much different than the set top box concept of recording a series or a "season pass".

Thanks,

-mike

[Ben Poor]

Absolutely, you can model B2B metadata usage in the same way as you do with set-top box.

So, to identify the 'same programme', you would match on the Programme Id (Crid) and/or ShortId. 

To identify programmes in the 'same series', you could match Programmes that share the same memberOf element.

To unsubscribe from this group and stop receiving emails from it, send an email to radioepg-developers+unsubscribe...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.