Discussions on TV

/guid/9202a8c04000641f800000000fca1420

This is an interesting problem. We're essentially giving names to things that aren't normally named (at least not in the way that a TV show has a name); most TV websites label the seasons as "Season 1", etc. and rely on the context to supply the name of the program (since they don't have visible representations of the seasons as separate objects); Wikipedia, which, like Freebase, does have separate representations for seasons, uses the format "Program X (Season Y)", which is very similar to what we do. Because any naming practice we use will be somewhat arbitrary, I think that it would always qualify as "hidden" knowledge to so some extent.

"Creator" is often a particular credit on a TV show (not all TV shows have this, however). See, for example, these various sites' representations of "ER": TV Rage, IMDB, Wikipedia. Note that in each, Michael Crichton is credited as "creator" (or "created by"). This information is not extractable from the combination of writers, directors, and producers.

I can't tell for sure about Death Note, but the practice should be that, if a series is the same in multiple regions, it's one series (e.g., the Japanese series is rebroadcast in the US). However, if a network in another region remakes the series for that region (like the US version of The Office), then it's two series.

I did actually do an import from the TVDB a while ago, so you should see TVDB links on certain TV shows and episodes. Right now, though, most of this data comes from TVRage and is updated every night. Was there anything specific you want to see? Episode summaries and images are coming soon.

dynamic/calculated properties will be making their way into freebase in the next few months.. keep an eye out for 'em.

That makes sense. So the property description would be something like "seasons in which this writer wrote one or more episodes of this program"? I'm trying to get a sense of how we want this type to be used, since this CVT already sort of denormalizes the TV Writer data, and we've never really defined what a "regular contribution" is -- more than one episode? More than a certain percent of episodes? (I mean, if someone wrote two episodes of a show like ER or MAS*H, would that really be considered regular? On the other hand, if they wrote two episodes of a show that was cancelled after a few episodes, or a mini-series, it might be a significant contribution.) Acting is much clearer in this regard, since there's a much clearer sense of who the stars of a show are, even if it only had one or two episodes.

TV drama series tend to have episode writers, but don't talk shows and sitcoms usually have the same writers for an entire season or seasons? I had Saturday Night Live in mind when I proposed the property, but it applies just as well to shows like 30 Rock.

And it looks like SNL was the original use case, since those were the first relationships created. We could decide to fully denormalize this, and just say that anyone who's written for a show can be listed in this property, which would spare us from trying to define a very fuzzy space.

Oh, yes, this should be posted as a suggestion in Media Commons as well.

Yeah, Jeff and I were talking about this just the other day.  There is a proliferation of "X subject" types out there: book subject, film subject, video game subject, visual art subject, etc.  I don't know whether we can combine them all or whether we want to or what, but it seems worth thinking about.

I definitly vote for merging all media into a generic media commons property, or at least merge the types for Art Subject, Film Subject, Written Work Subject into a single Media Subject type and still keep the properties for Film Subject, Art Subject, Book Subject for the Film, Artwork and Written Work types.

Merging all the "subject" types into one giant "subject" type, with properties for each expected type would probably work. (If we kept all the old keys around, the change might even be transparent to API users.)  One caveat is that non-commons types expecting a subject would still need Foo Subject types if they wanted the properties to be reciprocated; these types would then have to be merged with Media Subject, rather than simply moved to a new domain, if they were promoted.

Did we ever really resolve this?

It's still just a thought, a good one I think.

I'd like to get some more opinions on this, since there are several type structures with a similar pattern (genres being the main one), so I'm going to ask the data-modelers' list.

I noticed that "Subjects" and "Subject of" properties were added directly to Topic.

Here are the JIRA tasks that explain how subjects will ultimately work: CLI-9011 and DA-908

Good catch. All fixed now.

Yes -- that's a pretty big oversight. I'll fix that.  Also, it looks like we're going to be able to load ALL the 60 Minutes episodes from tvrage.com quite soon, possibly today, so you should be able to match these segments without having to create new episodes.  The data team has loaded episodes for all the TV shows that it could reconcile (60 Minutes wasn't reconciled, which is why it was missed -- there have been several shows with that name, it turns out); if you run across more, speak up and we can see if they can be added.

Wow, sounds great!!

OK, I've added appearance properties to segment: I had to add two, one for "official" appearances -- hosts, newsreaders, etc. and one for "guests" -- interviewees, one-off "experts", people plugging their latest album/film/etc., and the like.

Yes it is. Thanks for reminding me!

And here you go: Sequence of tv episode segments

Thank you!!

There hasn't really been any discussion of how to standardize here. Different data sources use different forms even internally and there has been no effort to standardize them yet.

Danm proposed something like this ages ago -- here's a table view of his model: Work of Fiction. I think it's a good model, but it never really went anywhere in part because no-one seemed interested in figuring out how it related to the existing commons Work of Fiction type (if at all).

There.  I think that should be clearer now.

