Synthesis — Knowledge Representation

The evolving thesis. Spun out of the hub _inbox knowledge-representation cluster on 2026-06-18, seeded by rdf (the data model), schema-org (the deployed vocabulary), and ontology-dev-tools (the authoring layer). The domain: describing meaning so machines can reason over it — the semantic web and formal knowledge representation.

Current thesis

The field has a layered stack and a deployment gap, and the two together are the story.

The stack. rdf is the base: everything is a triple (subject–predicate–object), and triples form a directed graph. It’s an abstract model — its many serializations (Turtle, JSON-LD, RDF/XML, N-Triples) are interchangeable skins over the same graph, which is why “RDF ≠ RDF/XML” is a recurring correction. Resources are named by URIs/IRIs that need not be dereferenceable — a URI is an identifier, not necessarily a fetchable address. On top of RDF sit the schema/ontology languages (RDFS → OWL, adding classes, hierarchies, and reasoning) and SHACL (validation/shapes), queried with SPARQL. Each layer adds expressive power and cost.

The deployment gap — the field’s defining tension. The ambitious end of the stack (rich OWL ontologies, automated machine reasoning — the capital-S “Semantic Web” vision) has always been heavier to author and adopt than promised; rdf‘s own documented criticisms are verbosity, URI wordiness, and a steep learning curve. The part that actually won at internet scale is the pragmatic, shallow end: schema-org — a single shared vocabulary, mostly expressed as JSON-LD, on 45M+ domains / 450B+ objects, driven by a concrete incentive (search rich-results). So the same triple foundation supports both a largely-unrealized reasoning vision and a wildly-successful structured-data layer; the lesson so far is that adoption tracks a concrete payoff and a low authoring cost, not expressive power. The ontology-dev-tools question (which Protégé-class editor to use) is the authoring-cost problem made concrete — the heavy end of the stack still needs specialist tools like protege (Stanford’s OWL 2 editor), which is part of why it stayed niche, yet whose use in the OBO Foundry, WHO ICD-11, and the NCI Thesaurus shows the reasoning end persists where the payoff is concrete.

Reflexive note. schema-org is not just a case study here — it’s the @type vocabulary this very hub runs on (every spoke’s pages are schema.org-typed JSON-LD frontmatter). This spoke is the natural home to document the model the wiki itself is built on.

The consumer is changing

Three sources arrived together — merchant-listing-structured-data, yoast-schema-aggregation, entitymap — and together they describe a shift in who structured data is published for. They’re three positions on one line, and the first is the incumbent the other two want to leave.

merchant-listing-structured-data is the classic model at its most concrete: markup embedded in the page, crawler reads the page, engine renders a richer result. It also puts hard numbers on the low-authoring-cost thesis — five required properties (name, image, offers, plus price and priceCurrency on the nested Offer) buy eligibility, and everything beyond that is optional detail that each unlocks one visual treatment. And it exposes something the vocabulary itself hides: the binding rules aren’t in schema.org. Single-product pages, one URL per currency, crawlability, excluded product categories — the consumer’s eligibility document is what publishers actually implement against. A shared vocabulary with an unshared payout is governed by whoever pays.

Then the other two move the description out of the page. yoast-schema-aggregation keeps the markup but changes delivery: one WordPress REST endpoint serving the whole site’s graph with duplicate entities merged. entitymap goes further and proposes a new file at a predictable URL — entitymap.json, entities with entityId, sameAs, typed relations — explicitly analogized to sitemap.xml. The trajectory is from inferred by the consumer to declared by the publisher, and ../search-marketing-wiki’s llms-txt made the same move a year earlier without an entity model.

Most of this is the semantic web with the serial numbers filed off, which is why it belongs here rather than in an SEO spoke. Stable identifiers, sameAs, typed relations between entities: rdf has expressed all of it from the start, and schema-org carries sameAs today. What the heavy stack never had was a publisher-side reason to author the graph — the deployment gap above, restated. These proposals are bidding for AI visibility to be that reason, and they repackage a thin slice of RDF semantics with a memorable filename, which is precisely the shallow-and-concrete formula that got schema.org to 45M domains in the first place.

One field escapes that reading. entitymap‘s hasChunks — a claim, the URLs that support it, relevance scores, attribution — has no schema.org equivalent, because it isn’t modelling meaning, it’s modelling retrieval: which passage grounds which assertion, and who gets credit for it. That’s a RAG-shaped concept, not an ontology-shaped one, and it’s the one place this thread is inventing rather than re-serializing. Where the spoke’s second open question asks how LLMs sit relative to RDF, this is the sharpest partial answer so far: not as reasoning, as retrieval scaffolding.

