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.

[2026-09-14] ingest | Structured Linked Data as a Memory Layer (WordLift, arXiv 2603.10700)

Ingested at the curator's instruction ("ingest it as T3") after the 08-23 and 09-14 research passes declined it on the bar. Source: structured-linked-data-memory-layer, T3 — all four authors at WordLift, the winning format is the product, one test site is the company blog. published: 2026-03-11. Growth edge 1 annotation updated (still open: a neutral party, or a JSON-LD-aware retriever). Synthesis section The consumer finally measured, by the party selling the page. structured-data-for-ai links to it.

[2026-09-28] ingest | Ontology Pipeline (Jessica Talisman, Technics Publications)

Arrived via Telegram from Lucsw as an Amazon Kindle link. No runner-up spoke. New source page ontology-pipeline — Talisman's six-stage practitioner method (controlled vocabulary → metadata schema → taxonomy → thesaurus → ontology → knowledge graph) for building an organization's formal knowledge layer, from her book Ontology Pipeline: A Framework for Knowledge Engineering (Technics Publications, published: 2026-09-09). Modeled as a DefinedTerm + source: true page, same shape as schema-org and entitymap, since the framework is the thing being documented and the book is its primary source, not a review of someone else's work.

Tier: T3. Talisman is presenting her own trademarked framework, sold through her own consultancy (contextually-llc) and training program (knowledge-graph-academy); the sales-page endorsement is from another data-governance vendor's CDO. Raised above a vendor blog post by 461 pages through a real specialist publisher and named enterprise deployments (an RDF knowledge graph at Adobe, work at the DOJ) rather than unsupported claims.

Fetch problem, resolved. The supplied Amazon URL (.../dp/B0D4M3K5ZX) 500-errored on two WebFetch retries and doesn't resolve to this book at all — the live Kindle ASIN is B0HJ8QWJ5V (paperback: B0HJ9223FH), found via WebSearch and confirmed by scraping it with firecrawl (per the hub's blocked-fetch fallback) after Amazon kept failing WebFetch outright. url: on the page points to Technics Publications' own product page instead, since it isn't ASIN-dependent and carries the fuller table of contents; the corrected ASINs are noted on the page for the record.

Entities (entity-index checked first — all four came back "nothing ≥ threshold; create new"): jessica-talisman (Person, author; same-as her Amazon author page and Substack, both confirmed by direct fetch/search, not guessed), technics-publications (Organization, publisher), contextually-llc (Organization, her consultancy — no independent site found, page rests on her own bio), knowledge-graph-academy (EducationalOrganization, the training program she teaches at — same caveat, no official site found). Named-but-not-paged: her past employers (Adobe, Amazon, Overstock, Pluralsight, Senzing, Vanguard, DOJ, Smithsonian, USC Shoah Foundation) and the endorsing CDO — kept as prose per the relevance gate, since the only evidence for any of them is one line on her own bio page, not independent confirmation of the relationship. Budget: 4 of 8 used.

Synthesis. New section on reading the RDF/OWL/SHACL/SPARQL stack as a build sequence rather than a layered standard; touches open question 2 (does the heavy stack matter in practice?) with T3 practitioner evidence, alongside the existing T1 protege tooling evidence; sharpens coverage edge 7 (SKOS/RDFS/OWL still lack their own pages — this book names SKOS twice without citing the spec). Index and log updated. Ran avoid-ai-writing over all new prose (clean).

[2026-10-02] quality | SHACL from the W3C spec; merchant-listing re-verified

Quality cycle. New shacl (W3C Recommendation 2017-07-20, T1), linked from rdf; coverage edge 4 half closed, residue 4b (SPARQL 1.1 and a triplestore's documentation). merchant-listing-structured-data re-verified against the live page: required core unchanged, four additions recorded, and the 08-30 word "deprecated" for hasEnergyConsumptionDetails struck and corrected (Google says still supported).