Oops, forgot to show example.  See A&E Television Networks: The Biography Channel, A&E Network and The History Channel.  Or should we just use the Company Division to show this linkage (didn't think of that before...d'oh!)

Using company or company division (as appropriate) seems like the right approach.  Shout if you find any other patterns, though.

They should be entered using the Personal Appearances property on TV Episode. This is for all non-acting appearances on TV.  The problem here is that the expected type is Person, and there's no reciprocating property. That's something that should be fixed.

This hasn't been fixed yet, but there's now a task for it (DA-683).

This would be a fairly trivial fix, if it weren't for the problem of coming up with the name of the type for people who appear in TV shows as guests, contestants, etc. 
"Person on TV"? "TV appearer"? "TV program guest"?  I welcome, nay, beg for, better suggestions.

I'm going to go with "TV program guest" for now.  The display name can always be changed if we come up with something better.

works for me.

Done!

I am interested in what episodes an actor actually appeared in, as well as when they were part of the formal cast. For example, in Babylon 5 (where I’ve done the most detailed modeling), Michael O’Hare was part of the cast for the first season, but was not actually in every episode, and then appeared in a few other episodes later on. The connection between the actor and the series, with seasons and dates as disambiguators models the starring relationship, and the episode cast list models the actual on-camera appearances. I think this is the right approach.

Filed https://bugs.freebase.com/browse/DA-672

In the examples, I see two types of "story": one that is greater than an episode, and one that is smaller.  So maybe two types would make sense. One for "multipart epsiode" with a property "consists of episodes", and one for "tv vignette" (or something -- I just made up that term) with a property of "included in episode". This latter type would also be useful for sketch comedy and anthology shows. (And would give us someplace to put The Parrot Sketch.)

Looking at this more deeply, the question of metadata for "tv vignette" (or whatever it should be called -- maybe "TV episode component") arises. Should we capture performance, writer, director, etc. data at this level?  It would require duplicate properties on most of the TV people types, and even more performance CVTs, and seems like it might be annoyingly complicated.

Here's a multi-part episode only schema on sandbox: https://www.sandbox-freebase.com/type/schema/tv/multipart_tv_episode. 

I was going to ask about this.  I'm just adding some Keith Floyd episodes which were filmed in various bits of Africa, and I'd like to be able to connect each episode to the places it was filmed in.  I also need to be able to connect an episode to more than one location.

Good catch. I see that "number of episodes" is also non-unique.  If there are no topics with multiple dates, this should be a quick fix; if there are some with multiple dates, it will take a bit longer.

well, sadly the reason I even noticed this was that the app I'm building stumbled upon one. The new Battlestar Galactica show (can't remember if it's miniseries or regular series) has two dates for first episode. I haven't found any others yet, but who knows. Coincidentally, the value for "release_date" on video games also allows multiple values. I've figured a way around this in my program, but I still don't know how you would sort the results by air date as long as they allow multiples...

Turns out that there are several hundred instances with more than one of either first or final air date, so this will take some time. I've opened up a ticket for this (and videogames).

Cool, thanks for looking into this.

Looks like some two-part episodes are currently modeled as a single episode.  See The Best of Both Worlds, for example.  I thought we had figured out a way to deal with these awhile back, but I can't find any relevant posts.  Faye, do you remember?

Cool; we're always looking for ways to improve the search/autocomplete features, so feedback is highly appreciated. Single-word searches often return many more results than can be displayed in the 10-item list, that "Midnight" failed to come up is not surprising. In the next release, you will be able to type in "midnight doctor who" and have a very good chance that the Doctor Who episode named "Midnight" will show up.

I also would use it. I'm wondering though, could that not be generated automatically based on episode number? Have you (staff) considered adding the functionality for field that could be generated from a query?

A lot of things are sequential, but I think an abstract type ("sequential thing"?) for all of them would be more trouble than it's worth. The pattern is just a variation of the parent/child pattern, which appears all over the place in Freebase, without an abstract type collecting them all.  That said, I can't think of any reason that TV episode shouldn't have previous/next properties.  If no one objects, I'll add them later this week.

The properties are there now.  Have at them!

Yay, thanks Jeff!

I think Web links are appropriate for now. My paranoid worry is that leaving a blank spot for online viewing to fill in would be perceived by some parties as inviting users to fill in unauthorized distribution channels, and we really don’t need that legal hassle.

Good idea. Take a look now. It looks to me like it's only defaulting to the first property, which is now "Programs in which character appeared as a regular" (or something like that). Is this the best property, or would "Episodes appeared in" be better? I mention this because only some characters will have data for the "Programs" property, while all characters could have data for Episodes.

tough one... my inclination would be to lead with the regular appearances, however, so it looks good to me.

