Log — Knowledge Representation Wiki

Append-only history. Each entry starts with ## [YYYY-MM-DD] <op> | <title> where <op> is ingest, query, lint, or split, so grep "^## \[" log.md | tail -5 works.

[2026-06-18] split | knowledge-representation-wiki created from _inbox (3 sources)

Spun out of the hub _inbox knowledge-representation cluster at the human’s call (Telegram msg 526→“1”), once rdf arrived as the trigger completing ≥3. Decision was new-spoke vs. fold-into-research-wiki (flagged twice by the prior router); human chose a dedicated spoke. Migrated the two parked records (schema-org, ontology-dev-tools) and ingested the trigger rdf. Domain: formal knowledge representation / the semantic web — a distinct tradition (RDF triples, OWL, SPARQL, structured-data vocabularies) from research-wiki’s markdown-PKM + formal-methods content; cross-links the research-wiki knowledge-graph bridge rather than duplicating it. The two _inbox records were deleted on migration.

[2026-06-18] ingest | RDF (Wikipedia) — trigger source

Resource Description Framework — the W3C triple (subject–predicate–object) graph data model under the semantic web. Abstract model with many serializations (Turtle, JSON-LD, RDF/XML, N-Triples); resources named by URIs/IRIs (needn’t be dereferenceable). The base layer beneath RDFS/OWL/SHACL (schema/ontology) and SPARQL (query). First W3C rec 1999; RDF 1.1 (2014) current. Powers Wikidata, DBpedia, FOAF, schema.org. T2 (Wikipedia — authoritative encyclopedic overview of a W3C standard; tertiary, the specs themselves are the T1). New page rdf (source) + knowledge-representation umbrella. Founding synthesis seeded on the layered-stack thesis.

[2026-06-18] ingest | schema.org (vocabulary) — migrated from _inbox

schema.org — collaborative structured-data vocabulary for the web (Google/Microsoft/Yahoo/Yandex; open W3C-style process). Encodings RDFa / Microdata / JSON-LD; 45M+ domains, 450B+ objects; used for search rich-results and knowledge graphs. A lightweight, mass-adopted web ontology — and reflexively the @type vocabulary this whole hub runs on. T1 (primary — the vocabulary’s own site). New page schema-org (source). Folded into synthesis (the “deployed vs. theoretical KR” thread). url-only.

[2026-06-18] ingest | ontology-dev-tools (r/semanticweb) — migrated from _inbox

Reddit r/semanticweb thread asking for the best ontology development environment (RDF/OWL editors, Protégé-class). Reddit blocks automated fetch → honest stub from title + subreddit; body unread. T4 (forum question, unverified, unread). New page ontology-dev-tools (source). Records the authoring-tool layer of the stack as a known gap to fill with a real T1/T2 source (e.g. a Protégé page). Folded into synthesis open questions. url-only.

[2026-06-30] ingest | Protégé — ontology-editor T1, closes the authoring-tools gap (quality cycle)

Weakest-first quality-cycle floor-raise. The spoke’s only non-T1/T2 source was ontology-dev-tools, a T4 blocked-Reddit stub; synthesis named “a real T1/T2 source on ontology editors” as the highest-value next add. Added protege (SoftwareApplication, T1, protege.stanford.edu) — Stanford’s free OWL 2 editor (Desktop + WebProtégé, Java plug-in core). Closes the “Authoring cost” open question and sharpens (doesn’t contradict) the deployment-gap thesis: Protégé is the specialist tool the heavy stack needs, and its use in the OBO Foundry / WHO ICD-11 / NCI Thesaurus shows the OWL-reasoning end is alive where the payoff justifies the cost. Kept the T4 stub (record-don’t-overwrite). Maintainer entity (Stanford University) deferred — single-connection, kept in prose per precedent. Threaded into synthesis (thesis + open-Q) + index. Floor T1 1→2 (of 4 sources). Ran avoid-ai-writing (clean). +1 page (→5).

[2026-07-28] ingest | Structured data for AI — three sources (Google merchant listing · Yoast Schema Aggregation · EntityMap)

Routed here by the hub as one cluster; runner-up spoke was search-marketing-wiki. All three arrived within four minutes over Telegram and are treated as one ingest because they’re three positions on one question, not three topics. New: merchant-listing-structured-data (T1, TechArticle), yoast-schema-aggregation (T3, SoftwareApplication), entitymap (T3, DefinedTerm+source — the schema-org precedent for a standard whose homepage is the source), structured-data-for-ai (theme), yoast + inlinks (entities). Updated: schema-org (two new sections), synthesis (new thesis section, first real contradiction, two open questions), index.

Why here and not search-marketing-wiki. All three come out of the SEO world — Google Search Central, a WordPress SEO plugin, a standard from an entity-SEO vendor. But the substance of each is vocabulary and data model: which schema.org types and properties, how a graph is identified and deduplicated, what fields an entity file carries. The SEO angle is the application. Runner-up logged; cross-links go both ways.

The finding. The three sit on one line, and it’s a line away from the page: markup embedded in the document (merchant listing) → the same markup aggregated to one REST endpoint (Yoast) → a separate entitymap.json at a predictable URL (EntityMap). From inferred by the consumer to declared by the publisher. llms.txt in search-marketing-wiki made the move a year earlier without an entity model.

And most of it is RDF with the serial numbers filed off. entityId is a URI, relations are triples, sameAs is a schema.org/OWL property that has meant this for twenty years. The heavy stack could always express it; what it lacked was a publisher-side reason to author it. These proposals bid for AI visibility to be that reason — which is the spoke’s deployment-gap thesis running again rather than a counterexample to it. Exception worth watching: EntityMap’s hasChunks (claim + supporting URLs + relevance scores + attribution) has no schema.org equivalent because it models retrieval, not meaning. That’s the one construct here that isn’t a re-serialization, and it’s the sharpest partial answer yet to the spoke’s “where do LLMs sit relative to RDF” question: absorbed as retrieval scaffolding, not as reasoning.

First real contradiction in this spoke, recorded both ways. Yoast: “Your content cannot be visible in AI if it is not understood correctly.” EntityMap: current AI retrieval fails at disambiguation and attribution. Google, first-party (search-marketing-wiki’s google-ai-optimization-guide, T1): structured data “isn’t required for generative AI search.” The biggest consumer of structured data says it isn’t the AI lever; the tooling market sells it as exactly that. Both interested, neither measured, and no AI system is documented as fetching either artifact.

Also worth keeping from the Google doc: eligibility rules that aren’t in schema.org at all — page must sell the product, single-product pages only, one URL per currency, crawlable, no regulated goods. The vocabulary says what you can express; the consumer says what expressing it earns. Governance sits with whoever pays out.

Tier notes: merchant listing T1 (first-party doc, volatile — Google changes required properties and surfaces on its own schedule). Yoast T3 (vendor feature page, promotional, unmeasured). EntityMap T3, not T1 — “open standard” here is one organization’s document plus a GitHub repo, self-published by a party selling entity-SEO tooling; not a multi-vendor process like schema.org’s. Fetch note: entitymap.org /spec/ returns 403 to both WebFetch and Firecrawl (per HUB edge handling, Firecrawl was tried). Field detail on the page is the homepage’s and is marked unverified; discovery mechanism and versioning are unknown. Entities: yoast and inlinks paged as Organizations. Fred Laurent and Dixon Jones noted inline only — the homepage is the sole evidence held for them, and evidence-only applies. google-search-central reused cross-wiki from search-marketing-wiki via entity-index, not duplicated. Verify deferred per hub policy (content-only). avoid-ai-writing run.