Databases

Deciding between facets

Information architecture is how we structure data. It’s the data and metadata we use to describe the things that matter to our systems. We also need to keep in mind that it’s not reality, or even a picture of reality. It’s a set of related models that capture some facets of reality. Our job is to choose which facets to model, what to leave out, and how concrete to be.

Relational databases

When we’re embedded in a paradigm, it’s hard to see its limits. Many of us got started in the era of relational databases and object-oriented programming, so we tend to view the world in terms of related objects and their states. Relational databases are good at answering, “What is the value of attribute A on entity E right now?” But they’re somewhat worse at keeping track of the history of attribute A on entity E. They’re pretty awkward with graphs or hierarchies, and they’re downright terrible at images, sound, or video. Other database models are good at other questions.

Take the question, “Who wrote Hamlet?” In a relational model, that question has one answer: “Shakespeare, William.” Our schema might allow coauthors, but it surely wouldn’t allow for the theory that Kit Marlowe wrote Shakespeare’s plays. That’s because the tables in a relational database are meant to represent facts. On the other hand, statements in an RDF triple store are assertions rather than facts. Every statement there comes with an implicit, “Oh yeah, who says?” attached to it.

Changing the database

Another perspective: In most databases, the act of changing the database is a momentary operation that has no long-lived reality of its own. In a few, however, the event itself is primary.