I find the varying usage of the words "Program", "Series" and "Season" a bit confusing -- it appears that in many cases the word Series is used to mean the same as TV Program (eg "TV Series Season" could be called "TV Program Season", right? unless I'm misunderstanding your usage. Plus "TV Series Episode" has links to both "Series" and "Season" but nothing to "Program").

Is that right? Perhaps the type called "TV Program" was until recently called "TV Series" and so the UI labels haven't been changed in related types?

Or I could just be confusing myself because we generally use "Series" and "Season" interchangeably here in the UK.

Right now I'm assuming the hierarchy is supposed to be:

TV Program (aka Series) -> TV Series Seasons -> TV Series Episode

is that right?

I know how hard it can be to model the varying relationships between episodes, programmes, series, strands, etc etc, if you want to see a few of our data models we use at the BBC, just ask.

You might regret it though ;-)

Brendan.

Your assumed hierarchy is correct. You're also right in your guess that the inconsistent naming is because we recently changed the schema, and obviously we missed a bunch of the labels.

I'd love to see how the BBC handles the modeling of this type of information; there's been some discussion about our model's failure to handle Doctor Who serials, and it would be good to see what else we're missing.

The "other crew" property on "TV episode" is intended to be used for this sort of thing (i.e., any creative or production role that isn't addressed by any of the other properties).

I love the Colbert report as much as the next guy - does it really deserve its own type? Does this mean we might have types for all our beloved shows? Can we add 'Twin Peaks Episode' with a number of pie sightings and references to 'hot, black coffee'? 'Lynch films Films exploring similar themes'? Don't get me wrong - this type is a lot of fun, just wondering what it might lead to.

I don't really know that it will lead us anywhere we weren't already going -- this is an ability implicit in Freebase's design, and is one we already make use of in a number of schemas. I would actually encourage people to copy this model, because it enables us to model general types with properties that will be broadly applicable, while at the same time allowing users with particular interests to model and capture data that is very specific to a group of related topics.

And I asked the question that should be answered every time a type is added -- are there properties unique to the type that a group of people would want to use? The answer seemed very clearly yes. This is one of the many reasons that the scope of domains is actually so small. Some of them may have dozens of types or even more.

Wouldn't this be better named as "his/herself" and aliased to "himself" and "herself"? You shouldn't have to run two queries to capture everybody playing themselves since you can always restrict the gender in your query manually.

No, I think you're doing the right thing. The typer was going off the Wikipedia infoboxes, which use the same template for Doctor Who episodes and serials, so the two were getting conflated. By separating them out, you're actually improving the data, so please! keep up the good work. If the "TV series serial" pattern is (or was) common, we should consider adding it to the public TV domain, but, at the moment anyway, I haven't been able to find any other shows that use it, so we'll hold off on that.

Star Trek also had serial stories containing multiple episodes, such as the following story below that was split into the third season finale and the first episode of the fourth season of Star Trek: The Next Generation. I was not happy about it getting typed as a TV series episode when I added it as part of the series. I think a "TV series serial" type would be useful in this situation.

http://www.freebase.com/view?id=%239202a8c04000641f800000000022ec00

This is a great idea, but it sounds like it may need to be expanded to include any multi-part episode?

If anyone would care to take a look at the type I created and tell me how to improve upon it for any multi-part episodes (it may already be...) I would be happy to make those adjustments so others can use it.

I think your model is pretty close to what we need, if we change the name to something like "Mulit-part TV Episode". The only other things I would change would be to make the links from "multi-part tv episode" to "season" and "series" be one-way, so that they aren't listed on the main series and season pages. (My thinking for this is that, with the exception of Dr. Who, it's not especially useful, and perhaps a bit confusing to have separate lists for "episodes" and "multi-part" episodes.) The "season" property should also be non-unique, since the ST:TNG two-parter that Faye found actually bridges two seasons. Otherwise, I think it should work fine.

Thanks for observing that some multi-part programs span multiple seasons, Jeff.

Instead of being a special case, a two-part episode bridging one season's finale and the next season's premiere was the normal with some of the Star Trek series (Voyager in particular). In terms of production and episode numbering though, they were considered two episodes, as were two-hour specials (like series finales) aired back-to-back. Nobody would say a typical season contains 25.5 episodes. That means a "multi-part TV episode", though singular from the perspective of a story, should be allowed to have multiple values for properties such as "episode number" and "production code".

I agree it's annoying, and it would ideally be auto-filled if the reciprocal value were already entered, but there are more properties on the guest appearance type than can be made reciprocal (at least currently). The series is useful information, however, if you're viewing the actor's page. If series weren't displayed, all you would see was the character they played and the name of the episode, without reference to the show itself.

The UI should be automatically grabbing the series info from the episode, so you need to make sure that the series link is set correctly on the episode.

I'm coming at this from the director's page (which I just typed as TV Director). Do you mean I need to navigate to the episode "This'll Kill Ya" and make sure it's typed properly before I can enter the information on the director's page?

I added "series" as a disambiguator to seasons; it is already a disambiguator for episodes. The trick with episode is that you have to make sure it's actually been entered in the episode -- it doesn't necessarily autofill that value.