Discussions on TV

First, thanks for doing this. I’ve recently begun attempting to watch all the Doctor Who episodes from the beginning, which is entertaining.

Secondly, please note that no value in Freebase is actually required. You don’t have to give the character.

That said, I don’t really see a problem with having a character for “Man in bar” as long as “Man in bar” from twentieth-season Doctor Who is not the same as “Man in bar” from Beverly Hills Cop, who is not the same as “Man in bar” from Babylon 5: The Gathering. Even those anonymous characters have gender and organizational affiliations, and for science fiction, species. I had a lot of fun fully populating the cast for the B5 pilot, though I haven’t gotten back to doing it for all the episodes.

I started filling in cast lists from the 2008 end and working backwards, so perhaps we'll meet somewhere in about 1975 :) So far I've left character as an empty field in places where the character is unnamed - that at least means the information can satisfy actor queries. But you're right, adding scenery characters does allow extra facts to be added and other connections to be made that are not otherwise possible.

I've already run (several times) into an issue with Freebase with "common" topic names - you can't link to the right one - which makes me want to avoid them if I can, but if the right bit of juicy data comes up, I'll be sure to do so :)

Hi Chris N,

You mentioned having problems with autocomplete, where the item you wanted wasn't on the list. Do you still remember what exactly you entered? I'd be interested to know: 1) the property you used autocomplete on, 2) the string you entered, 3) expected topic. Among other things I test the relevance engine that produces these results, so issues are of interest to me.

Also, autocomplete is not an "exact name matcher". You can enter additional information unique to your topic to help boost it to the top. For TV episodes, for example, entering the TV show's name in addition to the episode name helps, especially if the episode name is "The Rescue" or something that'd find many matches.

Hi there,

Don't spend too much time worrying about this, I've gotten a little more experience now with how things work here - and a bit more confidence on how things are 'expected' to work. The point about the non-exact matcher is well-taken, now I've seen the autocomplete more often suggest topics which are "useful" rather than exact, I have a few ideas how to use it to help me search as well. The main thing I've been doing lately is, if I definitely need a precise node that's unlikely to be high up the list, I open up another window and search for its guid.

 As it happens, I was experimenting with 'previous/next episode' as a reciprocal relationship. (This has been added to TV episode now, but to experiment with it I added a "TV episode additional data" type in my default domain). So:

1) I was trying to fill a 'previous' property on a 'TV episode additional data' type.

2) I was looking for the Doctor Who episode 'Midnight' and used just 'Midnight' as the search string.

3) The right node doesn't show in the suggestions - but I understand why, now. Until this relationship was filled, the target node didn't have the 'additional' type, just the existing TV episode. So the type information wasn't helpful in the search.

 My expectation that an "exact name" would take priority threw me a curve ball - once I got past that, I have no expectation now that somehow the machine will automagically work it out for me *every* time... 99.9% of the time is good enough for me - the corner cases are worth the extra work.

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?

To get the hang of things here I messed around with a type extending "TV Episode" and added "preceded by" reciprocating as "followed by". Agreed, it helps navigate, and it's also common on the wikipedia source articles as well.

However my guess is there should be a much grander type involved here for anything that can be ordered in a sequence, not just TV shows. Items may probably appear in more than one sequence as well (for example, story chronology isn't the same as release chronology - Star Wars movies are the cliche example).

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!

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.

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.

Only a year late... here's the BBC Programmes Ontology, built by Yves Raimond based on the BBC's internal data model:

http://www.bbc.co.uk/ontologies/programmes/2008-02-28.shtml

You may also be interested in our programmes database, containing all programmes broadcast from about August 2007 onwards: http://www.bbc.co.uk/programmes/

The idea is to release a machine-readable version of the /programmes site, marked up with the Programmes Ontology, some time soon.

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.