1. Data Models
Different data models are different conceptual ways for describing and dealing with data. For example, let's say I want to write George Washington's biography. Here are three different data models:
- I can write his biography as proses in a book, broken down into chapters but essentially organized in a sequential manner, intended to be read from start to end.
- I can write his biography in several web pages, with links between them, so that, say, I can take the reader instantly from one event in his life to another related event no matter how far apart in time those events were.
- I can write his biography in a table with several columns, including the names of events, the times when they happened, locations where they happened, the people involved or affected, etc., so that the reader can sort, group, and filter the events, or re-visualize them on time lines and maps.
Different data models are suited for different purposes. Proses might be nice to read a child to sleep, while tables are great for manipulation of the data and re-visualization in different ways.
You don't need to understand data models too deeply. Just know that different data models exist and are designed for different purposes.
Exhibit has its own data model, which consists of items, types, properties, and property values.
Each Exhibit database contains zero or more items. If it helps, you can think of items as records in traditional (relational) databases. An item represents something, anything—a person (Peter Pan), an object (the book called "The DaVinci Code"), a concept (beauty), etc. It's up to you to decide what constitutes items in your own exhibit.
Each item has a unique identifier (or ID for short) that, duh!, uniquely identifies the item within the exhibit. That is to say, two different items in an exhibit should have two different IDs, just like any two different persons in the U.S. should have different social security numbers (except when the U.S. government messes up and assigns the same number to both persons). If you accidentally assign the same identifier to two items, they will be considered the same by Exhibit.
An identifier is just a string—a short piece of text. There is really no restriction on what text can make up an identifier, but we would recommend something meaningful to you: "DaVinci Code", "Peter Pan", and "Beauty" would make good identifiers.
Although items have identifiers, you don't usually deal with identifiers directly. But we want to mention identifiers first just because we need to talk about them in various places later on.
In addition to an identifier, each item also has a label that is used to textually label the item in many cases when Exhibit needs to show the item in the web page.
Labels don't have to be unique. For example, two items (people) with IDs "John Doe #1" and "John Doe #2" can both have the label "John Doe". In most cases, you can use the same text for both the label and the ID of an item. In fact, Exhibit automatically assigns an item's label as its ID if you don't explicitly provide its ID. We will return to this issue later.
Each item also has a type. For example, the type of the item identified as "Peter Pan" would be "Person", the type of "The DaVinci Code" would be "Book", the type of "Beauty" would be "Concept".
Once again, we don't place any restriction on what constitutes types in your exhibit. You make that decision for your own data. Remember our motto for Exhibit:
If you don't explicitly assign the type to an item, Exhibit sets the item's type to "Item".
Just like items, types also have IDs which are just strings, e.g. "Book", "Beauty", and "Concept". Types also have labels, but we'll come back to that later on.
4. Properties and Property Values
Now the fun part begins. Each item can have zero or more properties (otherwise known as attributes, fields). For example, the item "Peter Pan" would have
- a "gender" property and
- a "member-of-gang" property,
and the item "The DaVinci Code" would have
- an "author" property and
- a "number-of-copies-sold" property.
The property value, or just value for short, of the "gender" property of "Peter Pan" is "male", and the value of the "member-of-gang" property of "Peter Pan" is "The Lost Boys". Similarly, the "author" property value of "The DaVinci Code" is "Dan Brown", and the "number-of-copies-sold" value is 6,347,343 or however many copies it was sold.
Note that while the "gender" property value mentioned, "male", is text, the "number-of-copies-sold" property value is a number. So, property values can be of different value types:
|text|| e.g., |
|number|| e.g., |
|date|| e.g., |
|url|| e.g., |
|item||we'll talk about this soon|
All property values of a property (e.g., "number-of-copies-sold") have the same value type ("number"). It is not possible to say that the "number-of-copies-sold" property value of "The DaVinci Code" is
6347343 while the "number-of-copies-sold" property value of "Lord of The Rings" is
"so many I can't count" because the first value is a number and the second is text.
Item Value Type
Now we said above that the "author" property value of "The DaVinci Code" is "Dan Brown". It's OK to consider that property value to be of value type "text", but since Dan Brown is actually a person, there's more we can do.
We can create another item of type "Person", with ID "Dan Brown", and with label "Dan Brown (writer)". And then, we can declare that "author" property values are of value type "item". When we say the "author" property value of "The DaVinci Code" is "Dan Brown", we actually make a relationship between the item "The DaVinci Code" and the item "Dan Brown". The property value "Dan Brown" is no longer just text, but it identifies another item.
5. Graph-Based Data Model
The relationship between "The DaVinci Code" and "Dan Brown" mentioned previously is shown as a red arrow in this graph representation of the data:
Relationships are properties that link items to items. Other properties link from items to text, numbers, dates, booleans, and URLs. So, the value type of a relationship property is "item".
Note that there are two different concepts of types here: types of items (e.g., "Book", "Person") and value types of properties (e.g., "number", "date", "item"). When we say that the value type of the "author" property is "item", we don't say anything about the types of the authors themselves. Books can be written by individual people, small groups, large organizations, or even a faceless, nameless mob.
Although we say that "Dan Brown" is an "author" property value of "The DaVinci Code", there should be no implication that somehow "Dan Brown" is smaller or less important a thing than "The DaVinci Code". We could have also said that "The DaVinci Code" is a "has-written" property value of "Dan Brown" and reversed the red arrow. It doesn't matter to Exhibit which direction you pick for a relationship, so just pick the direction most natural to you yourself.
See Next: Understanding Exhibit JSON Format