Profession property

These are all good questions. The problem we're trying to deal with is that most occupations are not represented by types. A type should exist only when there are properties associated with it. This is true of US Politician and Film Actor, but not of Taxi Driver or Computer Programmer (for now). The profession property on type person allows users to enter these professions.

This raises a bigger question about what happens with redundant data or at least redundant representations. For now, the assumption is that the users entering data will add types for professions that require them and enter the profession property value for those that don't. Soon, we will create a gardening script that enforces the 'denormalization' -- that is, if the topic is cross-typed as "Film Actor" that will be added as a profession to the profession property so that users can just look there. This will also make queries work correctly.

This pattern will most likely occur in other places throughout Freebase/Metaweb.

Is it possible to add a property called "Background" (or something similar) that would link to Profession as well. So Politician could be the shown as (current profession) and Lawyer could be listed as background.

Ray, note that the “Profession” property can have more than one value. Would that suffice? Many politicians, for instance, still nominally practice their other professions, so a particular person could have both Politician and Lawyer as their “Profession.”

Okay that helps - another throw back to RDBS stuff. It will take some time I think. But I'm enjoying the challenge. Is there a name for this approach to data?

I think it's a graph network but I'm not the best person to answer this question. However, I thought it might be helpful to mention the Freebase Type Viewer. That tool has been very helpful for my visualization of data connections.

As Ed says, the data is all a graph, a network of relationships between concepts. From a relational point of view, you might consider unique properties (such as “Date of Birth”) to be columns in a table, but non-unique properties (such as “Profession”) to be separate tables. One important exception to that, of course, is that Freebase isn’t schema-bound; the unique property can become non-unique, and vice versa, without rebuilding all the data.

Just a general note on the "profession" property -- in addition to accepting multiple values, I don't think it's limited to only current professions -- retired people, for example, generally have no current profession, but it's useful to know what profession(s) they practiced during their working years.