Semantic Triples (Subject-Predicate-Object) for Legal Content: Building a Machine-Readable Law Firm

A semantic triple is a simple statement of fact in the form Subject-Predicate-Object (S-P-O). The subject is a thing (an entity), the predicate describes a relationship, and the object is another thing (or a value). Examples: Scott Wiseman (subject) worksFor (predicate) InterCore (object). Or: InterCore (subject) hasOfficeLocation (predicate) San Francisco (object). Each triple expresses one fact.

Triples are the building blocks of the semantic web and knowledge graphs. Linked together, they form a network of entities and relationships that machines can understand and traverse. When you link the triple "Scott worksFor InterCore" with "InterCore hasOfficeLocation San Francisco," you have implicitly stated "Scott works in San Francisco" — the machine can infer this without you saying it explicitly.

For law firms, triples are essential because they transform your website from a collection of pages (which humans read) into a machine-readable knowledge base (which LLMs and search engines parse). An AI search engine like ChatGPT reading your site in plain text might infer that "John Smith is a partner at your firm" from prose, but it might miss nuance or misattribute the relationship if the text is ambiguous. With explicit triples, there is no ambiguity: John Smith's Person node carries a triple worksFor: {"@id": ".../#firm"}, pinned to your firm's unique identifier, and the relationship is machine-verifiable.

The advantage is clear: machines process triples at scale and with precision. Google, ChatGPT, Claude, and Gemini all index structured triples from JSON-LD to build entity graphs. An LLM answering "Who are the personal injury attorneys in Los Angeles?" searches a knowledge graph built from triples: it finds all Person nodes where hasOccupation=Attorney, knowsAbout=PersonalInjury, and worksFor.hasOfficeLocation=LA. Prose would require the LLM to parse and infer the same information from every page, introducing errors and missing results.

A semantic triple has three parts: (1) Subject — the entity being described. (2) Predicate — the relationship or property. (3) Object — the value or target entity. In RDF (Resource Description Framework), the formal language of the semantic web, subjects and objects are URIs (unique identifiers), and predicates are also URIs. For law firms using JSON-LD, URIs become @id values.

Example: Subject: https://intercore.net/#scott | Predicate: foaf:workplaceHomepage | Object: https://intercore.net/ (in RDF/Turtle syntax). In JSON-LD, this becomes {"@id": "https://intercore.net/#scott", "workplaceHomepage": "https://intercore.net/"}.

Subjects can be concrete entities: a Person (an attorney), an Organization (a law firm), a Place (a city), a LegalService (a practice area), a CourtHouse (a physical court). Predicates are standardized relationships. In schema.org, the most common predicates for law firms are: worksFor, hasCredential, hasOccupation, knowsAbout, image, url, sameAs, hasOfficeLocation, areaServed, and serviceArea. Objects can be other entities (another @id) or literal values (text, numbers, dates).

The key constraint: subjects and objects that refer to the same thing must use the same @id. If you declare Scott Wiseman as @id: https://intercore.net/#scott on his bio page and as @id: https://intercore.net/scott-wiseman on a team listing, you have split him into two entities in the knowledge graph. Search engines and LLMs will not recognize that both are the same person. This is why a shared, stable @id scheme is critical.

Predicates (relationships) must be chosen from a standard vocabulary. Schema.org provides ~700 predicates across types. RDF vocabularies (FOAF, Dublin Core, etc.) provide more. Using non-standard predicates breaks the graph — machines do not know how to interpret them. Stick to schema.org predicates when possible.

Schema.org is a collaborative vocabulary of types and properties (predicates) maintained by Google, Microsoft, Yahoo, and Yandex. It is the de facto standard for web structured data. JSON-LD is a JSON format for embedding schema.org triples into HTML. Every law-firm website using JSON-LD is, effectively, encoding semantic triples that AI search engines parse.

Here is a concrete example. You want to state three triples:

1. Scott Wiseman (@id: intercore.net/#scott) worksFor InterCore (@id: intercore.net/#org)
2. InterCore hasOfficeLocation San Francisco (@id: intercore.net/#sf-office)
3. San Francisco is in California

In JSON-LD, this becomes:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@id": "https://intercore.net/#scott",
      "@type": "Person",
      "name": "Scott Wiseman",
      "worksFor": {"@id": "https://intercore.net/#org"},
      "jobTitle": "Founder",
      "sameAs": "https://www.linkedin.com/in/scottwiseman/"
    },
    {
      "@id": "https://intercore.net/#org",
      "@type": "LegalService",
      "name": "InterCore",
      "hasOfficeLocation": {"@id": "https://intercore.net/#sf-office"},
      "url": "https://intercore.net/"
    },
    {
      "@id": "https://intercore.net/#sf-office",
      "@type": "Place",
      "name": "San Francisco",
      "address": {"@type": "PostalAddress", "addressLocality": "San Francisco", "addressRegion": "CA"}
    }
  ]
}

Each JSON object in the @graph array is a node (an entity). The @id uniquely identifies it. The @type declares what kind of entity it is. Properties (worksFor, hasOfficeLocation, etc.) express relationships. When an LLM indexes this JSON-LD, it extracts the triples: Scott worksFor InterCore; InterCore hasOfficeLocation SF-office; SF-office has address CA. These triples become part of the knowledge graph. When someone asks an LLM "Where is Scott Wiseman?" and the LLM has indexed your site, it can answer "San Francisco, California" by following the chain of triples.

The critical insight: JSON-LD is just a syntax for expressing semantic triples. The machine does not care about the format; it extracts the triples and builds a graph. But JSON-LD is easy for tools to validate, parse, and index, which is why it has become standard.

