Freebase (2007) › The Solution: A Collaborative Knowledge Graph

Freebase addressed these challenges through a fundamentally different architecture: a large-scale, collaboratively edited knowledge graph where information was represented as entities connected by typed relationships. Rather than storing information as text documents or rigid database records, Freebase modeled knowledge as a graph structure where nodes represented entities (people, places, concepts, events) and edges represented relationships (directed, acted in, located in, authored).

Freebase's design centered on a schema-free data model. Unlike traditional databases that required defining tables and columns before data could be entered, Freebase used a flexible type system where new types of entities and properties could be added dynamically as needed. The system organized knowledge into domains.broad categories like people, locations, organizations, works of art, and thousands of others. Within each domain, entities had properties that could be assigned values, and these properties could themselves reference other entities, creating the interconnected graph structure.

The technical architecture that enabled this flexibility was built around several main innovations. The system used a graph database to efficiently store and query the massive network of entities and relationships. Each entity received a unique identifier. This ensured that "Meryl Streep" as a person entity could be distinguished from "Meryl Streep" as a character name, even when the text strings were identical. Properties could have multiple values when appropriate.a person could have multiple professions, awards, or educational institutions.reflecting the complex reality of how entities relate to the world.

One of Freebase's most important features was its collaborative editing model, inspired by Wikipedia but structured for computational access. Users could add new entities, create relationships between existing entities, and edit property values. The system tracked changes and maintained version history, allowing for community moderation and quality control. This collaborative approach meant that knowledge could grow organically as users discovered gaps and added missing information, without requiring a centralized editorial team to anticipate every possible type of entity or relationship.

The query interface exposed this structured knowledge through MQL (Metaweb Query Language), a graph-based query language designed to express entity relationships more directly than SQL. Instead of joining tables, users could traverse the graph by following relationships. A query asking for "all movies directed by Steven Spielberg" would start at the Steven Spielberg entity and follow the "directed" relationship to connected movie entities. This graph traversal model matched how humans naturally think about relationships between entities.

Freebase organized its knowledge using a hierarchical type system. At the top level were domains representing major categories of knowledge. Within each domain, there were types.more specific categories like "Film Director" within the domain of people, or "Feature Film" within the domain of creative works. Types could inherit properties from parent types, allowing for shared characteristics while maintaining specificity. A film director would inherit basic person properties (name, date of birth, nationality) while adding director-specific properties (films directed, directing awards).

Properties in Freebase could have various value types. Some properties contained simple data types like strings (for names), dates (for birth dates), or numbers (for population counts). Other properties contained references to other entities, creating the graph connections. The property "directed" on a film director entity would contain references to film entities, while the property "director" on a film entity would reference back to the director. This bidirectional linking enabled efficient graph traversal in both directions.

The flexibility of the system meant that new types and properties could be added as knowledge domains expanded. When users discovered they needed to represent information about video games, they could create a new type within the appropriate domain without modifying existing schema. Properties could be added to types incrementally as users identified new relationships that needed to be captured. This organic growth model allowed Freebase to scale beyond what any predefined schema could anticipate.

The graph structure enabled types of reasoning that were difficult with other knowledge representations. Because entities were directly connected by relationships, the system could follow chains of relationships to answer questions that required multiple inference steps. To answer "which actors have worked with both Steven Spielberg and Martin Scorsese," the system could find all actors connected to Spielberg through "acted in" relationships, find all actors connected to Scorsese similarly, and compute the intersection.

The graph structure also supported more sophisticated queries about entity relationships. Users could ask about degrees of separation, finding entities connected through multiple relationship hops. They could query for patterns in the graph, finding all entities matching a particular structural description. The system could aggregate information across entities, computing statistics like "average box office revenue for films directed by directors who won Academy Awards."

This graph-based approach contrasted sharply with traditional text-based systems. While a text search might find documents mentioning relevant keywords, the graph structure ensured that relationships were explicit and queryable. When a film entity connected to a director entity through a "directed by" relationship, this connection was directly accessible, not buried in descriptive text that required natural language parsing to extract.

Freebase's success depended critically on its collaborative editing model. The system needed massive amounts of structured data to be useful, far more than any single organization could curate manually. By allowing community editing similar to Wikipedia, Freebase could draw on the collective knowledge and effort of many contributors. Users could add entities they knew about, create relationships between entities, and fill in property values from their domain expertise.

The system implemented various mechanisms to support quality and consistency. Users could flag problematic or incorrect information for review. The version history tracked all changes, allowing problematic edits to be reverted. The structured nature of the data made some inconsistencies easier to detect.if multiple users entered conflicting values for a fact like a birth date, these could be identified and resolved.

This collaborative approach had both strengths and challenges. The distributed effort meant that Freebase could grow rapidly and cover domains that would have been difficult for centralized teams to maintain. However, it also meant that data quality varied across different domains, with some areas receiving more attention and curation than others. The system needed to balance openness with mechanisms to maintain accuracy and consistency.