Spokes.wiki Search About

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

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. Hunted again 2026-08-23 — nothing ≥ bar, and the near-miss is worth keeping. One candidate does run the experiment this edge asks for: Structured Linked Data as a Memory Layer for Agent-Orchestrated Retrieval (Volpini, Raad, Gamba & Riccitelli, arXiv 2603.10700, March 2026) — 158 entities across four domains, 349 queries, 2,443 evaluations, seven conditions on Vertex AI Vector Search with a Google ADK agent. It is not ingested (ingested 2026-09-14 at the curator's instruction as structured-linked-data-memory-layer, T3, conflict stated on the page): Volpini and Riccitelli are WordLift's CEO and CTO and the winning condition is a page format their own platform produces, which is the maker measuring their own thing (T3, below the research-pass bar in ../QUALITY.md). Its numbers still bear on this edge, and they cut the way the GEO result did. JSON-LD markup on its own moves accuracy by Δ=+0.17 points, d=0.18 — statistically detectable at p=0.024 and practically negligible — because a flat-text RAG pipeline embeds the page as one chunk and 82–88% of their documents exceeded the ~20k character limit, so the JSON-LD block was often truncated out entirely. What does work, at +29.6% accuracy, is an entity page that materializes the same facts as readable prose with dereferenceable links. The authors' own framing splits the world into engines with dedicated structured-data parsers (Google, Bing) and flat-text RAG, where markup earns "no measurable benefit." So the edge now has a sharper form than "does anything read it": markup helps where something parses it out, and the systems this spoke is worried about do not. Needs, unchanged in kind: the same experiment from a party that does not sell the format. Not re-hunted before 2026-09-06.
  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.

  1. 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. HALF CLOSED 2026-10-02 (quality cycle): shacl is written from the W3C Recommendation (T1). Residue (edge 4b): SPARQL 1.1 and a triplestore's own documentation are still unsourced, so the spoke can now say how RDF is validated but not how it is queried or stored.
  2. 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.
  3. 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.
  4. 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. ontology-pipeline (2026-09-28) uses SKOS by name at two of its six stages without citing the spec itself, which keeps this open rather than closing it.

The consumer finally measured, by the party selling the page (2026-09-14)

structured-linked-data-memory-layer is in the spoke at the curator's call, tiered T3 because WordLift measured WordLift's format. Held at arm's length, it still says something the spoke's proposals (entitymap, yoast-schema-aggregation, structured-data-for-ai) have to answer: in a mainstream flat-text RAG pipeline the JSON-LD was mostly truncated out before indexing (88% of documents past the ~20k-character cut, the script block at a median character 18,510), and the +29.6% came from writing the graph's facts as prose. Read next to ../search-marketing-wiki's GEO paper, the corpus now has two experiments, one neutral and one interested, that agree: what a generative retriever consumes is text, and markup only helps where something parses it out first. The spoke's thesis — publish a machine-facing description — survives only in the second clause.

A practitioner method for the whole stack, from the self-interested side (2026-09-28)

ontology-pipeline (Jessica Talisman, Technics Publications, T3) is the first source in this spoke that reads the rdf → RDFS/OWL → SHACL/SPARQL stack as a build order rather than a layered standard: controlled vocabulary → metadata schema → taxonomy → thesaurus → ontology → knowledge graph, each stage tested before the next starts. It bears on open question 2 (does the heavy stack matter in practice?) with practitioner-side evidence — an RDF-based knowledge graph built at Adobe, ontology work at the Department of Justice — but T3 evidence, since Talisman is describing her own consulting and training work, not a measured deployment. It doesn't settle the question; it adds a data point on the side of "yes, people still build the heavy stack," which the existing protege T1 source already established from the tooling angle. The book also names SKOS explicitly at two stages, which sharpens rather than closes coverage edge 7 (the vocabularies under schema.org still lack their own pages).

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:

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

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)

SoftwareApplication (tools / sources)

TechArticle (sources)

ScholarlyArticle (sources)

Organization

Person

DiscussionForumPosting (sources)

Synthesis

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)

Related pages

Links to

Linked from