Mapping law firm data

The future of legal knowledge management is structured, connected, and usable—ontologies are a big piece to unlocking this potential.
Written by:
Andrew Thrasher
Published:
October 10, 2024

Information overload

A common scenario for legal professionals: you're working on a complex case that mirrors something you worked on last year, which would be a helpful template to reference.

Depending on your firm, next steps might include:

  1. searching through a case management system using keywords, reporting filters, etc.
  2. messaging a coworker to ask if they have the relevant template
  3. sorting through an unstructured folder system in a document library
  4. digging through physical case files to find scanned copies of filed petitions

These scenarios play out in law firms every day. Legal teams spend a lot of valuable time making up for knowledge silos and gaps in data infrastructure.

The sheer volume of information collected, created, and managed by even the smallest firms and solo practices—case files, research notes, legal templates, client communications, financial data, etc.—can be jarring to imagine. Traditional methods of organizing this data often fall short, pushing employees to use costly workarounds and redundant processes to compensate.

So, how can ontologies help an organization manage information?

  • Sharing knowledge: provides a common vocabulary for people and computers to understand and communicate about a domain of knowledge.
  • Reusing knowledge: makes it easier to reuse and build off existing knowledge. That’s important for optimizing performance (and reducing costs) in the products that routinely reference this information.
  • Making assumptions explicit: helps clarify and document the (otherwise implicit) assumptions behind a particular area of knowledge.
  • Separating domain and operational knowledge: helps to delineate the operational knowledge of a system from the domain knowledge.

Ontology (noun):

What exactly is an ontology? According to Wikipedia, it’s “…a way of showing the properties of a subject area and how they are related, by defining a set of terms and relational expressions that represent the entities in that subject area.”

A more tangible analogy: imagine a disorganized library, where returned books are randomly placed onto empty shelves without an organizational structure like the Dewey Decimal System. Just as a skilled librarian, supported by standard cataloging systems, knows exactly how and where to find a book in their care, an ontology provides a structured framework for organizing and connecting information—with added focus on the relationships connecting this data.

A playful illustration of a large, chaotic and disorganized car factory
A chaotic factory

Or, think of a Chaotic Factory. As Cal Newport explains:

"Imagine that you walk into a car factory and encounter a chaotic scene. Half-built vehicles are scattered across the floor. Workers wander frenetically, grabbing each other as they pass, shouting out random requests. “Do you know where the wrenches are?" “When you get a chance, come show me how to install a steering wheel.” (...)
If you saw this, you’d be astounded. Surely this factory wouldn’t be in business for long. (...)
And yet, in knowledge work, a lot of organizations run more or less like the chaotic car factory. If you replace the half-built cars with shared Google Docs, and the shouted requests with emails and Zoom, it’s the same haphazard dynamics.”

In slightly more technical terms from information science: an ontology is a formal way to represent a domain of knowledge as a set of concepts, and the relationships between those concepts.

Importantly, an ontology gives structure to this knowledge in a machine-readable format, making it more effective in machine learning tasks and knowledge graphing. That’s why ontologies are effective mapping tools for the large language models behind ChatGPT, Claude, and Microsoft CoPilot.

An ontology anatomy:

The basic components of an ontology include:

Classes: represent the general concepts or categories in the domain.

Properties: describe the specific characteristics or attributes of a Class. Property types can include data (e.g. timestamp/date formats), objects (e.g. ’isAuthor’ to relate a book and its writer), and annotations (e.g. deprecated components or readme notes from the ontology developers)

Individuals/Instances: Individual instances are specific examples of a Class.

Relationships: Relationships connect classes and individuals, like "is a" (subclass relationship), "has" (property relationship), or "located in."

Axioms: The assertions or rules (using logic statements) that describe the ‘truths’ and theories within the ontology.

Other components, like events and restrictions, further define the assertions made by—and the changes made to—the system.

Let’s look at a visual of ‘Gaming Law’ as a concept organized within the Standard for Open Legal Information:

Visualizing ‘Gaming Law’ as a concept in the Standard for Open Legal Information (SOLI) using webProtege. SOLI: https://github.com/alea-institute/SOLIProtege: https://protege.stanford.edu/

‘Gaming Law’ is an example Instance of an ‘Area of Law’, one of the top-level Classes in SOLI. The ‘rdfs:seeAlso’ indicates an ‘additional information’ Relationship between ‘Gaming Law’ and the ‘Amusement, Gambling, and Recreation Industry’.

Building an ontology

The two primary types of ontologies differ in the depth and breadth of knowledge covered:

  • Domain ontologies: Focus on a specific area of knowledge, like an ontology of birds or fish.
  • Upper ontologies: Provides a more general, big-picture framework representing knowledge across broader concepts.

