Discussions on Person

Not sure why its there. JG added it.

There are a lot of digitized signatures for historic people which are available through different collections. (See WP Infoboxes for instance.)

test

yogi

See the comments here: http://www.freebase.com/view/domain?id=%2Fpeople -- you should type your person as a 'deceased person' to get these properties, which will be removed from type 'person' shortly.

Would it be possible for us to do a mass co-type of all topics of type Person to Deceased Person if the date of birth is say, 1850 or earlier?

Currently 1 in 10,000 people reach 100. We could put this at 1890 and probably have no false positives.

Its simply a display option that type editors may have turned on or off. We'd like to have date of birth be 'restricted to one value' (see the display options for that property) but unfortunately we have many instances of multiple dates right now.

Interesting idea. Will chat about it with the other administrators on the person domain.

I like this too. I'll talk with Jeff over in the Book domain about this.

I like it too, and have a schema modeled, but there's a bug preventing me from implementing it -- hopefully, it will be fixed soon!

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.

Thanks Chris and Ed - it will take some time and experience I think to get a handle on it all. I've looked at the Type viewer and its very useful. It will be more helpful when I've created some types and added data and tried to run some queries. Its all very interesting. I think it will be easier from the users end if they can just ask questions and get some very detailed analysis in a short time.

  Thanks for all of your help and efforts on this project.

Ray 

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.

I think I understand this better now and yes adding multiple values will do exactly what you've suggested. It's what I was originally after.

Thanks 

We've talked a bit about the inclusion of such a property or type but there some issues around cultural sensitivity of doing something like this. We've had similar conversations about the appropriateness of a sexual orientation property or type. Beyond these issues, there is also some question as to how much these types or properties would actually be used.

Another approach, and one we might recommend instead is to create a collection like this one: http://www.freebase.com/view/?id=%239202a8c04000641f80000000051ff18b

This achieves the same result in a slightly different and more flexible way. You can create collections of anything in this manner - and these collections can be searched for or queried.

From my point of view - a collection is not more flexible from a search
perspective. It is a simple search - not a flexible one.

I think this would be valuable and interesting. I've been in quite a lot of discussions at tech conferences with, say, lesbian bloggers, or African-American bloggers, who want to be able to find each other; as parya mentions, this would be great to be able to search on. If we keep in mind that people are often in multiple races and ethnicities, even better. We shouldn't shy away from the difficult conversations about race that this type will bring.

This is a good suggestion, worth looking into. Thanks.

All we need are topics for the persons and the unmediated links between them. Starting with the information about Person-1, a user finds that Person-1 has a child, Person-2. The user can then discover the other recorded parents of Person-2 by examining the information about Person-2, in which information the user finds that Person-2 has a parent, Person-3 . What advantages do mediators offer in cases of this sort?

I agree with Etan. People can be born into or out of wedlock, and their parents may get married at some later date. If you know who a person’s parents are and you know their birthday, you can then make inferences based on marriages of the parents, but that’s about the best you can do.

A stronger argument for mediators is handling adoptive relationships as well as or instead of biological ones. That gets complicated.

What is complicated about handling adoptive relationships?

It’s a matter of what information is desired. Right now, we only have the parent/child relationship; it doesn’t say whether it’s exclusively biological or adoptive or either. That could easily result in people with multiple parents, or bad inferences, such as someone with two parents who were not married to each other until well after his birth; that could be an out-of-wedlock birth, or it could be a step-parent relationship. Genealogists, people looking for health information, and people curious about nobility would all want to know the specifics of the relationship. But on the other hand, particularly for living people, many people consider an adoptive relationship to be exactly the same as a biological one, and we need (IMO) to be sensitive to that.

It seems to me that the complication is already there, regardless of whether Freebase deals with the complication. Are multiple parents currently impossible? Are bad inferences currently impossible? Are people currently devoid of curiosity regarding parent/child relationships? To what degree will the company Metaweb control Freebase in attempts to avoid offending people? To what degree will the company Metaweb control Freebase in attempts to avoid conflicting or ambiguous data? In any case, what do mediators offer that properties do not offer?

In the absence of any qualifiers, people are going to assume that "parent" means biological parent.  It would definitely be useful to have adoptive relationships (with dates) included as well.  The two types of information are both useful.  As was pointed out, for some types of research (e.g. medical/genetic) only biological relationships are important.

