If you’re like me, MQL often feels like a combination of power and dark magic: some people can whip up a MQL query in no time, like they knew all about every type, every property and how they link all the various pieces of the graph together.

Asking around how people did it, yielded several strategies… but many basically revolved around using the ‘explore pages’ (those magically revealed by hitting the F8 key on freebase.com).

Then David wrote the new query editor, with the amazing context completion and I thought I was set… but while my MQL mojo improved a lot with it, it always felt like something was missing: if I knew the type I wanted, I could get started… but what if I didn’t know where to start? what if I didn’t know how to construct the query and I needed some guidance in navigating how the types were all connected together? (especially with CVTs and whatnot)

I felt like I was in a fog and with no map: finding my way out felt tentative at best, frustrating at worst.

The Jason showed me an acre app he had written a long time ago and that he uses all the time that offered a browsable interface to all the freebase domains, types and properties, their IDs… and how they all connect together.

I had found my map.

Unfortunately, while extremely useful already, the schema explorer app needed some love… so I decided to give it some and the result has been so successful internally that I’m happy to announce it to the public so that everybody can benefit from it. Find it at: http://schemas.freebaseapps.com/

I hope you’ll find it as useful as I do.

NOTES:

1) suggestions/criticism/feature-requests appreciated and welcome

2) this is an acre app and if you’re curious (or interested in forking it) you can find it at: http://acre.freebase.com/#app=/user/jdouglas/schemas

3) this couldn’t have been possible without Jason’s work upon which I built this so kudos go to him while all the mistakes remain mine

4) I’ve been working on integrating the schema explorer with the upcoming freebase developer’s documentation hub, so that newcomers won’t have to hunt down this URL in the mail archives to find a little guidance in the type maze.

Enjoy!

We already had the ability to return a count of results:

[{
  "type" : "/astronomy/planet",
  "return" : "count"
}]

(The above will tell you how many planets we have in Freebase’s Astronomy Commons.)

And you can even find counts within a sub-part of the query, like, how many moons each planet has:

[{
  "type" : "/astronomy/planet",
  "/astronomy/orbital_relationship/orbited_by" : {
    "optional" : true,
    "return" : "count"
  }
}]

But what if you just wanted to know the planets with the most satellites? There’s no way to sort by that count that’s returned… until now!

[{
  "type" : "/astronomy/planet",
  "/astronomy/orbital_relationship/orbited_by" : {
    "return" : "count"
  },
  "sort" : "-/astronomy/orbital_relationship/orbited_by.count",
  "limit" : 3
}]

You can also use estimate-count for counts which are large and might otherwise time out.

Try it in the query editor!

While MQL doesn’t currently support transitive closure, the /location/ location/containedby property model was designed to make the type of query you are attempting to write possible. When creating /location/ location topics the idea is to provide (at least) two levels of hierarchical containment in the containedby property. For example, in the US, cities should specify what county they are in as well as what state they are contained in.

As your query indicates universities should be co-typed as locations and should specify the city they are contained in. Using the two- level of hierarchy containment model, cities should be contained in states, and similarly states should be contained in the US. Therefore, you should be able to get what you are looking for with the query:

Note: the ID for the US is /guid/9202a8c04000641f8000000000959f60

  {
     "query":[{
       "/location/location/containedby":[{
         "/location/location/containedby":[{
           "/location/location/containedby":[{
             "id":"/guid/9202a8c04000641f8000000000959f60"
           }],
           "name":null
         }],
         "name":null
       }],
       "name":null,
       "type":"/education/university"
     }]
  }

Someday, MQL will probably handle transitivity operations – but until then it is possible to construct queries which utilize the containment models based on some minimal assumptions about the data.

This tip came from the MQL Cookbook: Perform transitive queries

What makes it tricky to find included types is that there is no property within the type itself that contains the information you need. Instead, you have to take advantage of a a property that is used by the Freebase client to display type information. These client properties are all properties of /type/property and can be queried in the same way as other properties of a property. These are bare properties; the type is not asserted on the property. Client properties include:

• /freebase/documented_object/tip: Adding documentation to a property (ect: /type/text)
• /freebase/property_hints/display_none: True if the property is hidden
• /freebase/property_hints/disambiguator: True if the property will operate as a disambiguator
• /freebase/property_hints/display_orientation: vertical if the property should be displayed as such, horizontal otherwise
• /freebase/type_hints/included_types: lists types included with another type

