Discussions on Data Modeling Guide

You can query against the timestamp, something along the lines of:

[
  {
    "name" : null,
    "timestamp" : null,
    "timestamp>" : "2008-08",
    "type" : "/film/film"
  }
]

This returns films that were added this month.

To be precise, Bryan’s query will find things that were created this month, which are also of type /film/film. To find new assertions, you have to get a little more complicated.

[
  {
    "id" : null,
    "type" : {
      "id" : "/film/film",
      "link" : {
        "timestamp>" : "2008-08"
      }
    }
  }
]

will find things who have had their film type asserted this month.

[
  {
    "id" : null,
    "type" : [
      {
        "id" : null,
        "link" : {
          "timestamp>" : "2008-08"
        }
      }
    ]
  }
]

will find things that have had new types added this month. In general, for any property assertion, you can ask about the timestamp on the link.

That's a good point. Just because an event doesn't appear in Freebase doesn't mean you can assume that it didn't occur.

I would model this by co-typing the 1994 World Series topic with a Canceled Event type and then maybe add a property to say why it was canceled.

In some ideal data-world, all administrative divisions for all countries would be entered, with the proper contains/contained by nesting, so that you would only need to add a city's immediate administrative division to assert that it was also in the country that contains the division (or that contains the division that contains the division, etc.). But since we don't (yet) live in such a world, go ahead and use the "contains/contained by" properties.

There may be something I am missing: it looks like you’ve answered your own question! (“If you want to change that name, and you have the necessary permissions, you can change it on that other type.”) I’ll try to break it down, though.

When looking at the schema for a type, you can only edit the properties on that type. The “linked in as” is the name of the reciprocal property on some other type, so you can’t edit that directly; you must visit the other type to change it.

To create a “linked in as,” a reciprocal property, is very simple. Once you have a property from one type to another, go visit the schema for that other type. At the bottom of the schema editor, you will see “Suggested Properties”; these are un-reciprocated incoming properties from other types. If you edit the name of one of those, you have not only picked up a new property with its “linked in as” already set, you have now changed the “linked in as” on the other type.

Please note that the schema editor is being redesigned, so the details of this process (though not the fundamental concepts) may change.

Now, if you don’t have the rights to edit the other type, you’re out of luck. Let’s say you make a private type called Hater with a property called “People Hated” that expects Person. Unless you’re an administrator of the People domain, you can’t reciprocate that property as “Hated By.” And that’s just as well; we don’t want everyone on the system to be able to edit all the types, which is why we have the administrator system in place. If you think that known by whom a person is hated is critical information to the Freebase community, you can ask the People administrators to reciprocate the property, or even to promote your Hater type into their domain.

Does that help? 

That's actually a good way of explaining reciprocal properties.

Do you know how much lag time to expect from the time a property is put up, to when the suggested property appears on the other type?

Hi wellstone,

 FYI - most locations include the type statistical region which has a property for population (ECT of dated integer).  If you look at the earth, the value for 2007 has already been inputted.