This is a summary of several iChat conversations between Kevin and I re: theme timeslots and metadata
The Problems / Issues
The approach to theme timeslots and metadata is meant to address several problems / issues. One problem is that there has not been an incentive for producers submitting programs via Create Show to complete the metadata fields accurately and often they have chosen the first item on the list - making that useless information. One issue is that stations will have different theme timeslots as they have different local audiences and different types of production and programs from the producer population. Another issue is that a mission of community television is the need (requirement in some cases) to target specific communities.
The Attempted Solutions
From what I gather, the idea now is to have two means to pre-populate program metadata in the Create Show process. The first would come from the Project. (Like in Facil - for those you who see that analogy - in Project, producers can / will add metadata that describes their general Project. The other metadata, of course, would be pre-populated from the theme timeslot selection. Having a Project is a requirement prior to creating a show (program). I'm not sure if selecting a theme timeslot will or shall be a requirement. It seems that it would need to be.
So the idea -- I thnk -- is that in the Create Show form, after a producer selects the theme timeslot, then a metadata options appear and some are pre-selected or pre-checked, based on the producers' Project and based on the theme timeslot chosen. At that point the producer has the option to accept those values, which will effectively be defaults, or to modify and fine tune.
This should ameliorate the problem of the person completing the Create Show form simply selecting the first metadata item on the list.
The other reason for doing this is so that in the event that the particular program is something of interest at another location, then that metadata is used as a way to recommend what theme timeslot it would appear at a different community television station.
The more granular, specific, and defined each theme timeslot metadata is, then the more useful and transferable to another corresponding (albeit differently named) theme timeslot on the other end.
A problem with this proposed solution arises when the theme timeslots are sufficiently broad so that any metadata transferred could apply to any number of theme timeslots at a different location.
Target Audiences
I also better understand that the concept Target Audiences as well as the way in which DOM has created some of their theme timeslots to also target specific populations (such as based on race/ethnicity/global geography - i.e. Latino/Latin American, African/African-American, European/Euro-Am), is meant to address the mandate/requirement of community television serving under-served communities.
We differ at channelAustin on this. We looked at DOM's theme timeslots and saw that there is a theme timeslot for African-American and one for Latino. And we considering doing it this way. But we realized that, yes, there are African-American producers at channelAustin, but little to none of their programming is thematically African-American. There are African-American producers whose programs would fit into our theme timeslots of Spiritual, or Music, or Community Issues. In those instances, selecting African/African-American as a target audience metadata, rather than having a theme timeslot for them, makes more sense. It is a similar case for Latino, or Hispanic, programs. There are a number of Hispanic producers with programs that fit into the Spiritual theme timeslot or the Music theme timeslot.
And it is probably better to organize it without having AfricanAmerican or Latino as specific theme timeslots. That way, the Music theme timeslot would be populated with Music from a diversity of cultures and backgrounds.
Moreover, whereas there is a mandate / requirement to reach and connect with target under-served populations. Is the mandate that we reach under-served populations so that they become producers and create programming, OR is the mandate that we schedule programming in such a way to target those underserved audiences? Maybe it is both. But I think the emphasis should be on the former and not the latter.
So these are some of the things we addressed. I probably left out a few of the more technical / programmatic points. Maybe Kevin can fill in.
Comments
Stefan, thanks for
Stefan, thanks for summarizing that.
Ann is actually considering or decided to combine African American and Latino into a more general Cultural Theme. This is in large part because we just haven't gotten enough content schedule the number of hours given to those themes. I've added the code I've used on Denver Open Media's stats page to the dev versions of om_support and om_timeslot_scheduler. For theme based autoscheduling to work as designed, there needs to be some relation between the amount of content in a Theme and the number of hours given to that theme.
The way both the Python autoscheduler Denver used with Drupal 5 and the new Drupal 6 code I'm working on works is that the autoscheduler makes multiple passes to try to fill content into a Timeslot Event. In the Python version, these passes were hard coded into the script.
The every channel had a file like channel57BlockTimes_1_mon.txt for every day of the week that defined the start and end time that was being scheduled.
#StartDay StartTime Duration Category Namemon 2009-10-05 03:00:00 0:30:00 Latino
mon 2009-10-05 03:30:00 2:30:00 Faith Based
mon 2009-10-05 07:00:00 0:30:00 GLBT
mon 2009-10-05 07:30:00 2:00:00 Well-Being & Lifestyle
mon 2009-10-05 11:00:00 2:00:00 News, Business and Government
mon 2009-10-05 13:00:00 1:00:00 International Issues
mon 2009-10-05 14:00:00 0:30:00 Mile High Perspective
mon 2009-10-05 14:30:00 2:00:00 Arts and Entertainment
mon 2009-10-05 18:00:00 0:30:00 GLBT
mon 2009-10-05 18:30:00 3:30:00 Well-Being & Lifestyle
mon 2009-10-05 23:30:00 0:30:00 GLBT
tue 2009-10-06 00:00:00 3:00:00 Well-Being & Lifestyle
tue 2009-10-06 03:00:00 0:30:00 GLBT
The Python code also hard coded pairings based on the Theme's name in another file like channel58Blocks.txt
,{false, "Monday", 0200, 240, {"Arts and Entertainment","Latino"},{2,1},{""},{false, "Monday", 0600, 240, {"Well-Being & Lifestyle","GLBT"},{2,1},{"AllAgesContent"}
,{false, "Monday", 1000, 240, {"Music","African American"},{2,1},{"AllAgesContent"}
,{false, "Monday", 1400, 480, {"Academic/Informational","Faith Based"},{2,1},{"AllAgesContent"}
,{false, "Monday", 2200, 240, {"News, Business and Government","General Youth"},{2,1},{""}
In the Drupal 6 code, we're now leveraging DateAPI to define the start and stop times for the Timeslot Event and a CCK Node Reference to Timeslot Theme. Stations who want to use pairings in their scheduling can enable om_timeslot_pairing which is a Timeslot Scheduler submodule. Without om_timeslot_pairing only the original Timeslot Theme will be available to query.
The Python script used 8 passes to try to populate the block with relevant content. It started with the top rated content as determined by a bayesian estimate with Primary Theme matches that hadn't aired in 7 days and then moved to Secondary Theme matches. In the D6 version, we eliminated Secondary Theme from om_show. The next 2 passes were the top bayesian shows that hadn't aired in 3 days... then 1 day. The 7th pass was a wildcard for category and was basically looking for content with a duration that matched the remaining gaps between content. The last pass filled any remaining gaps with interstitial content.
passNum 1
field = "ThemeBlockPrimary"
daysSinceLastAiring = 7
passNum 2
field="ThemeBlockSecondary"
daysSinceLastAiring = 7
passNum 3
field="ThemeBlockPrimary"
daysSinceLastAiring = 3
passNum 4
field="ThemeBlockSecondary"
daysSinceLastAiring = 3
passNum 5
field="ThemeBlockPrimary"
daysSinceLastAiring = 1
passNum 6
field="ThemeBlockSecondary"
daysSinceLastAiring = 1
passNum 7
catToLookFor="*"
daysSinceLastAiring = 1
# Couldn't find anything to fit, so have a guest show
# fill in, but the guest show's lastAiring shouldn't be
# updated because it could hurt the chances of the show airing
# in it's own category block
passNum 8
catToLookFor=Inputs["interstitialThemeName"]
field="ThemeBlockPrimary"
daysSinceLastAiring = 1
The Drupal 6 code allows users to add the results of any SQL query as a pass. In addition to the query, users define a variable for last aired. A separate function excludes shows that have aired withing the last aired variable. Right now, both the primary theme and the pairing theme follow the same rules.
The reason I'm posting this now is that I think understanding how autoscheduling works is going to have some impact on how stations define their Timeslot Themes and how they configure their Timeslot Events. The amount of content in a station's archive for each theme will be have a lot to do with how well theme based scheduling works.
If you have a theme like Youth and allocate 4 hours each week to it but have only received 32 shows in the last 6 months, there is going to be a lot of repeated content, content form other themes, or interstitial airing. The reverse is also true. If you only allocate 4 hours a week to faith based programming but are that makes up 40% of the new content users are adding, shows in that theme will be scheduled further and further into the future.
I've found the easiest way to visualize this is to think of the shows as legos.
If each color represents shows in a theme and the size of the lego represents the duration of the show, to get all the show scheduled you'd either need to go tall (more of that type of content in a day/week) or wide (more that type of content over time).
I hope this helps clarify a few things and isn't creating more confusion.