by Margaret Hagan, orignally published on Legal Design & Innovation

At recent lawyer-focused hackathons and design sprints, there is a definite trend in the projects being proposed:

Make ‘it’ machine-readable!

Build a standardized markup or markdown language!

Convert natural language to computable language!

Whether it is for legislation, legal help information, or for contracts (and especially for contracts), the focus is on converting the work product of lawyers from text that only humans can understand. All these projects propose to transform legal information into standardized, machine-readable form that computers can parse, search, compare, carry out, and otherwise act upon.

I am not a technologist, and when I first encountered the term ‘informatics’ I was scared. But I spent this past few months reading up on ontologies, schema, and other informatics term for how to structure information into machine-readable ways. I’ve written up my notes for other lawyers entering this brave new computable-information world, and who want to get literate in its jargon — as well as to appreciate its potential for improving legal services.

Don’t Be Scared, It’s Just an Ontology

The word ontology scares and confuses people. It sounds more intimidating, or overly structured. People (like lawyers) often get freaked out that it’s too technical – and they aren’t tech-oriented enough to engage.

Or, even if they get what an ontology is, they doubt its utility for them. Often, they assume that their knowledge is too specialized and custom to be rendered into machine-readable structures.

So what is an ontology?

An ontology is how we represent knowledge into a machine-readable format.

It helps machines to understand what humans say and write, and deliver better information back to them. Or to do other smart, useful things.

It is an explicit, structured description of all the people, things, concepts, and relationships in a domain. It provides a common vocabulary to all the people working in a domain — like in medicine, in law, or otherwise. It gives them a shared understanding of how to represent their domain to machines.

What’s the good of an ontology?

The value of an ontology derives from two main factors.

• An ontology improves how people in a domain communicate. It defines explicitly what a term means, with an unambiguous interpretation. It provides some certainty of what information means.
• An ontology lets humans and machines work together better. It lets us give machines more ability to do search and reasoning in efficient ways. It enhances machine’s powers for reasoning and inference.

An ontology that is public and collaborative has further value.

• It promotes efficiency among professionals, so that they can borrow and build on each others’ standards.
• It gives better insight into the domain, and how it’s structured.
• It prevents the ‘hard-coded’ assumptions in different groups’ systems and applications from being opaque. It lets anyone understand how the group is working, evaluate it, and work with it
• It helps you solve common tasks across domains. With a shared vocabulary and info architecture, it becomes easier to work together — and potentially also build interoperable software.

Where are ontologies used?

Medical professionals use ontologies to define information about diseases, symptoms patients have, what treatments can be used — and to share all this information in standard ways among different doctors, pharmacists, researchers, nurses, technologists, and beyond.

Banks use ontologies to tag the products they offer, and to report into government agencies about what they are doing.

Search engines use ontologies to build knowledge graphs that give them insight into what people mean when they search for questions.

How do you actually use an ontology?

You can use them as a reference material, that gives a shared vocabulary — with codes, markup tags, and other ways to standardize what different people and groups are talking about.

You can use ontologies to integrate databases, bring them together and harmonize them.

You can use them to annotate data and natural language — converting into standardized terms, so that it’s not different people’s jargon but a standard term.

Ontologies are useful to build decision support tools, with modeled information and an engine that interprets it and applies it to specific use cases.

You can use them for better search and browsing, so that people can see clearly categorized options and content.

How do we craft an ontology?

If ontologies are so valuable, how do we actually craft them? This is where all the hackathon and project work mentioned above comes in. Many are proposing new legal ontologies.

Hopefully this work will be collaborative — so that we do not have an overload of disparate ontologies, but rather interoperable ones that share standards. Ideally, it will also be user-centered, so that what is being mapped corresponds to what people who use the legal system actually need and want.

In our project, a Better Internet for Legal Help at the Legal Design Lab, we are using design thinking to craft an ontology of legal help issues that people search for online.

In our process, we’re pulling apart the kinds of information that an individual needs when they’re searching Google, Bing, or Yandex for a legal problem. That means thinking more systematically about what the ‘ingredients’ of a good legal answer to a search query would be. Each of these ingredients will be a possible term or branch in our ontology.

We used the online tool Mural to start putting up post-its about the various people, things, fees, places, and abstract concepts involved in getting legal help information to someone.

From there, we start to lay out those terms into systematic patterns. First, it’s a map of how the different terms relate to each other. We see which is connected to which, and which has priority over another.

We took to the whiteboard to start making the connections, details, and filling in how all these different ingredients related to each other.

We also did it from the perspective of different types of users. We imagined what different kinds of people might be searching for, in terms of legal help online, and then made ingredients lists and maps specific for them.

The questions that we got from these specific users will then be the metric for our ontology’s success. If we can successfully answer these questions from the users, then our ontology has succeeded. If we haven’t captured the information necessary for these users’ problems to be resolved, we need to revise it.

After that, we started to see not just patterns, but also hierarchies. We could see what types of information made up broader categories (classes), and then which types were more specific ones (sub-classes).

We spotted that the following factors were particularly meaningful as higher-level classes of information in our Legal Help ontology: eligibility, procedural steps, services to assist, legal rules, a person’s issue, and official records. This is our first draft of an information architecture.

As we continue refining our sketched out ontology, we will begin to implement it online with various legal help providers and search engines. They will have standardized terms and tags for how they can find the right info for people searching online for help. We will be posting more here as our ontology is further built out — stay tuned!