jamie

TV: TV episode performance limitation

2008-09-02T15:31:48.0012Z

The next release? Actually, it seems like there's a lot in there already that seems helpful - in particular the description field looks like it's included in the match. Quite handy, since many of the source wikipedia articles were obviously written to a particular template.

I just gave this a try and intended to type "tenth episode of the fourth series..." etc to get a match. I only needed two words to get what I needed as one of the suggestions :) Great stuff, thank you.

TV: TV episode performance limitation

2008-08-28T23:04:18.0000Z

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.

TV: TV episode performance limitation

2008-08-26T16:40:24.0012Z

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.

TV: TV episode performance limitation

2008-08-23T00:27:07.0012Z

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.

TV: Previous and Next Episodes

2008-08-23T00:05:52.0000Z

Yay, thanks Jeff!

TV: Previous and Next Episodes

2008-08-22T18:29:28.0000Z

The properties are there now. Have at them!

TV: TV episode performance limitation

2008-08-19T22:46:27.0012Z

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 :)

TV: Previous and Next Episodes

2008-08-19T21:51:12.0012Z

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.

TV: TV episode performance limitation

2008-08-19T18:38:20.0012Z

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.

TV: TV episode performance limitation

2008-08-19T17:15:04.0017Z

I ran into something of an annoyance when I started my freebase time filling out some Doctor Who cast lists. The "TV episode performance" requires a "TV Character". That's a bit much. There's always going to be credits entries like "Man In bar" or "Soldier #2". These aren't items that will need an entire "TV Character/Fictional Character/etc..." ontology - those entries require just a text string.

It seems to me there are two kinds of cast list entry - an actor performing a particular recurring character (TV Character Performance?) and performing an unnamed character (TV Extra Performance?). However the collection to formulate the cast list must order those in credits order - not as two separate lists, and must support reciprocal entries in either case (for instance, to support queries like "Which episodes of show X has actor Y appeared in?" (irrelevant whether the as a character or an extra).

Seems like this is an approach to handle the issue with "regular" appearances as well. There's one TV Character Performance node that says actor X has, at some time, portrayed character Y. All episodes where that's true, refer to that node. The reciprocal property on the TV Character Performance will enumerate all the episodes where that actor appears as that character.

TV: Previous and Next Episodes

2008-08-19T16:54:22.0012Z

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).

TV: Watch Online

2008-08-11T16:26:26.0012Z

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.

TV: Watch Online

2008-08-09T22:22:48.0018Z

I just added web links to the Monk topic to point to locations on the web (USA Network and Hulu) where the show can be watched online. Should this be a new property of TV Program or just keep adding them as web links?

TV: TV filming location

2008-07-02T18:39:23.0012Z

I think we should have a type, "TV filming location", for things like "Survivor: Vanuatu" which was filmed in Vanuatu. Thoughts?

TV: Suggested changes to TV character

2008-06-19T19:16:52.0012Z

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

TV: Suggested changes to TV character

2008-06-19T17:09:03.0012Z

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.

TV: Suggested changes to TV character

2008-06-19T16:16:31.0012Z

What would you guys say to moving actor and series up ahead of year of 1st and final appearance? The filter page defaults to the first 3 properties and these make for much more interesting filter criteria.

kevinhansen: Filipe Alves Ferreira

2008-06-18T08:45:18.0005Z

My ful name :

Filipe Alves Ferreira

My first school :

Escola Primaria de Lourosa - Portugal

My secondary school :

Liceu D. Manuel II de Porto - Portugal

My university :

Universite de Neuchatel - Switzerland

TV: TV Series "seasons" and other naming

2008-04-07T20:41:55.0007Z

Thanks -- that's a very interesting document. I like that they've modeled it as deeply as "episode versions". I doubt Freebase is likely to go that deep any time soon, but it's a useful concept in a lot of ways.

Superficially, it looks like the brand/series/episode model is very similar to our series/season/episode model, which is encouraging, and means that it should be fairly simple to create mappings between Freebase and applications using the Programmes Ontology.

TV: TV Series "seasons" and other naming

2008-04-03T21:59:15.0000Z

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.

jamie: BR_ESTATE

2008-03-19T20:51:36.0000Z

The sidebar can only display 50 types. To view the other types, click the symbol to the left of the word "Types" at the top of the list, and select "view all".

jamie: BR_ESTATE

2008-03-19T19:39:00.0005Z

Hi Jamie,

Could you add BR_ESTATE on side menu bar at Locations?

http://www.freebase.com/view/location/br_state

I working on it and ask for some friends to help, but without link the job is more complicate.

Tnks

Paulo Colacino

Geocode: should remove/deprecate datum property

2008-01-13T08:15:55.0007Z