Open questions

• Does the heavy stack (OWL reasoning) matter in practice, or did the shallow slice (schema.org JSON-LD) win the whole game? Watch whether incoming sources are reasoning/ontology systems or more structured-data/linked-data deployments.
• Where do LLMs sit relative to RDF? Knowledge graphs (Wikidata/DBpedia are RDF) increasingly back retrieval/grounding for LLMs — is formal KR being absorbed as an LLM substrate, or competed with? (Tie to research-wiki’s knowledge-graph and the agentic/RAG threads in sibling spokes.) Partial answer (2026-07-28): absorbed, and at the shallow end. entitymap and yoast-schema-aggregation reach for entity identity, sameAs and typed relations — RDF’s vocabulary, not its reasoning — as retrieval scaffolding for AI systems. Nobody in this cluster wants inference; they want disambiguation and attribution. The one genuinely new construct, hasChunks, is retrieval-native rather than ontology-native. What’s still missing is a consumer: no AI system is documented as reading any of these artifacts, so this is the field offering itself as substrate rather than evidence of being used as one. See structured-data-for-ai.
• Does publishing beat inferring? New with this cluster. Every proposal here moves the description out of the page and to a predictable URL, on the premise that a publisher’s declaration is worth more to a machine than what the machine can extract itself. Models have gotten markedly better at extraction over the same period, which is the case against — and llms.txt’s reception is the cautionary precedent. Watch whether any consumer commits to reading a published artifact.
• Authoring cost. Answered (2026-06-30, protege). The authoring-tools layer now has a T1 anchor: protege (Stanford’s free, open-source OWL 2 editor; Desktop + WebProtégé), replacing the blocked-Reddit T4 stub as the spoke’s source for how heavy ontologies get built. It also sharpens the deployment-gap thesis: Protégé is the specialist tool the heavy stack needs, and the fact that it underpins the OBO Foundry, WHO ICD-11, and the NCI Thesaurus shows the OWL end is alive where the payoff justifies the authoring cost. Residual sub-gap: SPARQL/SHACL tooling and triplestores are still unsourced.

Growth edges

Ranked; each names the kind of source that would close it (see ../QUALITY.md → Growth edges).

1. A documented consumer. This spoke holds a cluster of proposals for publishing machine-readable description (entitymap, yoast-schema-aggregation, structured-data-for-ai) and no evidence any AI system reads them. That makes the whole thread the field offering itself as substrate. — needs: T1/T2 evidence of a model or retrieval system consuming these artifacts · hunted 2026-08-08 — nothing ≥ bar, and the nearest evidence points the wrong way. Searching for a measured effect of schema.org, JSON-LD or llms.txt on model or retrieval behaviour returns the SEO-tooling genre asserting that it matters, plus RAG papers about structured data inside documents, which is a different claim. Meanwhile the one controlled study in the corpus on being surfaced by a generative engine — the GEO paper now in search-marketing-wiki — measures gains from prose-level edits (adding statistics, quotations, cited sources) and not from markup at all. That is weak evidence against this spoke’s thesis, and it belongs on the edge rather than buried. Not re-hunted before 2026-08-22.
2. Does the heavy stack matter in practice? OWL reasoning versus the shallow schema.org slice that plainly won distribution. — needs: a deployment report or survey of production reasoning use.
3. Publishing versus inferring, measured. The premise is that a publisher’s declaration beats what a model can extract — as extraction improves, that premise weakens. — needs: any comparison of declared versus extracted structured data.

Coverage edges (added 2026-08-08, at the curator’s request for a wider backlog). These widen what the spoke covers instead of answering an open question above; one ordinary solid source closes any.

4. The query and validation layer. SPARQL, SHACL and a triplestore are named in the open questions as a residual gap and still have no page, so the spoke can describe RDF and not what anyone does with it. — needs: the W3C recommendations, plus one triplestore’s own documentation.
5. The two graphs that actually exist. Wikidata and DBpedia are the largest live RDF deployments and the substrate the LLM question above is really about. — needs: their own documentation or a published paper, one page each.
6. Property graphs as the rival model. Neo4j, Cypher and the GQL standard took most of the industrial graph market while RDF took the standards, and the spoke never states the comparison. — needs: the GQL standard or vendor docs, plus one honest comparison.
7. The vocabularies under schema-org. Dublin Core, SKOS and RDFS/OWL themselves have no pages, so the layering of the stack is asserted rather than shown. — needs: the specifications.

