I’m just pottering around filling out my new Historic Period type, and looking up the dynasties of Ancient Egypt. For each dynasty, I can note its start and end dates, which other dynasties preceded and succeeded it, and what important events occurred or people lived in the period.

The fun comes when you get to filling in the important people. Take Nefertiti for example. Spouse: Amenhotep I. Employment history: Consort. But who’s her employer? I put down Amenhotep, but I’m not quite sure that’s right. If Nefertiti, as consort, was employed by the pharaoh of the time, then is Prince Philip employed by Queen Elizabeth II?

I love it when Freebase gets mushy around the edges.

On Wikipedia, one of the great tensions is between deletionists and inclusionists. The debate is over whether Wikipedia should include everything, or only things that are important enough for a “real” encyclopedia.

On Freebase, we don’t have this problem. As far as I can tell, Freebase is about as inclusionist as it’s possible to get. I usually express this to people by saying, “As far as I can tell, they want 6 billion person topics — or probably twice that, to allow for dead people.”

On the other hand, the first tension I’m seeing emerge on Freebase is that between normalisers and normal people, and I’m seeing it play out in a few discussions that are going on at the moment.

In the comments on my post about gender I linked to a thread on the data modelling mailing list: Should some of the Person attributes be moved to Organism?

Here’s what I said in comments:

Aristotle: There was a related discussion thred: Should some of the properties of Person be moved to Organism?

Someone facetiously commented, “I immediately began wondering which celebrities would get marked as hermaphroditic or asexually reproducing”, which of course is one of the risks of over-generalising.

I think there’s a tension in Freebase, taking a very broad view, between models that tend towards abstraction and those that tend towards how people think day-to-day. We encountered this when Jeff P was modelling Government, and had an abstraction which was kind of theoretically valid across many government forms, but left some of us (esp. those from countries whose governments use the Westminster system) scratching our heads and saying, “but nobody in Australia/Canada/UK *talks* like that!”

In the case of sex/gender of human beings, there’s probably 99% of cases where people just want to be able to say male/female, and confusing them with a list that includes “intersex” and “asexually reproducing” would just boggle them. Male/Female/Other is a reasonably well-precedented pattern for use in forms etc (though I’d want to get some trans people’s views on that to make sure it’s what they’d want) while not being overwhelmingly technical.

As mentioned, we had a similar problem with governments. Jeff Prucher had put together an abstract model that was theoretically workable but which didn’t match well with the way I thought about government. I found myself having to twist my brain to make things fit. I’d get there eventually, but I couldn’t enter the data naturally and smoothly. It was like having to translate into a different language on the fly.

Jeff’s since put together a second government test domain which seems to work better for a wider range of government styles. The differences are relatively small, as far as I can tell without being able to look at the first model (it’s been made private again), but the difference to me as an end user are like night and day.

From what I recall of the two government models and the changes between them, and from other normalizers-vs-normals discussions that I’ve seen, I’d like to propose some techniques that seem to minimise the conflict:

• Talk like a lay-person. The use of good type and attribute names, ones that don’t require translation by users, makes a model friendlier to “normals”. Even if you make no other design changes, this can make a big difference.
• Support the vast majority. Like Perl’s motto of “make the easy things easy and the hard things possible”, you should first try to support the vast majority of cases in a way that’s easy to use, then deal with the outliers. Make your main type support the vast majority, and make a second type for the rare misfits and co-type as necessary.
• Love your CVTs. The extensive use of Compound Value Types seems to be a common feature of models that feel natural to normals while still being elegant data modelling solutions.

Anyone got any other suggestions?

If you go to edit a Person in Freebase, there’s a field for “gender”. The current choices are “male” or “female”, and it’s a fundamental Freebase system type, which means that you can’t add new ones. Nor can you choose more than one.

Regardless of whether you buy into it or not (and you won’t be surprised to hear that I do), there are many people, groups, and indeed entire cultures that have more complex models of gender than a simple binary model.

• From a purely biological viewpoint, some people (or organisms) are actually hermaphroditic or intersex, having some male and some female biological traits
• In modern Western societies, many people undergo sex reassignment therapy (aka “sex change”), meaning that they might be male for one period of their life and female for another period.
• During the transition some of these people are both/neither, and identify as transgender or other related terms.
• Some people like to stay in the “transgendered” place, and live as neither (or both of) male or female long-term or permanently.
• In some cultures, a gender which is neither (or both) male nor female is widely acknowledged and used, eg. the Native American two-spirit concept.
• There is a general understanding in academia of the difference between sex (biological: what chromosomal make-up and/or sex organs do you have?) and gender (what role do you perform in society?)
• The example of women who dress and live as men (of whom there are some very famous examples, some not discovered til their death) gives us a situation where sex = female but gender = male.

I’m not actually an expert on this, just a reasonably well-informed layperson, but obviously it’s way more complicated than the simple male/female binary currently expressed on Freebase.

My feeling is that as a first step, “Gender”, the system type, should have an “Other” option (if not a more complete list). The next step, I suspect, is to create a “Transgender Person” type, which allows for gender identity to change over time.

