EntityMap
A proposed open standard for publishing a site’s entity index as a file at a predictable URL, so AI systems can read what a site knows without inferring it from prose. Its own analogy is the sharpest summary: “sitemap.xml tells crawlers what pages exist, entitymap.json tells AI systems what a site knows.” Version 1.0, marked Stable, CC BY 4.0.
T3 rather than T1: it’s self-published by parties with a commercial interest in entity-based SEO
tooling, and “open standard” here means one organization’s document plus a GitHub repo, not a
multi-vendor process like the one behind schema-org. Initiated by Fred Laurent with support from
Dixon Jones, maintained through Waikay / InLinks Optimization Ltd, with one reference
implementation (the Waikay EntityMap Generator). Ingested from the homepage — the /spec/ path returns
403 to both WebFetch and Firecrawl, so field-level detail below is what the homepage documents and the
full specification is unverified.
What it specifies
Two files: entitymap.json for machines, entitymap.html as a human- and crawler-readable view. Each
entity carries entityId, @type (the homepage’s examples use DefinedTerm), name, description,
sameAs for external identifiers, relations for typed predicates to other entities, and hasChunks
— source evidence as URLs with relevance scores and attribution.
The three problems it says current AI retrieval gets wrong: disambiguation (one concept under several names read as several signals), attribution (publisher identity lost when content is aggregated), and relationships (connections stated in prose rather than declared).
Most of this already exists
Strip the packaging and the entity model is a small RDF graph. entityId is a URI. relations
with typed predicates are triples. sameAs is a schema.org property (and an OWL one) that has meant
exactly this — same referent, different identifier — for two decades. @type is schema.org’s own
keyword. Disambiguation-by-stable-identifier and declared relationships are not gaps in the semantic
web; they are the parts of it that shipped.
Which makes EntityMap a re-run of this spoke’s deployment-gap pattern rather than a counterexample to it. The heavy stack was always able to express this; what it never had was a publisher-side incentive strong enough to make people author it. EntityMap’s bet is that AI visibility is that incentive, and it repackages a thin slice of RDF semantics as a single file with a memorable name and a sitemap analogy — the same shallow-and-concrete formula that made schema-org the one piece of the semantic web to reach 45M domains. The site invokes GoodRelations as precedent, which is a fair citation: a publisher-driven vocabulary that got absorbed once search engines paid for it.
hasChunks is the genuinely new field. Chunk-level evidence — a claim, the URLs supporting it,
relevance scores, attribution — has no schema.org equivalent, because it isn’t a semantic-web concept.
It’s a retrieval concept, shaped by how RAG systems actually consume text. That’s the seam where
this standard stops imitating the old stack and starts describing the new consumer.
What isn’t established
Adoption is one reference implementation by the maintaining vendor. No AI system is documented as
reading entitymap.json. The standard acknowledges no open questions, which for a v1.0 marked “Stable”
is itself a signal about how it was produced. The discovery mechanism (robots.txt, link rel,
well-known path) isn’t described on the homepage, and the relationship to schema.org, JSON-LD,
sitemaps and llms.txt is never stated — a curious omission for a format that borrows schema.org’s
@type and sameAs outright.
The obvious comparison is llms-txt in ../search-marketing-wiki: another proposed file at a
predictable path, another bid to be the machine-facing artifact, and one that Google has said plainly
it does not read. See structured-data-for-ai.
Related
structured-data-for-ai · schema-org · rdf · yoast-schema-aggregation · merchant-listing-structured-data · inlinks · knowledge-representation · synthesis