thanks for the correction on nad83/grs80 vs wgs84. in that case i propose transforming the existing nad83 geocodes to wgs84, and then getting rid of the datum property...

the problem with using multiple datums is that most of the people writing queries have very little gis background, and many popular client platforms (e.g. browser javascript) don't have gis libraries. the google maps api, which will probably represent >90% of clients, can't handle anything but wgs84. so if the data is meant to be shared, it has to have wgs84 coordinates in a place where simple clients can find them.

something similar happened with the mixture of address and lat/lon as ways of expressing location. writing an application that could display and query both kinds of location turned out to be simply too onerous, and we started adding lat/lon info for locations that had addresses.

the datum property is an example of a property that is expert-friendly but novice-hostile. it's novice-hostile because it encourages the experts to store data in a format that isn't effectively shareable. worse still, it encourages experts to store non-wgs84 data in exactly the place that novices will look. if you forget to specify a coordinate system in your query (like most existing geocode mashups i've seen), you get a mixed bag of wgs84, nad83, and nad27 results, some of which will plot correctly in google maps. ugh.

i think a solution that would be friendly to both experts and novices would be to create a co-type (or co-types) of geocode that can express a variety of different coordinate systems - including projections like UTM. this might be as simple as storing the projection as a wkt string and calling the new properties something like "x" and "y" instead of the geocentric "latitude" and "longitude". but, you would need to maintain the wgs84 version of the same data in the lat and lon properties of the geocode object if you want simple clients to be able to use your data. at some point we will have a gis-aware process that automatically synchronizes the two sets of coordinates, but in the near term it has to be up to the sophisticated users to maintain interoperability through wgs84 - certainly not "at all costs" but hopefully as a high priority.

TV: Animated show?

2007-12-31T18:00:12.0007Z

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).

TV: Animated show?

2007-12-29T20:35:52.0005Z

I don't know if this belongs in its own domain, belongs in Media Common, or if Animated shows are just part of TV, but it would be nice to be able to enter other roles, like "Animated by" to TV shows.. my favorite is the fact that No Doubt's original drummer, Eric Stefani, went on to be a Simpsons animator.... but there's no way to represent this in freebase right now. There are other examples of famous animators like Mel Blanc that would be nice to connect to their TV work. There are over 150 people designated as "Animators" according to http://en.wikipedia.org/wiki/Category:Animators

Geocode: should remove/deprecate datum property

2007-12-09T04:01:51.0007Z

Would it be possible to list a default datum of WGS84 but allow users to modify that if they want? I really hope you don't remove datum because I could use it. For example, I might want to maintain metadata on various surveys that collected location data but some people may have collected the data using NAD27 while others collected them in WGS84.

By the way, the WGS 84 ellipsoid slightly differs from the GRS 80 ellipsoid which was used for NAD 83. For some users this may make a difference.

Geocode: should remove/deprecate datum property

2007-12-04T06:59:28.0000Z

a bot that converts other datums to wgs84 could certainly be written. but there would still need to be a different query for "get me the wgs84 coordinates" as opposed to "get me the coordinates in their original datum".
i would propose that the most important thing for now is to at least handle wgs84 sensibly, so the existing "latitude" and "longitude" properties should be reserved for the wgs84 coordinates. optional non-wgs84 coordinates should use different properties - note that utm coordinates are triples of (northing, easting, zone) so you won't be able to use the latitude / longitude properties sensibly for that datum (and others) anyway.

for users entering lon/lat points by hand, i bet always guessing wgs84 will give better results than asking users to guess what "datum" means. for gis file uploads, the datum is specified in the file and the service and clients must cope as best they can.

Geocode: should remove/deprecate datum property

2007-12-03T22:33:41.0000Z

I should add that I was thinking datum should be an enumeration of specific named datums.

Geocode: should remove/deprecate datum property

2007-12-03T21:00:02.0000Z

Nix -

Amusingly, I had recently suggested that the datum property be unhidden.

I agree that on-read you would like everything to be in wgs84. But I hate to prevent (or make it harder) for people to contribute strong geo data if they don't have it in wgs84. Other parts of the world have lots of great data with datums which have historically been more relevant to their corner of the earth. I had figured we could fashion a bot that would re-assert non-wgs84 data into a standardized form if enough non-wgs84 data appeared.

My thinking is predicated on the idea that non-geo people may have access to geo data with no idea how to transform it. It's possible this is a minority usecase and we should just standardize and assume that everyone who has geo data will find some way to transform it. It was this thinking that lead us to hide the datum property.

Do others have opinions?

J

Geocode: should remove/deprecate datum property

2007-12-02T10:49:04.0005Z

