Repository navigation
A new base starts with no ontology pack #580
Description
Today a base starts with schema.org unless someone unticks it: the creation dialog pre-selects it (DEFAULT_ONTOLOGY_PACKS in web/src/api.ts, 0008), and the General base made at registration installs it without a dialog (DEFAULT_PACK in api/kbs.rs, #322). The proposal is that a new base starts with no ontology at all; packs stay available and remain the cold start for anyone who picks one.
Why
- schema.org is 800 classes. On a base that has nothing else, it is the whole prompt: The base created at registration installs an ontology no local model can hold #519 measured 105k tokens per chunk once retrieval fell back to the full ontology, and every local 32k endpoint answered 400. The fix there made retrieval run; it did not make the pack a good default for a base whose documents are about something else.
- The Chinese-label question in 0008 has been open since the record and got worse at the 2026-09-02 check: a Chinese base starts with 800 English classes and a handful of aligned labels.
- What The base created at registration installs no ontology pack #322 wanted from the pack, domain and range so a fact has a direction, now has other sources: the ontology grows from the documents under 0003 / 0009 / 0010 with
auto_extend_ontologyon by default, and 0036 has exploration propose the classes a data source needs. An empty start means the first documents shape the ontology instead of a vocabulary the base may never use.
What changes
- Registration installs no pack. The General base is empty until its owner picks one or the first extraction proposes classes.
- The creation dialog pre-selects nothing. The pack list stays, with the same summaries and counts.
- 0008 gets a revision note: packs are a cold start someone chooses, not the default; The base created at registration installs no ontology pack #322 is reversed with the reason.
- Nothing is removed from existing bases.
To measure before deciding it is right
The reason #322 exists: with no classes and no properties, does extraction on a fresh base still produce directed facts, or does it fall back to related_to? Run the extraction bench (scripts/bench/run.mjs, ai-timeline corpus) on a base with no pack against the same base with schema.org, and compare direction rate, related_to share, and the class count the base ends with. That number decides whether cut 1 ships as is or needs the cold-start proposals of 0036 first.
Where this came from: the observation that the default base should not carry a built-in ontology (2026-09-10), against #519's earlier conclusion to keep the pack and fix retrieval. Both are on record; this issue is the place to settle it with a number.
Activity
WaylandYang commentedon Sep 10, 2026
Measured. Two fresh bases on the same server (dev at
0fc44a7e), the same 15 ai-timeline documents (276k chars), DeepSeek-V3.2 through SiliconFlow,auto_extend_ontologyon in both (the product default),bootstrap_ontologyallowed to finish before reading. One with no pack, one with schema.org installed at creation.domain_mismatch, 93direction_corrected)Reading it:
released,acquired,announced; the pack hasemployee,founder,funder), and 342 facts were dropped fordomain_mismatch. After bootstrap the empty base has more directed edges than the pack base, because every relation it minted is a phrase the corpus actually uses.location,company,software,technologywhere the sheet wantsplace,corporation,software_application; those account for 32 of the 89 wrong-class misses. Counting them as right would put the empty base near 83%. The other part is real: 437 entities left untyped, against 34.direction_correcteddrops on the pack base have no counterpart here; some of those edges are presumably backwards in the empty base and this run cannot count them. That is the The base created at registration installs no ontology pack #322 concern, and it stays open as a number to get.MIN_DOCS = 2, so a General base with one file uploaded stays untyped until the second.Where that leaves the proposal: dropping the default pack costs about ten points of type accuracy on this corpus and 20% of entities untyped, and buys extraction calls of ~2k tokens instead of ~18k, an ontology of 13 classes in the base's own vocabulary, and more edges with a predicate. The pack stays one click away for a base that wants schema.org's vocabulary, and the number to watch after the change is the untyped share on real bases.
Single run each; the extraction bench's variance is about ±3 entities on 52, so treat differences under ten as noise. Bases
01a08921-81e5…(no pack) and01a08921-d055…(schema.org) on the bench database, if anyone wants to look.Correction (2026-09-10): the first version of this comment said the schema.org base put ~105k tokens of ontology into the extraction prompt. That is the size of the full class list (497k chars against a 24k budget), which the bench reports as a proxy for ontology scale; since #523 a base over budget retrieves a slice per chunk, and the server's own usage log for these two runs is what the table now shows. The tokens come from
llm usagelines, attributed by size: the 593 calls under 3k are the no-pack chunks and the small adjudication calls, the 383 calls over 10k are the pack base's chunks.