Freebase Commons admin guidelines

This is aimed at people who are, or would like to be, administrators of domains in the Freebase Commons.

Who can become an admin in the Commons?

Anyone who is a regular contributor to Freebase, has expert knowledge of the subject matter, and is experienced with schema modelling.

Your duties as a Commons admin

As an admin in the commons, here are the things you're responsible for:

  • Watching and responding to discussion posts in your Commons domain
  • Evolving schema according to community needs
  • Keeping the Freebase community informed of changes to your Commons domain

Tips for schema development in the Commons

Commons schema are intended to be as stable as possible.  The following tips all support that goal.

Commons types should not rely on non-Commons types.  No type in the commons should include a type from outside the commons, nor should the expected type of any property be a non-commons type.

Some schema changes will have effects on people using your Commons types.  Users may include API developers, people with saved views, and people whose bases rely on your Commons types.  The following list of changes will give you some idea of the amount of impact caused:
  • Adding a property: low impact
  • Deleting a property: high impact
  • Changing a property from a plain property to a CVT: high impact
  • Changing the expected type of a property: medium impact
  • Changing a property from unique to non-unique: low impact
  • Changing a property from non-unique to unique: high impact
  • Adding or removing an included type: low impact
High impact means that you will almost certainly break any apps relying on that type/property.  Medium impact means that you may or may not break apps.  Low impact means that you won't break any apps.

For high impact changes, you must attempt to notify as many users as possible.  At minimum, you should give notice on the data-modeling and developers' mailing lists and in the discussion on your base homepage, at least two weeks in advance.  You should repeat the warnings leading up to the change, then make the change on sandbox and leave it there for a week for people to test their code/schemas before making your changes on the live site.  This is especially important for core types like person, location, etc. 

For medium impact changes, you should perform the same notification but need not give as much warning.

For low impact changes, you can do them straight away without notice, but you should at least let people know you've done it by posting a discussion post on your base homepage.  Ideally you would already have discussed the idea of the change with the community before doing it.

Ways to mitigate the impact of changes:
  • Don't delete properties straight away.  Hide them first, document them as deprecated, and leave them that way for some time before removing them.  API users will find that their apps fall out of date, but don't break outright.

Search Help Center

Discussions

There are no conversations on this topic. Would you like to start one?

Start the Discussion »