Make your firm's meaning machine-readable — by building a coherent entity graph that AI engines can understand, trust and cite.
Ontology for a law firm is the system of entity types and relationships that tells AI what your firm is, who works there, what it does, where, and how it all connects. Instead of a database of disconnected pages, an ontology describes your firm as one coherent entity — Attorney, LegalService, LocalBusiness, Place, Practice Area — with typed relationships binding them together (worksFor, serves, locatedIn, practices) so an AI engine can read, reason over, and cite you.
Use the interactive map below to explore each one — click any node to read what it covers and jump to its page.
The guides to designing and implementing a coherent entity graph for your firm.
The entity model that makes you readable, trustworthy, and citable.
Ontology = the formal structure of meaning: entities (people, places, organizations, concepts) plus the relationships between them. It is how machines understand what things are and how they relate.
Taxonomy is hierarchical grouping (folders, tree structure); ontology is semantic meaning and relationships (graph structure). Both are necessary, but ontology is what AI search engines actually understand.
A law firm is a semantic entity made up of related sub-entities (attorneys, offices, practice areas, courts). AI search engines map relationships between these entities to understand authority and expertise.
A knowledge graph is a structured map of entities (people, places, concepts), their attributes (properties), and relationships (how they connect). It is the foundation of how AI search engines understand and cite your firm.
A semantic triple is a statement in the form Subject-Predicate-Object (e.g., 'Scott Wiseman worksFor InterCore'). It represents a single fact about the relationship between two entities. Triples are the atomic unit of structured knowledge; linked together, they form a knowledge graph.
An ontology defines entities (things: your firm, attorneys, courts, services) and relationships between them (an attorney works for the firm, a service is offered in a city). Schema.org is the standardized vocabulary for expressing these entities and relationships.
Ontology is the meaning layer of your site — the entities (people, practices, locations, courts) and how they relate (spokeOf, partOf, relatedTo). It is separate from URL structure and traditional SEO.
Ontology is the formal description of what your firm *is* — the entity types (Organization, Person, LegalService, Place) and the relationships connecting them (worksFor, provider, areaServed, locatedIn). It answers: 'What entities exist in my legal domain, and how do they relate to each other?' It lives in the meaning layer, distinct from both taxonomy (the grouping structure) and schema (the technical markup).
Think of it this way: taxonomy organizes pages into groups (a hub for 'premises liability'). Ontology describes what premises liability *is* and how it connects to your firm, your attorneys, and the cities you serve. Schema is the technical vehicle for expressing that meaning to machines — schema.org JSON-LD is one choice, but you could express the same ontology in other markup languages. The ontology exists independently of the vehicle.
For a law firm, an explicit ontology prevents fragmentation. If every page describes 'the firm' differently, uses multiple names or addresses, or leaves relationships implicit, AI models can't confidently reason about you. A coherent ontology — one firm identity, one attorney identity, clear services and places — lets models trust, corroborate across directories, and cite you consistently.
The five core entity types: Organization (your firm), Person (each attorney), LegalService (what you offer — 'premises liability representation' or 'estate planning'), Place (city, county, state where you serve), and Practice Area (a topic like 'premises liability' that can span services). Every page and profile should declare at least one of these types with clear relationships to the others.
A typical local service page expresses four of them at once: the Organization (your firm), the LegalService (premises liability representation), the Place (Austin, Texas), and the Person (the lead attorney). A hub page about premises liability itself might declare the Practice Area and relate it to all the services and people who practice it. The more explicit these entities and relationships are, the more models can reason about your firm.
One firm identity with a single @id (unique identifier) across your whole site tells AI engines: this is the same entity, trust it. If your pages describe 'the firm,' 'our firm,' 'Firm, PC,' and 'Firm P.C.' with different addresses or phone numbers, models can't deduplicate. They see fragments and lose confidence.
In schema.org markup, the @id is typically something like #organization for your firm, and it's declared once (usually in the footer or site-wide layout) and referenced, not re-declared, on every page that belongs to it. The difference is critical: declaring the firm three times with different details looks like three different firms; referencing one @id everywhere is coherent and trustworthy.
This single-identity rule extends beyond your site. When your Google Business Profile, Avvo profile, LinkedIn page, and law directories all use byte-identical NAP (name, address, phone), and your site's @id is linked to them via schema sameAs, models can corroborate that it's the same entity across the web — which is the highest trust signal for citation.
| Approach | What models see | Citation risk |
|---|---|---|
| One @id, referenced everywhere | One coherent firm entity with consistent details across pages | High trust; models cite you consistently |
| Multiple @ids or no @ids | Fragmented; 'Firm PC' and 'Firm, PC' look different or are generic | Low trust; models can't deduplicate; no cite |
| One @id on-site, inconsistent directories | Site looks unified, directories contradict it | Medium trust; corroboration fails; models hesitate to cite |
One firm identity vs. fragmented — impact on how models read you.
An ontology is more than a list of entities; it's the typed relationships between them. A page about 'premises liability in Austin' shouldn't just list those concepts; it should connect them explicitly: the LegalService (premises liability) is provided by the Organization (your firm), the service is available in the Place (Austin, Texas), and it's handled by the Person (lead attorney) who worksFor the Organization.
Relationships answer implicit questions: 'Which attorneys at this firm practice premises liability?' (Attorney → practices → LegalService). 'Where does the firm serve?' (Organization → areaServed → Place). 'Who runs the Austin office?' (Person → worksFor → Organization; Person → locatedIn → Place). When models can reason through these relationships, they can construct more nuanced, accurate answers and cite you for the right practice area in the right place.
The key relationships for a law firm are: worksFor (attorney to firm), provider (service to firm), areaServed (service or firm to place), locatedIn (office or attorney to place), practices (attorney to service or practice area), and knows (firm or attorney to practice area or concept). Express these explicitly, and models can build a rich, trustworthy picture of your firm.
When your ontology is consistent — same firm name, address, and phone across your site, Google Business Profile, Avvo, Justia, and your LinkedIn page — models can corroborate that they're reading about the same entity. Corroboration is trust. A firm that describes itself the same way everywhere is more credible than one with conflicting details.
The technical glue is schema sameAs: your site's firm @id links to your Google Business Profile URL, your Avvo profile, your Justia listing, your LinkedIn company page. When a model sees your site, then encounters your Avvo profile and recognizes sameAs linkage, it confirms: 'This is the same firm.' Multiply that across five directories, and your identity becomes unambiguous and highly citable.
This is why we emphasize byte-identical NAP — the atomic facts (name, address, phone) must match exactly. A one-character typo, a missing suite number, or a different phone number fragments the entity. Every profile, every page, every directory must reflect one source of truth. For law firms that are already listed in dozens of directories, an audit and reconciliation project is often the highest-return investment — not flashy, but trusted by AI engines and every professional directory at once.
Start with one canonical source of truth — typically your website's master data (a spreadsheet, a database, or a CMS that drives everything). Every page and profile should be derived from this source, not maintained separately. If your firm's name, address, or phone is stored in five places, one of them will drift.
Design the entity model first, before you build pages or schema. Decide: What is a LegalService in your taxonomy? Is 'premises liability' a service, or is 'premises liability representation in Austin' the service? Is Austin a Place, or is an office location a Place with its own address? Be consistent in that choice. Then ensure every page and profile expresses entities consistently with that model.
Link everything via schema sameAs and @id. Your site's firm @id should link to your Google Business Profile, Avvo, Justia, LinkedIn. Every attorney Person @id should link to their LinkedIn and bar-association profiles. Every local office Place node should link to its Google Business Profile location. This creates the connective tissue models use to corroborate.
Audit regularly. Check your top directories quarterly for NAP drift, duplicate listings, or inconsistent practice areas. Use the ontology audit checklist (or run a free AI visibility audit to see where your entity is fragmented) to catch gaps before they cost you citations. It's easier to maintain consistency than to rebuild a fractured entity later.
The intents AI engines fan a search into — and where we make your firm the answer.
It's the formal description of what your firm *is* — the entity types (Organization, Person, LegalService, Place, Practice Area) and relationships between them (worksFor, provider, areaServed, practices, located). Ontology sits between taxonomy (how you organize pages) and schema (how you mark them up). It's the meaning layer.
Taxonomy organizes pages into groups — a hub for 'premises liability' contains all pages about slip-and-fall claims. Ontology describes what premises liability *is* as a concept and how it relates to your firm, your attorneys, and the places you serve. Taxonomy is the filing system; ontology is the meaning.
Ontology is the design — the entity types and relationships you decide matter (Firm, Attorney, Service, Place, Court, Statute, Practice Area). Schema is the markup — the technical standard (schema.org, RDF, JSON-LD) you use to *express* that ontology to machines. You could describe the same ontology in different schema languages.
Because AI engines reason about entities, not pages. If your site describes 'the firm' three different ways, uses multiple names/addresses, and doesn't connect services to the places you serve, models see fragmented information and can't confidently cite you. A coherent ontology lets them trust and recommend you.
Organization (the firm itself), Person (each attorney), LegalService (what you offer — 'premises liability representation'), Place (where you operate), and optionally Practice Area (a topic that spans services). Every page and profile should clearly express at least one of these with typed relationships to the others.
NAP — name, address, phone — is the atomic fact about your firm entity. When it's identical everywhere (your site, Google Business Profile, Avvo, Justia), models can confidently deduplicate and know they're reading about the *same* firm. It's the foundation of entity corroboration.
An @id is a unique, stable identifier for an entity in schema.org markup — like #organization for your firm or scott-wiseman#person for an attorney. When you use the same @id everywhere on your site, you declare 'this is the same entity.' Without it, markup fragments look like different firms.
Typed connections between entities — 'Attorney worksFor Organization,' 'LegalService provider Organization,' 'Organization locatedIn Place,' 'LegalService areaServed Place.' These relationships tell models how your firm's parts fit together and answer implicit questions ('which attorneys practice premises liability in Austin?').
Use one canonical source of truth (your site's master data), derive every page and profile from it, and use schema sameAs to link profiles (Google Business Profile URL, Avvo URL, LinkedIn page) to your firm's @id so models know they're describing the same entity.
No — not if you want models to recognize and cite you consistently. One firm should have one @id on your site, referenced (not re-declared) on every page. Use sameAs to link directory profiles, but keep the primary identity unified.
Every page should have a primary entity type (Article, WebPage, LegalService, FAQPage) and connect to the firm's @id so models know the page belongs to you. A local practice-area page also declares the Place (city/county), and optionally the attorneys (Person nodes) who handle it.
Run a fixed panel of real client questions through AI engines and track whether models cite you consistently, name your firm the same way, and reference the right practice areas and locations. If models sometimes call you 'The Firm' and sometimes 'Firm, PC' with different addresses, your entity is fragmented.
Start with a free 23-point AI visibility report — see exactly where ChatGPT, Gemini, Claude and Perplexity cite your firm today, and what closes the gap. Delivered in 24 hours. No credit card.