Contradictions / tensions

The vision-vs-deployment tension above is structural, not a fact conflict. The first real conflict arrived 2026-07-28, and both sides stay on the record:

• The vendors. yoast-schema-aggregation: “Your content cannot be visible in AI if it is not understood correctly.” entitymap: current AI retrieval fails at disambiguation, attribution and relationships, and a published entity file fixes it.
• The consumer. Google’s own guidance (../search-marketing-wiki’s google-ai-optimization-guide, T1) says structured data “isn’t required for generative AI search” — it earns rich results and is not a gate on generative features — and that of llms.txt, “Google Search itself doesn’t use them.”

So the largest consumer of structured data on the web says structured data is not the AI-visibility lever, while the tooling market sells products premised on it being exactly that. Both parties are interested: Google describes only its own systems and would rather publishers not chase hacks; the vendors sell the hack. Neither has published a measurement, and no AI system is documented as fetching an aggregated endpoint or an entitymap.json. Kept as a live conflict — see structured-data-for-ai for what would settle it.

Cross-spoke adjacency

• research-wiki — owns the knowledge-graph node and the typed-pages / “mechanize thought” theme, but as markdown-PKM + formal-methods content; this spoke is the RDF/OWL/semantic-web tradition. Different lineage, linked not duplicated.
• agentic-tooling-wiki / llm-providers-wiki — where RDF knowledge graphs meet LLMs (RAG grounding, Wikidata-backed retrieval); the KR substrate lives here, the agents/models there.

Index — Knowledge Representation Wiki

Catalog of every page, grouped by schema.org @type. Spine: synthesis (thesis), log.md (history), this file (catalog). Read this first when answering a query, then drill into the relevant pages. Some wiki-links resolve cross-wiki (research-wiki’s knowledge-graph) — intentional bridge links.

DefinedTerm (concepts / standards / vocabularies)

• knowledge-representation — umbrella: describing meaning so machines can reason; the semantic-web stack and this spoke’s axes · domain
• rdf — Resource Description Framework: the W3C subject–predicate–object triple graph model under the semantic web · source · standard
• schema-org — the cross-search-engine structured-data vocabulary (JSON-LD/Microdata/RDFa); a widely-deployed lightweight web ontology · source · vocabulary
• structured-data-for-ai — the 2026-07-28 thread: publishing a machine-facing description for AI systems rather than embedding markup for crawlers; markup leaving the page (embedded → aggregated endpoint → standalone file), and the vendors-vs-Google conflict over whether it does anything · theme
• entitymap — proposed open standard: entitymap.json at a predictable URL (“sitemap tells crawlers what pages exist, entitymap tells AI what a site knows”); entities with entityId/sameAs/typed relations/hasChunks; v1.0 CC BY 4.0, one vendor implementation · source · T3 · entitymap.org

SoftwareApplication (tools / sources)

• yoast-schema-aggregation — Yoast SEO feature: merges a WordPress site’s per-page schema graph into one deduplicated REST endpoint for AI consumption (NLWeb cited as a build target); engineering real, benefit asserted · source · T3 · yoast.com
• protege — Stanford’s free, open-source OWL 2 ontology editor (Desktop + WebProtégé); the authoring-tools T1 anchor (OBO Foundry, WHO ICD-11, NCI Thesaurus) · source · T1 · protege.stanford.edu

TechArticle (sources)

• merchant-listing-structured-data — Google Search Central: Product+Offer markup for shopping surfaces — five required properties, dozens of recommended ones, and eligibility rules that live outside schema.org entirely · source · T1 · developers.google.com

Organization

• yoast — maker of Yoast SEO; a structured-data implementer at scale (the plugin authors the graph most publishers never write)
• inlinks — InLinks Optimization Ltd; maintains entitymap and its one reference implementation

DiscussionForumPosting (sources)

• ontology-dev-tools — r/semanticweb thread on the best ontology development environment (Protégé-class RDF/OWL editors) · source · T4 (stub)

Synthesis

• synthesis — the evolving thesis (open questions + flagged contradictions)

Bridge nodes (live in sibling wikis, linked cross-wiki)

knowledge-graph (research-wiki) · google-search-central (search-marketing-wiki) · google-ai-optimization-guide + llms-txt (search-marketing-wiki — the counter-evidence and the precedent for structured-data-for-ai)