For this particular query, use the /freebase/type_hints/included_types property, as shown in the following query:

{
  "/freebase/type_hints/included_types" : [
   {}
  ],
  "id" : "/music/artist"
}

This example is from the Schema Introspection Cookbook, where you can find more MQL recipes for finding out information about types, properties, and schema.More information about /type/property and its properties can be found in Chapter 2 of the Complete MQL Reference Guide, “Metaweb Architecture.”

This week the query focuses on getting the Wikipedia article ID for a given topic, and is drawn from the help topic Attributing Topic Descriptions to Wikipedia. According to the Freebase terms of service, if you reproduce a Freebase topic description that originally came from Wikipedia in your own application, you are obligated to provide a link back to the original Wikipedia article. Fortunately, there’s an easy way to identify the source of a Freebase topic description by examining its /common/document/source_uri property for the topic description. If this property contains a wp, as in http://wp/en/1194195, then that description originated from Wikipedia. However, you should note that this value is a “pseudo-URI;” it won’t link you back to the original Wikipedia article, it’s simply a way of assigning a resource indicator to the article description.

With this in mind, the trick is to create a basic MQL query that will return the value for this property. Here’s a query that can be used to examine this property for a single topic:

  {
     "id" : "/en/hortense_ellis",
     "/common/topic/article" : [{
     "id":null,
     "/common/document/source_uri" : []
     }]
   }

Note that this query is configured to return multiple results in case there’s both a Wikipedia and user-contributed topic description.

In most cases, however, you’ll want to run this query against a batch of results, and then, programmatically create links back to the Wikipedia articles where appropriate. Here’s how you could incorporate the same query into a larger one that looks for 25 albums with tracks containing the word “love,” and returns the artist name, track name, album name, and the GUID of the topic description, along with the /common/document/source_uri property value:

   [
     {
       "album" : [{
         "artist" : [ ],
         "name" : null,
         "/common/topic/article" : [{
     "id":null,
     "/common/document/source_uri" : [ ]
     }]

       }],
       "limit" : 25,
       "name" : null,
       "name~=" : "Love*",
       "type" : "/music/track"
     }
   ]

Having retrieved the information you need, all you need to do is re-insert the number at the end of the /common/document/source_uri property, which identifies the article in Wikipedia, into a working Wikipedia URL, like this: http://en.wikipedia.org/w/index.php?curid=1194195. Again, this is something you can do programmically once you’ve gotten the information you need.

One of the interesting features of the graph database structure underlying Freebase is that, because nothing is ever completely removed from the graph, you can create queries that let you examine the state of domains, types, and other objects at some point in the past. This can be useful, for example, for charting the growth of a domain, or establishing a trusted view of a topics by establishing a view based on a timestamp. This is accomplished by using the “as_of_time” envelope parameter. This is covered in detail in section 4.2.4 of the MQL Reference Guide, but below is an example of how you would use this parameter to answer the question “how many types existed in the Architecture domain on January 9, 2007, at a little after 10 PM?”

{
  "q1" : {
    "as_of_time" : "2007-01-09T22:00:56.0000Z",
    "query" : [
      {
        "domain" : "/architecture",
        "id" : null,
        "return" : "count",
        "timestamp" : null,
        "type" : "/type/type"
      }
    ]
  }
}

The answer is “12.” This example was drawn from a user-contributed query in the MQL Cookbook. Please feel free to contribute your own queries as well.

Some cool features of the new editor

• permalinks allow you to forward a URL with an embedded query (note: the links created in this version aren’t going to be supported going forward, we have a planned enhancement to ‘beautify’ them when we move out of experimental mode)
• more reliable UI (less buggy in various browsers)
• full screen editing
• toggle syntax highlighting on/off
• undo/redo

Missing features from the old editor:

• no tree view
• no full json results
• no filter option on sample queries

Let us know what you think. There are a bunch of other enhancements in the queue, including the ability to save queries. We’re particularly interested in feedback on which (if any) of the unimplemented old features above you feel are important to resurrect in the new one. We hope to replace the old editor with the new one formally within the next release or two.