Knowledge graphs

A knowledge graph is the form in which a system stores what it knows: entities, the attributes of each, and the relationships between them. Joe Ashta, a GEO / AEO consultant for law firms, works on the part of the graph that describes a firm. This page explains the three elements, how a firm proposes its own node, how outside records confirm it, where disambiguation goes wrong, and why this site publishes its own graph in the open.

Entities, attributes, relationships

An entity is a thing the system can name: a law firm, a lawyer, a city, a practice area, a court. An attribute is a fact about one entity: the firm's legal name, its address, its founding year, its phone number. A relationship connects two entities: the firm is located in Vancouver, the lawyer works at the firm, the firm practises criminal defence, the lawyer is a member of the Law Society of British Columbia.

Written as triples, a criminal defence firm in Vancouver looks like this.

Firm -> locatedIn -> Vancouver, BC
Firm -> practisesIn -> Impaired driving defence
Lawyer -> worksAt -> Firm
Lawyer -> memberOf -> Law Society of British Columbia
Firm -> sameAs -> Law society directory entry
Firm -> sameAs -> Google Business Profile

A system that answers a question about a DUI lawyer in Vancouver walks this graph. It finds the entities connected to impaired driving defence, filters to those connected to Vancouver, and checks how many sources support each edge. The firm with the most, and the most consistent, edges is the firm it is surest about. That is what Entity authority means in graph terms, and it is why the Brand in AI answers page describes a brand as a record.

How a firm proposes its node

A firm's structured data is its proposal for what its node should contain. Schema.org markup on the firm's pages, in JSON-LD, states the entities and edges directly.

• An Organization or LegalService node for the firm, with the legal name, the address, the telephone number and the practice areas.
• A Person node for each lawyer, with the name, the job title, and a worksFor edge pointing at the firm.
• One @id for the firm, used on every page, so that each page adds to the same node instead of minting a new one. A firm whose pages carry ten different identifiers has proposed ten firms.
• sameAs edges to the records the firm holds elsewhere: the law society directory, the Google Business Profile, the LinkedIn company page. These tell the system which outside nodes are this firm.

The proposal is only as good as its agreement with the prose. When the markup says one address and the contact page says another, the system has two candidate values for one attribute and no reason to trust the markup over the text.

How third-party records confirm it

A node the firm wrote is a claim. The system holds it with the confidence appropriate to a self-description. Confirmation comes from records that state the same edges and that the firm does not control. The law society lists the lawyer at the firm's address. A court decision names the firm as counsel in an impaired driving matter. A legal publication describes the firm as a Vancouver criminal defence practice. Each such record raises the confidence on the edge it repeats.

The sameAs edges are how the firm points the system at those records. The records themselves are what confirm the node. Owned pages cannot do this job, because every domain the firm controls is one origin. A firm site, a blog on a second domain and a lawyer's personal site have proposed the same node three times, and confirmed it zero times.

Where disambiguation goes wrong

Two firms with similar names in the same city are the common case. One is a family law practice, the other a criminal defence practice, and both are "Something Law Group" with one word different. A system with weak evidence merges them, and the criminal defence firm inherits family law attributes, or loses its own to the other node. The fix is more edges that only one of the two firms can have: the practice area stated everywhere, the lawyers' names, the exact address, an @id that the outside records point back at.

A lawyer who moves firms is the other common case. Directory entries, old articles and a personal profile still connect the lawyer to the previous firm. The system then holds two worksAt edges for one person and has to choose. Until the older records are corrected or outweighed, the lawyer's reputation continues to accrue partly to a firm that no longer employs them. A firm hiring a lateral should expect this and update the records it can reach.

Why this site publishes its own graph

This site states its graph twice. The GEO consultant for law firms page writes the relationships out as triples in plain text, so a reader or a machine can see the graph without inference. Every page carries the same JSON-LD: a Person node with one identifier, https://joeashta.com/#person, a worksFor edge to the NearMe Marketing organization, and sameAs edges to the LinkedIn and Crunchbase profiles. The entity record is the human-readable version of the same node. Publishing the graph openly is the same advice Joe gives a firm, applied first to himself.

The limit

A graph the firm writes is a claim until an independent record agrees with it. Structured data proposes; it does not confirm. A firm can publish a complete, consistent, single-identifier graph and still be a weak node, because nothing outside its own domains repeats the edges. The sources page on this site exists to show which of Joe Ashta's edges are confirmed and by whom. A law firm should be able to produce the same list, and the GEO work of building a firm's presence in AI answers is largely the work of lengthening it.

Related

Every citation, mention and recommendation a firm earns depends on its node being resolved first.

Entity authority is the state a well-confirmed node reaches. Grounding is how a system fetches the pages it reads the graph from. How AI chooses which law firms to name shows the graph being used to pick one firm over another.