Discussions on Person
Start a New Discussion
-
-
Add "from-to" to religon property
-
I can see why it would be useful to record the to and from dates of someones religious affiliation in order to be able to say which one is the most recent. However, I doubt that most of the people topics in Freebase would have this sort of information available.
The only area where I think this would work well is for celebrities. You should check out the Celebrity type in the Postra base. It has exactly the sort of property that you're looking for. For eaxmple, Britney Spears' many religious affiliations.
-
-
-
If I'm adding a kid, it's now asking me for date of birth, country, etc. Why not gender too?
-
+1, gender is the most likely other bit of additional info that someone knows (or is able to easily deduce) about a person. It would really help reduce the amount that has then to be processed by genderizer.
-
-
-
I propose to add "Language(s)" for Person. It's important for everybody, as imporant than ethnicity-nationality, religion, education. In some fields, it's essential like in arts. A "french" writer could live in many countries as a english one. Nabokov, borned in Russia, wrote in russian, english and french.
Thanks.
-
+1
-
Good idea, but there is complication if we need to differentiate between levels of proficiency in the language.
-
There's also often a difference in proficiency among reading, writing, and spoken language skills.
-
+100
-
...and i say no mapping of proficiency yet. either they speak it or they dont. that would be way too much detail....
-
What would be the use case for this? Where would we get data from? I'm interested in understanding how it would be used.
-
-
-
I would have thought that conjoined twins should be two people, but a lot of topics for conjoined twins are single topics - is this just an artifact from copying articles from wikipedia?
-
I've created a view for spotting likely Person topics for split.
-
Yep, all the topics came straight from WP. I have been experimenting with a look-alikes base that has such twinning in its schema. I think there should be a topic for both the individuals of and one for cojoined-twins as a partnership. Same would/could be possible for identical/near-identical twins, often employed in tandem for entertainment purposes.
-
-
-
Seems like these concepts should be in there.
-
I agree that they would be useful attributes to have.
-
What colour would you list my hair as?
-
dark brown or black
-
maybe its better called "natural hair color"
-
Did you mean "color" ? :-)
I'd go with whatever it says on your passport/driver's license.
-
Neither my passport nor my driving licence say what colour my hair is (and I don't think there's any other sort of official documentation which does).
-
Mine neither. I think maybe it's a US thing?
-
My (US) drivers license has hair color on it. I'm too lazy to look for my passport. Natural hair color seems like the simplest thing to model, but would anyone really expect to find Heather Locklear in a list of brunette actors?
-
-
-
-
-
So I don't want to start a huge technical debate here, but I think it's confusing that Caucasian and White are completely separate topics in our system.
I know there are slight technical differences in the terms that we could spend a long time talking about, but do we ever really need to distinguish between the two of them? If not, what do people think about merging the two into an ethnicity called "Caucasian/White"? Or if Caucasian is a superset of white, maybe we could just delete White and add it as an AKA for Caucasian?
I'd just like to make sure that it's easy for people to fill out the Ethnicity field for Caucasian/white people. Right now, I think it requires too much unnecessary thought.
-
There's already a phylogeny pattern to let you specify "Included in groups" or "Includes groups". Generally speaking with ethnicities I have taken a pretty open approach to it; I think it was zenkat (Brian K.) who added ones like "Texan" and "Hillbilly".
-
+ for merging to Caucasian/White - filter views are skewed by having both - data entry is confusing. For example for every person Mike O types as Caucasian I've been using White.
-
-
-
How could we specify the percentage of ethnicity of mixed race people? e.g. white 50%, black 50%.
-
If this is ever implemented, is there a way to automatically calculate a person's ethnicity percentages by the person's parents' ethnicity percentages?
-
It could easily be modeled as a compound value type (CVT); see the Religion Percentage, for example, for describing the religions among a population of a region. I’m not sure how useful it would actually be, though; most people don’t know their exact makeup, and aside from genealogy uses, I am not sure what use it would have.
-
-
-
I suggest that the children property use a mediator rather than directly linking to the person. This is currently done for marriage (useful) and sibling relationships (not so useful right now, since there are no additional properties on the mediator). Children (and siblings) can be the result of a specific marriage or a specific person. There's no way of knowing where a person's children came from if they have multiple marriages.
-
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?
-
Another long delay - I need to remember to login in more than once a month (or figure out how to get RSS feeds set up).
I guess the real answer to whether the accuracy is needed depends on whether Freebase has aspirations to hold genealogical data. The current scheme isn't adequate for anything genealogical, including medical applications which need genealogical information.
I tend to lean towards the "if you're going to do it, you should do it right" camp, but I recognize that that often leads to over engineering. I don't know anything about how Freebase stores things internally, so it's difficult to evaluate where the "quadrupling" comes in and how big an impact it has in real world terms.
On the other hand, no one's addressed the sibling side of the argument. That could clearly be derived from traversing the parent-child graph as well, yet it seems to have been important enough to record separately (and redundantly).
That's enough lobbying for me though. If anyone ever decides to change the decision, ping me and I'll provide pointers to how things are modeled in the genealogical data world.
-
-
-
While it seems to make sense that the main name for a person be the arbitrary string most associated with that person, shouldn't this database, like almost every other application that references people I know of, break the name down, i.e., have separate fields for first, middle, last, and post (like III or jr), and then another for "nickname," and yet another for alternative name(s) like pen name (e.g. Mark Twain/Samuel L. Clemens/Sam).
-
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?
-
-
-
Crossposted from the data-modeling mailing list...
A while ago I signed up for online banking and, as online banking systems tend to do, it asked me not only for a password but for some additional question/answer pairs to help me sort things out if I lost or forgot that password. I looked at the list of suggested questions, and saw things like:
- Mother's maiden name
- Your high school's mascot
- Town where you were born
It occurred to me that almost every item on that list of questions was something that you could find in Freebase, if a person's properties were filled in completely. As you can imagine, this could be a bit scary if someone used the information in FB to login to your online banking.
When you sign up for Freebase you get a "user profile" and then there's a field to link it to a "Person topic about me". That person topic then lets you fill in your mother's maiden name, your high school, the town where you were born, and so forth. I suspect that some people do this a bit naively, hardly thinking about how it could be used for identity theft. (None of *us*, of course! Me, I filled in my mother's maiden name in the full and complete knowledge that the world can use it to access to my bank statements ;))
But now my mother and father have nodes in Freebase, and what's to stop someone coming along and filling in *their* mother's maiden names, high schools, etc? Or for that matter, points that might be sensitive for various reasons, like "weight" or "religion"?
So there's been a bit of discussion around the place about changing the "Person" topic to be less privacy-invading, and moving some of the properties to a new type called "Public person", which we can use for well-known public figures and famous people whose privacy is, let's face it, already pretty well invaded. That way we can record the weight of professional athletes or celebrities with eating disorders, or the religion of Presidents of the USA, or the genealogy of historical figures, without doing the same to ordinary people like you or me.
If we did this, we'd probably then go through and type anyone who has a Wikipedia article as a "public person" for starters. If they meet Wikipedia's notability criteria, then their birthdates and so forth are probably public knowledge anyway. Also, we'd need to write a FAQ or guideline somewhere about what makes someone a public person, and when you should (or shouldn't) apply that type.
Anyone got any thoughts on this?-
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).
-
-
-
(n00b question, might be wrong forum, sorry in advance, pointers in the correct direction appreciated, etc.)
Anyways, why do some relationships return a null name field? For example, spouse_s, sibling_s, etc. That is, for a query such as the following, the name field comes back null.
{
"query" : {
"/people/person/spouse_s" : [
{}
],
"id" : "/en/bill_clinton"
}
}(yes, I know...insert Bill Clinton joke here)
But I can get Chelsea's name from a similar query for /people/person/children. This seems to imply that I need to get the guid from this query, and re-query for information on Bill's spouse (and siblings, and some others that seem to return a guid+null name)
-
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.
-
-
-
There's some room for argument as to whether only humans should be persons? Perhaps something more like Humans, rather than Persons would be slightly more accurate/appropriate?
-
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?
-
-
-
I don't think that height and weight should be included in person's properties as they are highly variable and can not be easily fixed to particular event or age of that person.
-
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.
-
-
-
-
Should we capture the announced, official or legal reasons for a marriage's end? I guess it would be less certain for the unofficialized unions such as domestic partnership.
Just mourning the end to yet another beautiful celebrity relationship But I think at the least it would be interesting to have the various historically significant anullments, divorces, and estrangements captured and searchable. Henry VIII and Catherine's breakup certainly had a tremendous impact on history.
Catherine of Aragon
m. 1509 - 1533
Divorced
Anne Boleyn
m. 1533 - 1536
Executed
Jane Seymour
m. 1536 - 1537
Died
-
-
-
What do y'all think about adding Handedness (Left, Right, Ambidextrous) to Person? There are many data sources out there to start populating it, e.g.
http://en.wikipedia.org/wiki/List_of_famous_left-handed_people
http://www.indiana.edu/~primate/left.html
-
-
-
The current typing of religion seems awkward to me. It lists JFK's religion as "Catholicism" when, if he were asked what religion he was, he almost certainly would have said "Catholic," or more likely, "Roman Catholic." In addition to the phrasing (perhaps using the "adherent" form would fix that), the loss of specificity doesn't really seem desirable. In real life, people probably do consider themselves affiliated with a specific church (in the sense of an administrative hierarchy, set of policies, etc as opposed to a buliding), not just a generic religion. It looks like things were refactored a while ago to remove this level of specificity, which doesn't seem like an improvement.
-
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.
-
-
-
I was looking at the JFK & Jackie entries as examples of People. There seems to be a fair amount of information in the text body which is not represented formally in the database. Examples include AKAs and family relationships. When I went to add Jackie's parents I discovered that they were already in the database (because they have Wikipedia articles of their own), but they weren't linked.
Is any attempt made to automatically extract information from Wikipedia when the articles are downloaded? They do include active hyperlinks to the parents' articles, but these links aren't typed in any way. Will manually entered information get overwritten the next time a pull from Wikipedia is done?
What is the long term goal? Clearly it's much easier to generate the text from the database ("Her parents were __") than the other way around. What are the steps along the way towards this goal?
-
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.
-
-
-
Could you add a "Currently Lives At" Property to capture where a Person currently lives (or resides)?
-
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.
-
-
-
The new profession property has me thinking about the other properties and types related to employment. For example, the topic "George W Bush" has career information divided / duplicated in the following areas:
types: us president, us politician, military person
employment history (a property of person): empty in this case
offices held (a property of us politician)
and now profession (a property of person).
Filling out a new entry, I imagine, would be confusing for a new user. How would they know where to put what info, and when they should enter duplicate info?
Similarly, reading a fully populated person topic, how would a novice user know which ones to look at to figure out what the person does?-
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
-
-
-
What is the best way to add a "known for" attribute ? For example I wish I could add "Known for:"Dynamo to Ányos Jedlik
Thanks.
-
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.)
-
-
-
But when I'm on:
Domains & Types People Person
And I click the action "Add a new person," a box appears with the cursor in it. This fact tells my simple little mind that this is where I get to enter the name of the person. So I start typing, and it helps me with values already in the database, none of which are the new person I wish to add -- in my simplistic way of thinking, this is the main reason to "Add a new person." If I finish the name and hit the Enter key, the top item in the suggestions list is entered, over-writing the name I've entered. If I finish the name and click "Save", I'm told to "Please choose an item from the popup list."
So then I think I've got it figured out because there's this little symbol to the left of the data entry box, and I realize it's supposed to be a foreign key, and maybe I'm supposed to enter the type of the person first. So I start entering "person" and there are lots of types. So I think I've got it. I pick the main person type & save it. Only then I see this: "Person has been added as a Person.Go add more info!" So I'm blocked! Again!
Is this any way to run a data entry field? If it's my stupidity, please shoot me, or if you're not close enough, at least tell me what I'm missing?-
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.
-
-
-
I started to enter some genealogical info (about my immediate family) into Freebase to try it out. One issue that I'm wondering about is what to do about names. There are a number of people in my family tree named "Gregory Stone". Should I use "Gregory Stone" as the topic name for all of them? Should I include everyone's middle name in the topic name? Should I do that only when needed to avoid ambiguity? What's a good convention here?
Also, regardless of what I use as the topic name, it seems like there ought to be a place to store the full name of each person. ("Professor J. Arthur Xavier Randolph van de Horton III", for example.) Can a "Full name" property be added to the Person type?
Since Freebase could someday contain nearly every person that ever lived, linked into a big tree, it seems like we need a good system for naming them.
-Jesse-
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.
-
-
-
I suggest add this type for person.
But i think that lifestyle type need some editing and discussion.-
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
-
-
-
There are a number of topics without a type named "political views of ..." There is a proposal to link in a political ideology type but that would be difficult at best. No one would agree on the type even in the case that someone describes themselves as having that particular ideology. It seems to suffer the same problems as the "lifestyle" type. Maybe just a text field would be best. At least the two topics would be linked.
-
-
-
Have you considered allowing people to import a Personal Ancenstory File from a geneology program to populate the people section? Although there is some around merging data this tool could be a revolution for geneology research since you are commited to open source documentation.
I have linked over 10,000 names in may family tree many including birth, death, marrige location, etc.
If you import a feature like this you may consider excluding some details on records that don't include a death date to protect personal privacy but I think this would tie into a great application.-
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.
-
-
-
will it be possible to import the employment history of a person from his/her matching profile at Linkedin?
one can assume that what a person writes at LinkedIn (and other services like it) will be true (at least to some extent), so it would be useful to have this data easily uploaded.
of course there should be some sort of safety feature to make sure you upload only your own public profile from there, or something like that.
Thanks,
Doron.-
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.
-
-
-
It might be nice to have this type since it different from nationality and people are often interested
in finding some one by this sorting factor " a writer of Indian descent".-
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. -
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.
-
-
-
Now that we have a type for Patents, with the inventor field pointing to an instance of type person, it would be nice if person listed patents associated with the individual.
Here's a link to the patent type:
http://www.freebase.com/view/filter?id=%2Flaw%2Fus_patent
-
-
-
Do we have a way yet to associate quotes with people?
I was just trying to search for the origin of the phrase "Insanity is doing the same thing, over and over again, but expecting different results." I hear it quoted regularly (and referenced many places throughout the web) but not reliably attributed. (Ben Franklin and Albert Einstein both get credit for it in various places - two of the best people to associate random quotes to if you want them to carry extra umph.)
I finally found an attribution to Rita Mae Brown, from her book Sudden Death, and it occurs to me that the source of a quotation could be a search Metaweb would really shine with.
I am just starting to play with Freebase, but I could imagine Quote as a Type, associated with people (or with certain sub-classes of people, like authors) and/or perhaps with various media (books, music, songs).Thoughts?
-
-
-
I've come across person entries where the person is dead and I wanted to enter this info, but the date and place of death, while specified in the schema, are not set to "display by default."
We hid these fields (unselected them as "display by default") during an older software rev, when all fields were displayed whether they had data or not. At the time, it seemed morbid to display "date of death: [blank]" for clearly living people :)
But now, empty fields are hidden, and I'd like to see date and place of death come back as default properties for the person type so I can enter data for these fields. They're there in the schema. Can someone bring them back as "display by default?"-
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.
-
-
-
In an effort to help people better understand the relationship between a person and a user in Freebase, I've chosen to display the property (which was already linked from user profile to person) -- for the vast majority of 'person' topics, this will be blank and not displayed -- but for all Freebase users, the username will show up on the corresponding person topic.
-