it would be much simpler for clients if we standardized on wgs84 lon/lat coordinates. allowing a datum here is like allowing arbitrary units for distance measurements - it makes it impossible to search since mql has no way to compare feet against meters, or wgs84 against utm.

fortunately nobody is taking advantage of the datum field yet so it is possible to nip it in the bud.
of the 220k instances of /location/geocode, most have no datum. 18k have datum "NAD83" (note that "wgs84" is equivalent to "nad83" for latitude and longitude, but less us-centric and better known to the average gps user). 5 have datum "WGS84". 18 have nonsense in the datum string.
so if all datum properties are deleted from the system nobody should suffer. deleting the property completely might affect some api clients but it could be hidden from the ui.

jamie: Tall ships and sailing boats

2007-08-18T14:19:47.0011Z

Hi Jamie,

I see you're doing some work around sailing vessels. I've been adding types related to tall ships and related subjects. We should chat!

I'm quite new here, and not entirely sure how developed this comment system is and whether it's a good place to chat, but please feel free to email me at skud@infotrope.net.

K.

TV: Previous and Next Episodes

2007-05-29T06:11:30.0006Z

We have considered it, but we've not had a chance to actually implement it. Generally, we assume that 'higher functionality' like that would be the purview of an application developer that's focused on a particular subject area, in this case Television. The Freebase app is really the 80% solution, where dedicated developers can do something far more specific.

TV: Previous and Next Episodes

2007-05-16T04:19:10.0006Z

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?

TV: Damn the Metaweb bot

2007-05-15T17:40:19.0006Z

If the multi-part episode links to its constituent episodes, each of which has its own production code and episode number, I think it might be redundant to ask for the same data in the multipart episode type itself. The exception would be, of course, if the multipart episode has a code or something that refers to the whole work (which does seem to be the case with Doctor Who).

TV: TV Series "seasons" and other naming

2007-05-14T21:28:47.0006Z

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.

TV: Previous and Next Episodes

2007-05-14T16:26:12.0012Z

Hi, can we add "Previous Episode" and "Next Episode" properties to the TV series episode type? In addition to capturing the sequential data on TV episodes, that would also be a useful navigation tool for browsing.

TV: TV Series "seasons" and other naming

2007-05-13T01:24:17.0006Z

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.

TV: Damn the Metaweb bot

2007-05-10T19:27:17.0006Z

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".

TV: Damn the Metaweb bot

2007-05-10T18:42:37.0000Z

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.

jamie: Apologies

2007-05-10T05:30:34.0014Z

I found and read what I was supposed to. Thanks.

jamie: How to typefy CSS

2007-05-10T04:27:45.0012Z

Jamie,
With the current selection of types, the CSS topic will remain an orphan. Do you think somebody on your side could create a type for Web Development , or something along these lines - other than Programming Languages? Thank you for the freebase!

jamie: How to typefy CSS

2007-05-10T04:24:30.0006Z

Jamie,
A topic called CSS (Cascading style sheets) is an orphan with the current selection of types. Do you think somebody on your side create a type, other than Programming Languages? I understand, that a dedicated type for Stylesheet Languages might be an overkill, so maybe Web Development?

TV: Damn the Metaweb bot

2007-05-09T03:57:29.0006Z

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.

TV: Damn the Metaweb bot

2007-05-09T01:16:42.0006Z

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

TV: Damn the Metaweb bot

2007-05-08T19:39:22.0006Z

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

TV: Damn the Metaweb bot

2007-05-08T18:53:28.0006Z

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.

TV: Damn the Metaweb bot

2007-05-08T05:41:01.0012Z

It didn't help that I was confusing myself by creating unnecessary personal types and getting unnecessarily complicated, but I figured out that the Metaweb bot has been "correcting" things for me. I'm working on an extensive Doctor Who dataset. I created a type to use called "TV Series Serials" because the early Doctor Who had episodes contained within the serial stories. Unfortunately, there are Wikipeda entries for each of the serial stories, not each episode, and you Metaweb has been importing them (and un-correcting them after I correct them) as episodes, which they are not.

Can you fix this? Or am I doing it wrong and supposed to fall in line with what the bot is telling me?

TV: TV Series "seasons" and other naming

2007-03-02T03:53:11.0012Z

The type "TV Series seasons" is oddly plural - it makes for some strange UI such as "Create New TV Series seasons" - perhaps it could be plural

Also, I'm finding myself wanting to type "TV episode" but finding it frustrating that I have to type "TV Series episode" to get autocomplete to match. I think a few of the TV types could add aliases (also known as's) with the word 'series' dropped to aid autocomplete

jamie: seeing double

2007-02-23T00:23:02.0006Z

Two heads are better than one!

jamie: seeing double

2007-02-22T23:02:29.0011Z

is it just me or is your picture showing up twice?