Key principles:

Here are a few things to consider as you build/adopt an ontology:

  1. There are multiple ways to model a domain, and the best approach depends on how you intend to use the knowledge you’re organizing.
  2. A sustainable ontology requires ongoing refinement as you gain a better understanding of and update the system.
  3. Grounded in the domain: Concepts should closely reflect the real-world objects, assumptions, and relationships in the domain—beyond the more basic, rigid hierarchy of a taxonomy.

First steps:

Without over-simplifying a complex area of information science and knowledge management, here are some basic steps to building an ontology:

  • Define the top domain and scope: What specific area of information will the ontology cover? What questions should it be able to answer?
  • Identify the key concepts (’Classes’): What are the primary topics that help organize and classify the concepts in this area of information?
  • Organize concepts into a hierarchy: Group similar classes together using "is a" (subclass) relationships.
  • Define properties: What are the important characteristics of each class?
  • Add individual instances: Create specific examples of each class to ‘test’ the ontology.

Ramentology 🍜

Let’s build a simple system to classify and organize the concepts relevant to ramen (a Ramentology, if you will).

To help visualize and apply this exercise, we’ll use the fantastic bowl of mayu tonkotsu I had yesterday (shout out to Akahoshi Ramen in Chicago!) as an example instance:

To start, we might define the classes of the domain, using ‘ramenType’ as our primary class to help classify each bowl of ramen. Broth and noodle types, the local origin of each dish, and the key toppings are all connected main classes as well.

Within those top-level classes, we might use subclasses like ‘vegetableToppings’ and ‘proteinToppings’ to give more context on the range of ingredients that might be included.

To help us understand these classes, we can also add relationships between concepts—like “is a“ for the broth subclasses or "has" to connect ‘ramenType’ with the ‘Noodles’, ‘Toppings’, and ‘Seasonings’ that go into each dish.

Then, we can add properties to help us further outline the intricacies of ramen, like the temperature of the broth (an integer value) or a boolean Yes/No for ‘glutenFree’ under 'noodleType'.

With those in place, let’s look at the mayu tonkotsu example using standard Web Ontology Language (OWL2) syntax:

ramen:MayuTonkotsu rdf:type owl:NamedIndividual ,
ramen:Ramen ;
ramen:hasType ramen:Tonkotsu ;
ramen:hasOrigin ramen:Fukuoka ;
ramen:hasBroth ramen:MayuTonkotsuBroth ;
ramen:hasNoodles ramen:MayuTonkotsuNoodles ;
ramen:hasToppings ramen:ChashuPork ,
ramen:GreenOnions ,
ramen:Kikurage ,
ramen:AjitsukeTamago ;
ramen:hasSeasonings ramen:Mayu .

ramen:MayuTonkotsuBroth rdf:type owl:NamedIndividual ,
**ramen:Broth ;**
ramen:hasBase ramen:PorkBone ;
ramen:hasFlavor "Rich, creamy, with roasted garlic notes"^^xsd:string ;
ramen:hasConsistency "Thick"^^xsd:string .

ramen:MayuTonkotsuNoodles rdf:type owl:NamedIndividual ,
ramen:Noodles ;
ramen:hasType ramen:SapporoNoodles ;
ramen:hasTexture "Firm"^^xsd:string ;
ramen:hasThickness "Thin"^^xsd:string .

ramen:Mayu rdf:type owl:NamedIndividual ,
ramen:Seasonings ;
rdfs:label "Black garlic oil"^^xsd:string .

ramen:Tonkotsu rdf:type owl:NamedIndividual ,
ramen:RamenType .

ramen:Fukuoka rdf:type owl:NamedIndividual ,
ramen:Origin ;
ramen:inCountry ramen:Japan .

ramen:PorkBone rdf:type owl:NamedIndividual ,
ramen:BrothBase .

ramen:SapporoNoodles rdf:type owl:NamedIndividual ,
ramen:NoodleType .

ramen:ChashuPork rdf:type owl:NamedIndividual ,
ramen:ProteinTopping .

ramen:GreenOnions rdf:type owl:NamedIndividual ,
ramen:VegetableTopping .

ramen:Kikurage rdf:type owl:NamedIndividual ,
ramen:VegetableTopping .

ramen:Kikurage rdf:type owl:NamedIndividual ,
ramen:VegetableTopping .

Why should we care?

This might sound too technical for a small or midsize law firm to consider.

If you work in an area of ‘PeopleLaw’, like immigration or personal injury, your clients aren’t necessarily demanding this type of practice innovation. And highlighting your firm’s more sustainable knowledge base isn’t exactly compelling marketing content.