A legal knowledge graph is a network of entities (Attorney, Firm, Court, Practice Area, Jurisdiction, CaseResult) connected by semantic triples. Building a complete graph requires identifying the core entities and the relationships between them. For a law firm, the minimal set includes:

Once these entities and triples are defined in your schema.org JSON-LD, search engines and LLMs build a unified graph. Query resolution becomes precise: "Personal injury lawyers in San Francisco" → find all Attorney nodes where (knowsAbout=PersonalInjury) AND (worksFor.hasOfficeLocation.addressLocality=San Francisco). No inference; all facts are explicit.

The single most important rule for semantic triples: every mention of the same entity must use the same @id. If Scott Wiseman appears on five pages (bio page, team listing, practice-area page, blog author, and testimonial), all five mentions must carry the same @id, e.g., https://intercore.net/#scott. Without this, the knowledge graph treats him as five separate people.

Here is why this matters for AI citation: an LLM building a knowledge graph from your site processes every page independently. If page A says Scott "has 15 years of experience" and page B says Scott "wrote the GEO guide," the LLM needs to know these are the same Scott to combine the information. A shared @id tells it so explicitly. Without it, the LLM might merge the information (correct but unreliable) or keep them separate (incomplete knowledge).

Shared @ids also enable cross-linking. If you link Scott's Person @id to his LinkedIn profile (sameAs: https://linkedin.com/in/scottwiseman/), then when an LLM encounters his LinkedIn entry elsewhere on the web, it can recognize and merge the data. This is entity linking across domains — the foundational technique that powers knowledge graphs like Google's Knowledge Graph and Wikidata.

Common mistakes: (1) Using non-unique @ids — e.g., all attorney nodes share the same @id, https://intercore.net/#attorney. This merges everyone into one entity. (2) Forgetting to add @id altogether — properties reference @id, not just names, so omitting @id breaks the graph. (3) Changing an @id over time — if Scott's page initially uses https://intercore.net/#scott but you later change it to https://intercore.net/team/scott/, the knowledge graph sees a new person (data duplication). Nail down your @id scheme before launch and treat it as permanent.

When an LLM crawls your site to build its knowledge graph, it performs these steps:

1. Fetch every page.
2. Parse the JSON-LD from the HTML head.
3. Extract every triple from the @graph array (subject, predicate, object).
4. For subjects/objects that are @ids, resolve them to a canonical identifier (typically the full URL).
5. Merge triples that share the same @id across all pages.
6. Build indexes optimized for query: subject-to-predicates, predicate-to-objects, object-to-subjects.

Example: You have three pages with attorney triples:

• Page 1 (bio): Scott (@id: .../scott) worksFor Firm (@id: .../#org)
• Page 2 (practice-area): Scott (@id: .../scott) knowsAbout GEO
• Page 3 (team listing): Scott (@id: .../scott) image "...scott.jpg"

The LLM merges all three into a single Person node (the @id is the merge key) with properties: name=Scott, worksFor=Firm, knowsAbout=GEO, image=scott.jpg. Now when a user asks "Who at your firm knows GEO?" the LLM can answer by finding all Person nodes with knowsAbout=GEO and worksFor=YourFirm, which returns Scott immediately.

Triples also power AI citation: when a user asks a question, the LLM's RAG pipeline retrieves relevant passages from your pages, then uses the embedded triples to ground the answer in verifiable facts. A triple like "Scott founded InterCore in 2015" is citable because it is explicitly structured and sourced from your page.

The retrieval pipeline leverages triples as semantic signals. If a user asks "Who founded InterCore?" the system can search the knowledge graph directly (query for objects of founderOf predicates) before falling back to text retrieval. This makes your answers discoverable and citable at scale.

Semantic triples are powerful but fragile. One mistake can corrupt your knowledge graph. Common errors:

To catch these errors before publishing:

1. Use validator.schema.org to check JSON-LD syntax.
2. Load your JSON-LD into a triple-store visualization tool (e.g., Protégé, WebVOWL) and visually inspect the graph. Does every entity have all required properties? Are relationships clear?
3. Test consistency by crawling all pages and checking that @ids are stable and predicates are consistent across pages.
4. Use Google's Rich Results Test and Schema.org validator for warning-level issues (missing recommended properties, deprecated terms).

The fundamental reason triples matter for law firms: they enable AI search engines to understand your practice deeply and cite you accurately. Without triples, your site is opaque to machines — an LLM must infer everything from prose, introducing ambiguity and errors. With explicit triples, every fact is verifiable and machine-readable.

This connects to the broader GEO (Generative Engine Optimization) playbook: traditional SEO optimizes for Google's crawler and links. GEO optimizes for AI engines by ensuring your content is (1) retrievable via embeddings (semantic clarity), (2) citable via passage structure (answer-first, H2/H3, tables), and (3) verifiable via triples (explicit entity graphs). Semantic triples are the third pillar.

A page on your site might declare that you won a specific case with a certain outcome. With plain text, an LLM reads it and may cite it. With semantic triples, you declare CaseResult worksFor Attorney, CaseResult resultDescription, CaseResult award, and CaseResult involvedCourt. An LLM indexing this graph knows the fact is explicitly asserted and can cite it with high confidence. Conversely, if your triples contradict each other or are incomplete, the LLM treats the claim as lower-confidence and may deprioritize it in results.

The payoff: over months, as LLMs index your site's triples, your practice becomes a recognized entity in their knowledge graphs. You become citable not just for individual pages but as an authority on specific practice areas, jurisdictions, and case types. An LLM answering "Who are the top personal injury attorneys in San Francisco?" can reference your entity directly because your knowledge graph is rich and consistent.