I’m playing with some of this in a personal domain if you’d like to come comment or take a look.

The other day, while organising the Melbourne, Australia Freebase gathering I found myself wanting to know all the Freebase users in Melbourne and, ideally, their email addresses.

Well, the first part is easy enough. Here’s the MQL for it:

{
  "query":[{
    "location":"Melbourne, Australia",
    "name":null,
    "type":"/freebase/user_profile"
  }]
}

The email address, however, proved impossible. Freebase doesn’t store email addresses anywhere publicly available, and I guess I can see why. The potential for spam is greater even than putting an email address on an ordinary website, because the spammers wouldn’t even have to crawl the site. They could just programmatically ask for a list of email addresses:

{
  "query":[{
    "name":null,
    "type":"/internet/email_address"
  }]
}

Or, if they were actually trying to market something to people who cared, say women of a certain age group:

{
  "query":[{
    "name":null,
    "type":"/internet/email_address",
    "person": {
        "sex":"female",
        "a:date_of_birth>":1970,
        "b:date_of_birth<":1980,
    }
  }]
}

(Code is an example only, untested and untestable, and almost certainly syntactically incorrect in the date constraints because I don’t think dates work like that.)

Now I, for one, would actually prefer to get spam about drugs for menstrual cramps rather than ones offering me a larger penis, but most other people seem to disagree, and consider it a huge invasion of privacy to think of spammers being able to search on their personal details.

On the other hand, there are some valid reasons why you might want to store email addresses in Freebase. Contacting Freebase users is one reason: I would quite like other Freebasers to be able to email me if they want to get in touch privately, and I expect that many of those Melbourne users would’ve liked to know about the upcoming meeting. You’d want the publicity of a user’s email address to be configurable by them, and private by default, but it’s by no means an obscure use case.

Another reason is that some types might fundamentally be about email. I was modelling CPAN Authors a while ago, and one of the very few data points recorded about contributors to CPAN is their email address. That information is already available in a public database of sorts, so there’s no real expectation of privacy there. Or what about mailing lists? A model for “mailing list” might reasonably want to store “posting address”, “subscription address”, and “admin address”. Or it might be nice to store email contacts for political representatives, so that their constituents can email them about issues of importance.

I’m sure there are a thousand reasons to want to record email addresses in Freebase, and there’s only one reason not to… but it’s a biggie. I wonder what solutions to this problem will emerge?

This is interesting. Freebase user Peter von Stackelberg has been working up a whole domain full of types related to Future Studies and Forecasting. I came across his Event type while considering historical events.

I’m not any kind of formally trained historian, but I do enjoy history and I’m quite interested in it. When I consider historical events, I want to know when they happened, where they happened, who was involved, and whether they were part of any larger event. (For instance, the Battle of Trafalgar occurred during the Napoleonic Wars; the death of Horatio Nelson occurred during the Battle of Trafalgar.) I started out modelling these in Historical Event (skud’s types); see Battle of Trafalgar or Nuremberg Trials for an example of my type in use.

It seems like Peter’s forecasting event has some of the same critieria, especially the “when” aspects and the ability to nest events within each other. However, he’s added fields such as “supports trend” and “opposes trend” for use in forecasting — his particular field of interest.

Meanwhile, I’m considering adding “commemorative event” (eg. Trafalgar 200 for 200th anniversary of the Battle of Trafalgar) and “historic site”, possibly subtyping that using National Historic Site or Protected Site, or co-typing with something like Listed Site.

All this makes me think that what we really need is an “Event” type which we can use as part of “Historic Event” or “Forecasting Event”. This will require further consideration.

I recently spent a year working for a real estate search engine company that dealt with property listings in a number of different countries, ranging from England to Indonesia. While I was there I learnt a few things about location data which I think have some bearing on Freebase.

The most important thing is that concepts of location are culturally dependent. In Australia, like the US, we have States. In Canada it’s provinces. In the UK it’s counties. In Fiji, they don’t have any such administrative divisions, just a bunch of islands. If you’ve ever tried to order something online to ship to another country you’ll know what it’s like. “State? I don’t have a state! And what’s this zipcode thing?”

When the original version of the real estate search database was designed — long before my time — the people involved were only really thinking about Australia. They decided that every listing would have a suburb, a state, and a postcode of 4 digits. Obviously this soon started breaking when the company started spreading into other countries. When the new database design was made, just about the only thing they found common among all the culturally diverse ideas of location was this: Locations may contain, or be contained by, other locations. You can see this reflected in Freebase’s Location type — along with a few other attributes, such as “adjoins” and “area”.

It’s only when you start getting into culturally specific ideas of location that you see things like “capital city” or “postal code” or “governor” — attributes that reflect anything other than the pure geometry of the space.

I’ve been messing around a bit with Australian-specific location types, which include “Location” or, when appropriate, “Administrative Division”. You can see them here: Australian State, Australian Territory, and Australian Municipality (which I might rename to Local Government Area, I’m not sure.)