TV Program

TV Program: Regular performances, but which episodes?

2008-04-14T19:56:47.0007Z

The next question is (having capitulated to adding seasons to the regular acting performance), do we still need the "to" and "from" dates? Arguably, no, since the seasons should tell us that. But sometimes we only have that data (e.g., from wikipedia infobox loades).

TV Program: Regular performances, but which episodes?

2008-04-14T18:51:10.0007Z

Right, but if you use the Performance for a regular actor, the data gets quite dense very quickly. It seemed like Performances was for additional actors beyond the regulars. There’s also an important distinction; sometimes a frequent guest star becomes a regular character, and sometimes a regular character returns for a guest appearance.

In fact, here’s a crazy idea… What if the Regular Performance CVT had additional disambiguators for seasons and episodes?

TV Program: Regular performances, but which episodes?

2008-04-14T18:22:07.0007Z

Whatchoo talkin' 'bout, crism? TV episode has properties "performances" and "personal appearances" which are for all people who appear on the episode, regular, guest, or otherwise.

TV Program: Regular performances, but which episodes?

2008-04-12T08:33:23.0012Z

I think it makes sense to have the regular performances property. However, there is no way to indicate in which episodes a regularly-credited actor appeared, and it is silly to mark them as a guest actor.

What if the regular appearance (and I think I will copy this comment there) had an additional disambiguator pointing to the episodes in which the actor actually appeared?

TV Program: Episodes

2007-05-16T16:20:38.0006Z

'Suspecting' isn't something computers do ;-) Anyhow, then someone should go thought all types/docs and unify this. Thanks for the clarification thought

TV Program: Episodes

2007-05-15T01:32:18.0006Z

David Flanagan wrote the documentation based on my music types, which were among the first types designed for Freebase. I tended to use singular for the property keys. The display names have since changed to plural, and this is definitely a better user model. So: plural if you expect that there will usually be more than one value for the property.

TV Program: Episodes

2007-05-07T21:32:45.0006Z

Interesting. You've just found a big discrepancy in our documentation. The help topic "adding properties to types" reads, in part:

Property Name
[...]
To add a new property, you simply click the 'Add New Property' button and type in a display name for the property. These new properties are displayed in the 'User Created Properties' section. Note: A display name must be unique for that type. You may also want to use a plural name because the property often contains a list of items (example: 'siblings' instead of 'sibling').

Since creating a property through the UI automatically generates the property key from the display name, this instruction is essentially the opposite of the one in the developer API. I'll see if we can't get some clarity on this.

TV Program: Episodes

2007-05-07T20:14:43.0006Z

From the Developer API:

Singular or Plural?

Note that the property we query in the example above is named "album" and not "albums", even though bands like The Police may well have more than one album. This reflects the underlying nature of Metaweb: the database object that represents The Police has many links of type "album" that refer to the objects that represent those albums. The type /music/artist aggregates these many links into a single set of albums, but retains the singular name "album" because that is the name of the underlying link type.

Also, as we'll see soon when you want to obtain information (such as a list of tracks) about one particular album, you specify a single value (instead of an array) for the album property. In this case, the singular name makes a lot of sense.

Although property names are typically singular, there are exceptions to this rule, and sometimes you'll see a plural property name.

In this case we have a property TV Program, which links to a property Episode, which is the name of the underlying object. I don't think this calls for an exception, if you read the explanation. (I didn't mean the label, I meant the property)

TV Program: Episodes

2007-05-07T20:09:48.0006Z

Since we're expecting to see a list of episodes, I think the plural makes more sense; I think it would look awkward if the label were "episode" and there was a list of several episodes below it. Unless there's something I'm missing?

TV Program: Episodes

2007-05-07T11:27:32.0012Z

Shouldn't the TV Program property "episodes" be "episode"?