Philip’s email explains what you’re seeing:

* Nodes represent types, edges represent properties.
* Reverse properties are shown in parentheses after the master property name.
* Grey edges represent hidden properties
* Blue nodes are types outside the domain being viewed, but which are linked to from the domain (the edge will be dashed if the master property is from the type outside the domain to that inside the domain)
* Red nodes represent undocumented types
* Node shapes indicate the display style of the type (ellipse: standard, rectangle: CVT, triangle: enumeration)
* All nodes are clickable to view that type

The visualisations are now built into the schema explorer.

As with all other Acre apps, the source code is available and cloneable.

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!

The steps to do this are pretty straightforward.

1. Open a schema that you have permissions to edit
2. Click ‘add new property’



3. Give it a title and click ‘Or: use a property from another type” at the bottom of the edit window
4. Enter the name of the property you want to delegate and click ’select’



5. If you’re happy with your selection and you’re done editing the property, you can click ’save’

As a recap, delegated properties have the following characteristics.

• They share the data with the source property (edits to property values in either property always affects the other property)
• The expected type of the delegated property is the same as the source property and can’t be changed in schema editor
• Once data exists for a delegated property, you can’t change source property it points at. In this case you’ll need to delete or hide the property and create a new one.

Say for instance you’re creating a new type called ‘Irish actors’ and you want the properties ‘birthdate’ and ‘birthplace’ from the ‘person’ type and the ‘films’ property from ‘film actor.’ Instead of creating new properties that duplicate these existing ones, and having to repopulate their values, you can delegate these properties — which means you create a new type with new properties (that can have their own display names and display characteristics) that share the expected type and the data with the source properties.

This is a new feature and requires a little help to find your way through it, so let’s look at an example. You’d start by selecting a type, say ‘film actor,’ and adding columns for the properties you care about. You can then filter down by some criteria, such as ‘birthplace,’ and get a list of actors that might look like this.

The next step is to click the ‘use results’ button and select ‘add to another type.’ One option here is to quickly apply an existing type to these results, but we want to go one step further and create an entirely new type. By entering a type name and choosing ‘create new’ you now have the option to make a new type in any domain you administer.

This new type will come pre-populated with delegated properties for each of the columns appearing in your filtered set.

Voila, you’ve created a new type without ever setting foot in schema editor!

In the next release you’ll be able to create delegated properties directly in the schema editor as well, but hopefully this can get you started.

Some important changes

• Server-side rendering for fast page loads
• Properties grouped by the types they include
• Property keys and display hints are visible at a glance
• A redesigned property edit interface
• Data type picker for selecting an expected type
  • Note: you can still select any type in the system as an expected type by picking ‘link to topic’
• Quick access to related types (from within and outside of the current domain)
• Enumeration options (pick lists) are now edited within the settings for the type

Due in an upcoming release

• Ability to delegate properties from other types
• Ability to access the discussion for the domain to discuss schema changes
• Ability to create/modify compound value types within a parent schema