On the opposite side of things, the "sibling" relationship seems undesirable to have stored explicitly since it can be derived from the other primary relationships. 

People may assume that the biological parent is intended, but the participants in most adoptive relationships prefer to have their relationship assumed to be equivalent to (if not identical to) a biological one. This is really a sort of privacy questions; the fact that you or I were or were not adopted is not of general public interest; the fact that Nicole Richie or Pax Jolie-Pitt are adopted is of broader public interest. This will probably be addressed in the near future by a division of the Person type into public and private sub-types.

I just discovered this reply after many months. Sorry for the delay!

In my opinion the privacy concerns are orthogonal and are a red herring here. The participants can believe whatever they want, but biological parents and adoptive parents are undeniably different relationships.

The decision to obscure the facts which our displayed for living people who aren't public personas shouldn't prevent getting the data accurate in the first place. That's not possible with the current schema.

Take a look a Gerry Ford http://freebase.com/view/en/gerald_ford?pid=%2Fpeople%2Fperson%2Fparents. Leaving aside the fact that his grandfather is also listed as a "parent" (apparently the work of mw_template_bot), how would you accurately model his family using the current schema? How would you tell his adoptive parents from his biological parents? How would you tell which female parent went with which male parent? Would all the half-brothers and half-sisters just get linked together in one big undifferentiated pile of "siblings?"

It’s less a decision to obscure the facts as a lack of a compelling use case for a more complicated model. The current model is simple and handles 95% of the use cases. To complicate the parent-child relationship—quadrupling the amount of information needed to represent it, in even the simplest cases—really needs a compelling use case. The blurb can tell human consumers that Gerald Ford was adopted. Is there a need for API-based applications to be able to make that distinction?

Hey, dvorkin. What do you mean by lifestyle? Whether the person is gay/straight/otherwise?

Hey, Sgmils!

I think gay and lesbian and straight it's more about sex preference, and i suppose that it's part of lifestyle. But lifestyle it's more than sex.

