We’ve been really impressed with all the great feedback we’ve received since Factual launched two weeks ago. Of course, this is just the beginning, and we still have a lot of work ahead of us. And although we have a talented (and sleep-deprived) team in our office dedicated to making Factual the best it can be, the real success of our product lies in the hands of people enthusiastic about the possibilities of open data.

People like Len Charnoff (aka @parrotguy), who independently of us made a series of instructional videos about how to use Factual. If you haven’t seen them, definitely check them out. In fact, Len might win the prize for the best quote about Factual we’ve heard so far: “If you’re a data junkie, then Factual.com is Nirvana.” Thanks Len!

In one of his videos, Len demonstrates how to build a Factual table. So we thought we’d post a brief addendum to that video and offer up some best practices tips when it comes to building a Factual table.

Tip #1 – Choose your primary key wisely.

Have you ever noticed how the left-most column(s) of Factual tables are darker than the others? The dark gray column is the primary key — the unique category field that will be the main pillar on which the rest of your data rests. (Think of it as the “primary subject” of your table, which sounds more intuitive, even though in database terminology “primary key” is an accurate way to refer to it.)


So if you’re building a table about cockatoos, to use Len’s example, we’d suggest that your primary key be “Name of Bird” (since each bird has a unique name) while the other fields to the right of it would be attributes of the subject. See the example below:

Tip #2 – Fields/columns should specify a data category, not an individual data entry.

In Len’s cockatoo table, he created a separate field for each new bird. The table currently has a only few fields, but if he decided to enter another hundred birds, that means the table would be over a hundred columns wide. It’s preferable to use fields as the names of categories (weight, height, country of origin, etc), and then create a new row for each new entry (in this case, for each new bird). In addition to giving the table a cleaner look, this also makes it easier to filter and search for information within the table.

Tip #3 – Create fields/columns that are data- and opinion-based.

In general, we recommend that you create field categories where the data can be verified (or disputed) objectively. But sometimes, creating fields where the answer is somewhat debatable is OK too. So for example, in Len’s table, the Mollucan’s “country of origin” is a verifiable fact; whether or not it’s “good with children” is probably more a matter of opinion. However, sometimes those are the categories that might spur the most interesting discussions…and turn up the most surprising facts. We may be a data-driven site, but we encourage you to create tables about all types of subjects — even disputed ones. Especially disputed ones.

We hope you find these tips useful as you embark upon creating your own tables. And we intend to offer up more Factual best practices tips in the future. So stay tuned.

As always, your feedback is most welcome.

And Len: keep those videos coming!

– The Factual Team