You know how when you look at a topic, some fields are in the main area of the screen just near the image, and some are on the right hand side?

I used to think that anything that permitted multiple values went on the right, but it turns out that’s not so. Here’s the skinny on what’s really happening, thanks to Jeff:

You can actually specify which column a property appears in in the schema editor. Left is “horizontal” (because multiple values are displayed next to each other, separated by a comma), right is “vertical” (because multiple values are displayed above and below each other). The default layout is that properties for which the expected type is a primitive type (date/time, integer, text, etc.) display on the left, and everything else displays on the right.

(from this discussion about countries’ official languages.)

So, to summarise:

System primitives on the left.
Horizontal multiples on the left.
Vertical multiples on the right.
Non-primitives, even if single, on the right.

Tags:freebase metaweb ui user interface

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?

Tags:

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.

Tags:freebase gender genderqueer intersex metaweb queer transgender

MQL, the Metaweb Query Language, is what we use to talk to any Metaweb database such as Freebase. It’s the guts of any Metaweb API, such as mjt or my own Metaweb CPAN module for Perl, but you can also use it standalone in the Query Editor.

I want to run a series of tutorials on MQL, taking a cookbook approach. Essentially, as I learn stuff, I’ll post it here in tutorial form.

Today’s topic: a simple “read” query

First step, open up the Query Editor in your browser. The empty box on the left is where you type your MQL. Then you click “Read” and the response will show up on the right.

Here’s a simple query to cut and paste:

{
  "query":[{
    "type":"/people/person",
    "name":null
   }]
}

This query is asking for a list of all objects of type “/people/person”, and saying that we want to know their names. The overall format of the query uses the JavaScript Object Notation, or JSON. For the most part, the format consists of name/value pairs, and some syntax for grouping lists of those pairs together.

Let’s take our example and break it down further.

“query”:[{ ... }]

All MQL queries need this wrapper around them, to group the query parameters together.

(If you’re using an API rather than the Query Editor, you may also need another envelope around this; see the API docs for details.)

“type”:”/people/person”

Here we limit our search results by the type of object we’re interested in. The type is expressed in the form “domain/type”, which is how the system refers to types under the hood. If you’re not sure of the underlying system name for a type, you can find it by browsing the Data page and getting to the type you want, then looking at the URL. The last two segments of the URL will be the domain and type, eg. “http://www.freebase.com/view/filter/people/person”

“name”:null

This says, “We want to know the name, but we don’t have any particular constraints on it.” So the results we get will list all the names of every object returned.

Now you can click the “read >>” button and see the results. It should look something like this:

  "code":"/api/status/ok",
  "result":[{
    "name":"Jack Abramoff",
    "type":"/people/person"
  },{
    "name":"Bob Ney",
    "type":"/people/person"
  },{
    "name":"David Safavian",
    "type":"/people/person"
  },{
    "name":"Kåre Kristiansen",
    "type":"/people/person"
  },

… and so on. You can click on different views, eg. “Tree View”, “JSON View”, etc. The one I’ve pasted is the JSON view.

Try this

So that’s the most basic form of query. Now you can try some queries of your own:

1. Try searching other types, eg. “location/location” or “internet/website”.
2. Try adding adding the “id” field to your query: "id":null
3. Try limiting the output: "limit":10
4. Try sorting the output: "sort":"name"

What I’ve covered in this tutorial corresponds roughly to the most basic parts of section 3 of the API docs. If you want to read more, that’s where to do it.

Tags:api freebase json metaweb mql programming query tutorial