I think that lifestyle it's subculture preferences, clothing, dreams and so on.
sorry for bad english :(
Do you understand what i mean?

Can you give a couple of examples of lifestyles? That might help explain it.

#
Punk subculture,
Punk subculture
Lifestyle
The punk subculture is a subculture/counterculture based on punk rock. Since emerging from the larger rock 'n' roll scene in the mid-to-late-1970s in the U.K., the U.S and Australia, the punk movement has spread around the globe and developed into a number of different forms. Punk culture encompasses...
#
Do it yourself,
Do it yourself
Lifestyle
Do it yourself, often referred to by the acronym "DIY," is a term used by various communities that focus on people creating things for themselves without the aid of paid professionals. Many DIY subcultures explicitly critique consumer culture, which emphasizes that the solution to our needs is to purchase...
#
Bushido,
Lifestyle
Bushidō (武 士 道,Bushidō?), meaning "Way of the Warrior", is a Japanese code of conduct and a way of life, loosely analogous to the European concept of chivalry. It orginates from the samurai moral code and stresses frugality, loyalty, mastery of martial arts, and honor to the death. Bushidō developed between...
#
Lifestyle,
TV Genre, Media genre, Lifestyle
In sociology a lifestyle is the way a person lives. This includes patterns of social relations, consumption, entertainment, and dress. A lifestyle typically also reflects an individual's attitudes, values or worldview. Having a specific "lifestyle" means engaging in a characteristic bundle of behaviors...
#
Vampire lifestyle,
Lifestyle
The vampire lifestyle (or vampyre subculture) is a lifestyle, involving a number of customs and beliefs, followed (in various fashions and to different degrees) by a subculture of people who are attracted to contemporary vampire lore and who seek to emulate it. While some older occult and tribal cultures...
#
Backpacking,
Backpacking
Lifestyle
Backpacking (also tramping or trekking or bushwalking in some countries) combines hiking and camping in a single trip. A backpacker hikes into the backcountry to spend one or more nights there, and carries supplies and equipment to satisfy sleeping and eating needs. A backpacker packs all of his or her...
#
Adventuring,
Lifestyle
#
Downshifting,
Lifestyle
From Wikipedia.org Simple living (or voluntary simplicity) is a lifestyle in which individuals consciously choose to minimize the pursuit of wealth and consumption. Adherents choose simple living for a variety of reasons, including spirituality, health, stress reduction, conservation, social justice...
#
Traveling

I hope it will help.

Hi dvorkin,

I think the notion of lifestyle is too vague to turn into a type. The type would have basically no properties (that apply to ALL of those things you listed) and would just collect people with common interests.

I do think we should have some way to convey the interests of a person, but maybe through a tagging system rather than a strong yet vague assertion that they have this lifestyle.

Tristan

This is a fine idea for a new feature, although our focus will likely be on more generic import tools first. LinkedIn would certainly be a good source for historical employment data on people topics.

The 'safety' feature you describe may not be in the cards, however, as a person topic can be edited by anyone (just as other topics are) - with the idea being that this data will become more correct over time.

Zachary -

Good catch. These topics came in via Wikipedia and we are in the process of gardening them (removing/merging as appropriate) because, as you point out, they don't really meet the criteria of a Freebase Topic.

J

As noted above on the question about LinkedIn data, we're currently looking into ways to import data in bulk generically (say from .csv) which would most likely be the first import utility.

Geneology data is definitely intriguing for Freebase -- and also a bit more complicated due to the privacy issues.

There are many person topics in Freebase that only have the first and last name for the display name. However, it isn't a bad idea to include a middle name in the display name to help disambiguate two otherwise identical names.

You can also include full names in the 'also known as' field -- this is probably the best place for that because this field has extra weight in search and auto-complete results.

So the answer must be that I'm operating in the type instead of the data domain.

So how did I get there? I clicked on the high-level menu item "Data" (to the right of Home), and got to a page that has a list of things, the first one of which is:
# Person 507262
which indicates to me that there are 500K+ instances (data) of the Person type. So naturally, when I'm offered the chance to "Add a new person" I think I'm adding a new instance of type person, but that must not be what's going on here.
The shoot/explain offer remains open.

David, I think your assumptions are all correct; the only thing you’re missing is that, at the bottom of the list of candidates when you type a name, is an item “Create New Topic.” You need to select that to explicitly tell Freebase to create a new instance of Person, rather than just adding the Person type to an existing topic.

This is a tricky problem. Right now, we're just storing variant/alternative names in the "alias" property, which is better than nothing, but as you suggest, doesn't provide any real structure or information about those names. So adding some structure to this is appealing. But from a data-modeling standpoint, I have some questions about this approach: Should multiple middle names be entered as one instance of a property, or as separate instances? If the latter, how do we ensure they're ordered correctly? How do we differentiate between birth-names and names that were taken later (or should we make this distinction at all)? Asian names could probably be dealt with by finding culturally-neutral terminology for "first" and "last" names, although data input and reconciliation will be harder since the names are often ambiguously ordered when they're transliterated.

From a data-acquisition standpoint, I don't think we have any sources currently that model data this way, and doing an automatic extraction from, say, Wikipedia would be fraught with problems. We have, however, been discussing ways to handle pseudonyms/alternate names used by authors and musicians, which could presumably be generalized, and would at least address the pseudonym issue.

It would be worth reviewing the practices in the field of genealogy. Doing this in a culturally comprehensive way is non-trivial. Surname or family name and given name are more culturally neutral terms, but you also need to deal with ruf names http://en.wikipedia.org/wiki/German_name, dit names http://www.francogene.com/quebec/ditnames.php, other kinds of aliases (e.g. "William Smith alias Jones") , etc.

In addition to all the names a person used personally, they may also have been called different names in different languages or cultures (e.g. Charlemagne vs Carolus Magnus) where it is useful to have the name tagged with the language.

As with many such issues, there is a trade-off between the use cases and completeness. Having proper sorting, name semantics, etc., would all be very cool, but (a) where would we get this data, and (b) who would use it? These are not rhetorical questions; if there is a large store of such data and an interested user community, then it is worth figuring out the answers to these questions.
We could get sorting information from Wikipedia, as category inclusions often include that, and from MusicBrainz, which includes it for all musical artists. Is it worthwhile? How would we model it—as an additional text field, like alias?
Is there a large database of genealogical information that is reconcilable with Wikipedia and of general public interest? Does it have well-structured name information?

That’s a good question, Pierre. The trivial answer to your surface question is that we could add a new property to the Person type, or that you could make a new type for Famous Person with such a property.

Another interesting question is to ask what is the underlying matter of interest here? Jedlik was an inventor and the dynamo was his invention, while musicians are usually known for their music (though some may also be political activists better known for their political causes). So I made Jedlik an inventor and the electrical generator his invention. (This could be cleaned up with a separate“Dynamo” topic, a change that has only just happened this week on Wikipedia.)

Mike, the “Places lived” property points to a compound value type with start and end dates; is this sufficient for your needs? If not, what additional information would you like to capture? (For instance, to what type would you expect “Currently Lives At” to point?) Thanks.

Hi Chris,

 Thanks. Yes, that will work.  I am still learning about the site.

 Regards, - Mike

What is the convention for modeling dates when the start and end points are unknown?  For example, I know that someone lived at a place in 1985, but I don't know how much earlier or how much later?  Entering 1985 as either the start or end date will create an inaccurate and potentially misleading record.

That’s a good question. We don’t (yet) have a way to indicate variable certainty or at-least relationships; I would say that noting that they lived there is better than not, and that noting a start and end date of 1985 is better than no date at all. The dates can be changed as new information is learned, and an incorrect value is more likely to provoke a correction from the community than an absence of a value.

We do a lot of extraction from Wikipedia, but currently mostly from the structured information (Infoboxes and boilerplate sentence structure), and not much from natural language yet. The long term goal is open-ended: to gather as much information as we can. But it is like peeling an onion; we are getting the easier, outer layers now, and continuing to work down. Manual entry like yours for prominent topics is definitely an important part of the process, so thanks for contributing those data.

This is a subject of some confusion; see also “Hinduism and Hindu.” It may be worth revisiting this structure.

The linguistic arguments are not the right approach, though, IMO. There are things one can say about Catholicism, as a concept, regardless of its label (or the language of that label), and things one can say about Catholics (again, regardless of the label or language), and they are two distinct concepts.

Followups are probably best discussed in the Religion domain.

Change banks. Seriously! Your bank has indicated that they really don't care about the security of your money or your personal information. Information like this is widely available from sources other than Freebase.

If you're going to keep the same bank, just lie. They don't care that you said your mother's maiden Deep Azure Blue or Rugby Union. They're just going to check that the response to the challenge matches what you gave them originally (of course that does somewhat defeat the mnemonic value of using easy to remember challenges).

For the more general question of personal data, the approach used by things like WorldConnect (wc.rootsweb.com) is a good starting point. Don't publish personal data on people who are still alive (unless they are a public persona).

We actually had a property for this once-upon-a-time, but it seems it was deleted. I think it's interesting data, too.

This is a good point, but is kind of related to the general question of time-varying properties. For now, they should be the present height and weight, if known, or the most relevant (per community consensus, e.g. an athlete’s height and weight at the peak of their career) otherwise.

We are working on the general challenge of varying properties. 

Most dictionaries define "person" as a human being, for what that's worth. My impression is people (defined as "humans using Freebase" for purposes of this post) will understand what is implied by the type "person". Naming the type "human" seems, well, impersonal to me. But maybe I'm not familiar enough with the arguments you're alluding to. What other types of things might it be confused with?

The discussion fora are a fine place to ask questions. I don’t know if the discussion about Person is the best place for this question, but it’s fine.

The thing attached to the “Spouse (or domestic partner)” property is not a Person, but rather a Marriage. The Marriage is a compound value type connecting two (or more) Persons, as well as other information such as the start and end of the marriage. Since the Marriage CVT doesn’t have a name on its own, the simple form of the query doesn’t have anything to display.

You can try this instead:

"spouse_s" : [ { "id" : null } ]

to find the marriage itself, or:

"spouse_s" : [ { "spouse" : [] } ]

to find the participants in the marriage. The problem with that latter approach is that since the Person from which you’re starting is in the marriage, you will see him or her again; for instance, from Bill Clinton, you will find that his marriage includes Bill Clinton and Hillary Clinton.

CVTs are a powerful design pattern in Freebase, but can be a little tricky to use. The help topic linked above should be of some help.