Zooming out from the individual client, though, you can see how this behind-the-scenes work is smart business:

  1. Knowledge (mis)management: Using an ontological structure gives you a clear blueprint and common business language to organize your firm’s collective knowledge. Knowledge silos are often the product of unclear guidance on how to effectively share and manage this data across teams.
  2. A better search experience: I’ll avoid the tired cliches about searching for a specific file and finding dozens of long-winded file names like ‘H1BSupportLetterFINALTemplateV3’ (editor’s note: ok, I won’t avoid the cliche). With an ontology-driven knowledge base, your searches often return better results because of the additional context and relationship mapping available.
  3. AI-powered legal services: Ontologies will continue to grow in importance as a tool for AI advancement in law. When you consider the ongoing efforts to sort through endless unstructured and inaccessible data—representative of lots of legal work even today—we’ll see more demand (and value) for structured roadmaps to organize this ocean of knowledge.

Ontologies IRL

In legal:

Now, what does an ontology look like in real life? I recently mentioned the ALEA Institute’s Michael Bommarito, who is leading a new Standard for Open Legal Information (SOLI).

Tangentially, Damien Riehl is a well-known ambassador for the SALI Alliance™ (Standard Advancement for the Legal Industry) and its legal matter standard specification (LMSS) model. Damien also advises the ALEA Institute and advocates for its work on SOLI.

Earlier this year, I came across some great content from Graeme Johnston on LinkedIn, and have enjoyed following his updates on noslegal, a similar collaboration focused on UK law.

A hat tip to Graeme as well, for his indirect recommendation for The Book of Trees: Visualizing branches of knowledge by Manuel Lima—a great reminder of the social and historical context behind this work (which doubles as a great coffee table book).

Cover art for 'The Book of Trees: visualizing branches of knowledge' by Manuel Lima. Side-by-side half images showing two different knowledge trees from different time periods.https://papress.com/products/the-book-of-trees-visualizing-branches-of-knowledge

Elsewhere:

While the legal industry (as a whole) is in the relatively early stages of adopting information standards for digital work, let’s look at a few real-world examples to imagine future potential:

In healthcare, the SNOMED CT ontology is an internationally-recognized standard for medical terminology across different systems and countries—serving as the core interchange for transferable electronic health records in products like Epic Systems and allowing researchers to use clinical data more effectively.

A visual model of the SNOMED CT hierarchy of concepts representing procedures performed on a patient (Wikipedia). https://en.wikipedia.org/wiki/SNOMED_CT#
A visual model of the SNOMED CT hierarchy of concepts representing procedures performed on a patient (

Upper and domain ontologies are also used for organizing everything from the elements of gene sequencing to human anatomy.

Meanwhile, financial institutions use ontologies to model complex financial products and regulatory requirements to improve risk management and compliance efforts. The Financial Industry Business Ontology (FIBO), from the Enterprise Data Management Council (EDMC), is maintained in coordination with its member organizations and built on the standard Web Ontology Language (OWL).

EDMC membership includes an international laundry list of government agencies (US Citizenship and Immigration Services is a new member), large banks (e.g. Citibank, Wells Fargo, Credit Suisse), as well as tech and consulting partners.

Ontologies are also key to the discussion on colonialism and the cataloging of Indigenous and Native American culture and knowledge. Collaborations like the First Nations, Metis and Inuit – Indigenous Ontologies (FNMIIO) show the potential for ontologies in helping document and protect community knowledge and information structures.

Revisiting our ‘ramentology’ idea for a second—the ‘farm-to-fork’ FoodOn ontology covers everything from agricultural processes to the chemical ingredients of packaged meals. To do so, it reuses elements from other ontologies built on the OBO Foundry (Open Biological and Biomedical Ontologies) principles, like ENVO for environmental knowledge and CDNO for nutritional concepts.

Image from FoodOn visualizing the major components to the FoodOn ecosystem.https://foodon.org/

According to FoodOn : ”The ontology can be used like a grammar to construct statements about the world and food in particular, statements which can be entered in a database and queried or reasoned about.”

A structured future

As law firms respond to broader trends we see in knowledge work today—like indexing frequently referenced data for easier/cheaper access across an organization—ontologies should become more important.

And with easy-to-access tools that let us visualize, share, and use relational knowledge more effectively and at a larger scale, we can build more granular models of complex areas of knowledge. This, alone, should excite anyone who works with legal information regularly.

Well-informed legal professionals, equipped with structured domain knowledge and operational information, are able to better serve their clients.

The future of legal knowledge management is structured, connected, and usable. Ontologies are a big piece to unlocking that potential.

Further reading suggestions:

Get our newsletter
A monthly email on the latest in legal technology, process design, and the business of immigration law.
From quick tips to deep-dive content, we share the resources you need to deliver better legal services.