Moved to App Settings in v0.129.0

The tuning values on this page are configured in the in-app App Settings screen (sidebar footer, sliders icon) and stored in app_settings.jsonc -- not in .env. A value left in .env is ignored and named once in the startup log; run chatwalaau settings migrate --write to carry an existing configuration across. Feature enable-gates and secrets stay in .env. See Configuration -> Application settings.

Ontology Concept Modeling

The Ontology workspace lets you design concept models -- the essential entities, relationships, and properties of a domain -- as RDF knowledge graphs of Subject-Predicate-Object triples. Each ontology is a standard, self-contained Turtle file -- or a TriG file once it has named graphs -- you can version, share, and open in any RDF tool.

The feature is on by default since v0.130.2. It costs nothing until you use it: no secret, no shell, no outbound call, and .ontologies/ is created only on your first write.

Turning it off

ONTOLOGY_ENABLED=false
# optional: where the ontology files live (created on demand)
ONTOLOGY_DIR=.ontologies

Setting it to false hides the sidebar icon, makes the API return 404, and drops the read-only ontology_query tool from the agent.

When enabled, a network icon appears in the sidebar footer (next to the Declarative Agents icon). It opens a full-screen workspace with three freely resizable panes.

The workspace

• Left -- catalog. Your ontologies, each with a name and a description (write a good description: it is how the assistant picks the right ontology). Create a new one, rename it (name and description, in place -- the ontology and its graph are preserved), import an RDF file (Turtle, TriG, N-Triples, N-Quads, RDF/XML or JSON-LD), export it in any of those six formats, or delete (with a confirmation, a progress indicator, and a backup kept on disk). Drag the list into the order you want (v0.190.0).
• Center -- design canvas. Entities are two-ring circles: drag the inner circle to move the node, and start or end a relationship anywhere on the outer ring -- a full 360°, so connections attach from any direction and follow the nodes as you move them. Edges are directional with a cardinality -- 1:1, 1:N, N:1, or N:M. When two or more relationships connect the same pair of entities they fan out along separate curves (each individually selectable, with its own label); a relationship from an entity to itself draws as a loop. Clicking an entity also lights up its incoming / outgoing relationships and the connected entities (clicking a relationship lights up its endpoints and their edges); click an empty area to clear. Drag from one node to another to create a relationship. Pan and zoom, fit to view, one-click auto-layout, and download the graph as a PNG.
• Right -- Detail / Resources / Search. Detail edits the selected entity or relationship; each entity property can be marked as a key attribute (a key badge appears on the node), and All statements shows everything said about the selected item -- including what the form does not show -- with add / edit / delete. Resources lists everything the canvas does not draw (see below). Search runs SPARQL (syntax-highlighted editor, with a Reset button that restores the default query) or a natural-language question -- the send button converts it to SPARQL via the model and puts the generated query in the editor so you can refine it. Table results highlight the matching entities on the canvas in strong color while everything else dims, with connected relationships re-colored.

Saving writes a timestamped backup before atomically replacing the file, and closing with unsaved changes asks for confirmation first. If the ontology was saved from another tab after you opened it, Save is refused and a Reload button appears, so one tab never silently overwrites another.

Nothing is lost when you edit (v0.175.0)

Every statement of an ontology is part of what you edit -- not only the parts that fit the entity / relationship form.

• Resources tab. Instances, terms of other vocabularies, annotations (reifiers), lists and blank nodes -- everything the canvas does not draw -- are listed here with a filter. Select one to see and edit its statements, or add a new resource with + Resource.
• A typed value editor. A value can be an IRI (prefixed names such as owl:Class work), a blank node, a literal with datatype, language and text direction, or an RDF 1.2 triple term <<( s p o )>>. Blank nodes used once are shown nested, RDF lists as ordered lists, statements that carry annotations get an annotated badge, and values that do not match their datatype get an ill-typed warning -- they are kept exactly as written.
• Several values are kept. A label in English and another in Japanese both stay; the field shows one (untagged, then English) and the others appear as chips under it. Editing the shown label keeps its language. A property with several domains appears under each of its entities, marked shared; a range that is an expression (such as [ owl:oneOf ( ... ) ]) is shown as expression and edited in the statements list.
• Document dialog (header button). The prefixes, base and VERSION of the ontology. They come through import (Turtle and RDF/XML) and appear at the top of the exported Turtle. Comments and the original formatting of an imported file are not kept: the file is written in a canonical form.
• Positions. Entities without a saved position are laid out automatically when you open the ontology; positions are saved only when you move a node or use Reset Layout. A save without edits adds nothing to the file.
• Deleting and annotations. Deleting an entity keeps what other resources say about it and tells you how many statements that is. Editing a statement that has annotations asks whether the annotations should follow the edit (the default) or stay on the old statement.

API change in v0.175.0

GET / PUT /api/ontology/{id} exchange a new JSON shape: document (prefixes, base, version), resources (each subject with all its statements, every value typed) and revision. Scripts that call these two endpoints directly must be updated. A PUT with an outdated revision is refused with 409 stale_revision.

Query results match the file (v0.176.0)

Search results and the assistant's answers show the values exactly as the ontology file writes them.

• Exact values. "01" stays 01, "1.50" stays 1.50, and a date-time keeps its milliseconds. Each value in a table shows its language (@ja), text direction and datatype (xsd:integer), so a number and a text are easy to tell apart.
• Links into the editor. IRIs and blank nodes in a result use the same names as the editor (_:b1), and clicking one opens that resource.
• Notes when the query engine cannot match the file. The query engine treats "01", "1" and "+1" (as integers) as one value. A CONSTRUCT result brings all of them back. When a count or a text function (STR, REGEX, ...) works on the engine's single value, a note above the result says so, and a value written in several ways is marked ambiguous with its spellings listed.
• Files without a base import. A file that uses relative IRIs (<#Person>, rdf:about="#Person") but declares no base now imports; those IRIs are placed in the new ontology's own namespace.
• Checked against the W3C tests. The official W3C RDF 1.1 and RDF 1.2 test suites for Turtle and RDF/XML run through import, editing, save, export and search on every test run. Four RDF/XML tests about XML literal formatting are known exceptions in the underlying RDF library.

Named graphs, formats and annotations (v0.177.0)

Named graphs

An RDF dataset groups statements into named graphs -- for example one graph per source, version or team. Import a TriG (.trig) or N-Quads (.nq) file, or add a graph yourself with the layers button above the canvas.

• Graph selector. Once an ontology has a named graph, a selector above the canvas shows All graphs, Default graph or one named graph. The canvas and the Search tab follow it, and the search says which graphs it covers. "All graphs" counts a fact that several graphs hold once. A GRAPH <name> { ... } pattern in SPARQL can still name any graph.
• Where new statements go. While a named graph is selected, everything you add goes into it. Node positions always stay in the default graph.
• Statements show their graph. In the inspector each statement shows a graph chip; edit a statement to move it to another graph. The Resources tab can filter by graph.
• Saved as TriG. An ontology with a named graph is stored as <id>.trig; when the last named graph is emptied it goes back to <id>.ttl. A graph without statements is not saved.

Downgrade

Versions before v0.177.0 only know <id>.ttl files and will not find an ontology that has been saved as TriG. Export it first if you might downgrade.

Import and export formats

Format	Extension	Named graphs	Annotations (triple terms)
Turtle	.ttl	no	yes
TriG	.trig	yes	yes
RDF/XML	.rdf, .owl, .xml	no	yes
JSON-LD	.jsonld, .json	yes	no
N-Triples	.nt	no	yes
N-Quads	.nq	yes	yes

• Export refuses instead of dropping. When a format cannot hold your ontology -- named graphs in Turtle, annotations in JSON-LD, or a name RDF/XML cannot write (such as a property ending in a digit) -- the export menu explains why and lists example statements (click one to open it). Nothing is silently left out.
• Every export is checked. The file is read back and compared with the ontology before you download it.
• Prefixes. N-Triples, N-Quads and JSON-LD have no prefixes; IRIs are written in full and the menu tells you so.
• JSON-LD import. Prefixes and @base from the top-level @context are kept. @json values are normalized by the JSON-LD rules (keys sorted). A file that points to a remote @context (for example "https://schema.org/") is refused with a message; the server never downloads it. Replace the URL with the context itself.

Annotations

Hover over a statement in the inspector and choose Add annotation to say something about the statement itself -- its source, date or confidence. This creates a reifier: a resource with an IRI in your ontology (...#r-1a2b3c4d, which you can change) that rdf:reifies the statement, plus an optional first annotation. It is added to the statement's graph, and a statement can have several. Deleting an annotated statement asks whether its annotations should go too; Keep the annotations is the default.

For scripts

POST /api/ontology/{id}/statements applies add, remove, replace and annotate operations in one atomic save (with the current revision). A replace moves the statement's annotations to the new statement unless the old statement is still present in another graph. Send projection_version: 3 with PUT; saving an ontology that has named graphs without it is refused (graph_unaware_client), so an older script cannot move every statement into the default graph by accident.

Faster searches and safer saves (v0.178.0)

Repeated searches answer at once. The first search on an ontology loads it; the next ones -- SPARQL, natural language or the assistant's questions -- reuse the loaded copy. At the 10 MiB size cap the first search takes a few seconds and the following ones a few tens of milliseconds. The copy is tied to the exact bytes of the file, so after any save the next search sees the new version. The memory used is bounded by App Settings > Limits > Ontology query cache (MiB) (default 512; 0 turns it off); the least recently used ontologies are dropped first. Searches and saves also no longer pause other users' chats while a large ontology loads.

Saves send only what changed. The editor sends the statements you added and removed, not the whole ontology. If someone else (or another tab) saved first:

• edits to different statements are merged, and the editor reloads to show both;
• an edit to a statement that was removed or changed elsewhere is listed and nothing is saved -- choose Reload to see the latest version (your unsaved changes are discarded);
• node positions take the last save.

Two people can each add a different label to the same resource; both labels are kept, because an RDF ontology is a set of statements. Changes to prefixes, base or VERSION (the Document dialog) still save the whole ontology and are refused if someone saved first.

For scripts, POST /api/ontology/{id}/statements accepts "on_stale": "rebase" (the rules above; 409 stale_conflict lists the conflicting operations) and "fresh_blank_nodes" (the blank-node labels the script created; the server renames any the file already uses and returns blank_nodes). Without on_stale it behaves as before (409 stale_revision on an older revision).

History and restore (v0.179.0)

Every save, import and restore of an ontology is a version. Open the History tab next to Detail / Resources / Search:

• the list shows each version with what produced it ("Saved 3 changes", "Imported", "Restored the version of ...") and when;
• select a version to see Changes in this version -- exactly which statements it added (green) and removed (red), with their graphs -- or switch to Compared with now to see what restoring it would change. Changes to prefixes, base or VERSION are listed too;
• Restore this version asks for confirmation with the counts, then saves that version as a new one. Nothing is lost: the version it replaced is in the list, so a restore can be undone the same way;
• Download saves a version as Turtle or TriG.

Deleted ontologies. The archive button at the top of the catalog lists deleted ontologies with their names. Restore brings one back with the same id, so IRIs made in it stay valid. A deleted ontology stays restorable for 30 days by default.

How much history is kept. After each save the backups of that ontology are trimmed: the newest 20 are kept, plus one per day for the last 30 days, up to 200 MiB per ontology; the newest is never removed. Change this under App Settings > Ontology (ontology_history_keep_recent, ontology_history_keep_days, ontology_history_max_mb). Backups made before v0.179.0 are listed as "Earlier version" and are never removed automatically.

For scripts: GET /api/ontology/{id}/history, GET .../history/{version}/diff, GET .../history/{version}/file, POST .../history/{version}/restore with the current revision, GET /api/ontology/trash and POST /api/ontology/trash/{id}/restore. The restores are refused under DEMO_MODE.

RDFS schemas and class hierarchies (v0.180.0)

The canvas draws ontologies written in RDFS as well as OWL:

• rdfs:Class is an entity. rdf:Property is an attribute when every range is a datatype (xsd:*, rdfs:Literal, rdf:langString, rdf:JSON, a type declared rdfs:Datatype, ...) and a relationship otherwise; one without a range stays in the Resources tab.
• "is a" edges. rdfs:subClassOf between two entities draws a dashed edge with an open arrow pointing at the superclass, in every ontology. Uncheck Show "is a" in the canvas toolbar to hide them (remembered in this browser).
• Draw a hierarchy. Set the toolbar switch to Link: Is a and drag from the subclass to the superclass: one rdfs:subClassOf statement is added. Select an "is a" edge to remove it. An entity's Detail lists its superclasses and subclasses; a relationship shows its super-properties.
• New terms match the ontology. The badge next to the switch shows OWL or RDFS. In an ontology written in RDFS only, new entities, relationships and attributes are rdfs:Class / rdf:Property; otherwise -- and in a new, empty ontology -- they are OWL. In the RDFS style a property's kind follows its range.
• Undeclared classes. A class that is used (in rdfs:subClassOf, rdfs:domain or rdfs:range) but not declared in the ontology is not drawn; its statements are marked not declared and the Resources tab shows how many there are.
• Natural-language search knows RDFS classes, properties and the class hierarchy, and asks for subclass instances with rdfs:subClassOf* -- the search itself has no inference, it reads the statements as written.

These roles are only how the editor shows the statements: nothing is added to the file.

OWL 2 and property characteristics (v0.181.0)

Everything an OWL 2 ontology says is kept: restrictions, cardinalities (also qualified), property chains, keys, punning (an IRI that is both a class and an individual), axiom annotations, disjointness and AllDifferent axioms, negative property assertions and data ranges. These are part of the automated tests on every path -- import, saving, search, the six export formats and the history.

Property characteristics. Select a relationship: the Characteristics block shows Functional, Inverse functional, Transitive, Symmetric, Asymmetric, Reflexive and Irreflexive. Click one to turn it on or off -- it adds or removes the matching rdf:type owl:...Property statement and nothing else. Combinations that contradict each other (Symmetric and Asymmetric, Reflexive and Irreflexive) or that OWL 2 DL does not allow (a Transitive property that is also Functional, Inverse functional, Asymmetric or Irreflexive) show a notice; saving still works. In an ontology written in RDFS only, the first characteristic asks before adding OWL vocabulary, because new terms are then created as OWL.

Individuals in the Data view (v0.182.0)

The canvas shows the schema -- classes, properties and "is a". The individuals (the data typed by those classes, such as :rex a :Dog) have a view of their own:

• Schema | Data. The switch at the left of the toolbar changes the view; your choice is remembered in this browser. On the canvas, a class with individuals shows a small badge (x12); click it to open the Data view on that class.
• Class tree. The left side lists the classes as a tree (from rdfs:subClassOf) with the number of individuals of each. Types used by individuals but not declared as classes are under Not declared; individuals typed only owl:NamedIndividual are under No class. Include subclasses also lists the individuals of the subclasses (off by default; it only changes what is listed -- nothing is inferred or saved).
• Table. One row per individual. The columns are the properties the schema gives the class (their rdfs:domain is the class or one of its superclasses), then any other property the individuals use, marked *. Columns hides the ones you do not need.
• Values are statements. A cell shows every value of the property -- an individual can have several names in different languages, or several owners. Click a cell to change, remove or add values: each change touches exactly one statement and keeps its graph, datatype and language. A value that does not fit its datatype, or a second value of a Functional property, shows a notice; saving still works.
• Detail. Selecting an individual shows its types, label, one field per property and All statements.
• + Individual adds one statement -- rdf:type of the class -- in the graph you are editing, plus a label when you enter one. Delete individual shows how many statements of other resources refer to it and removes those too (annotations on them are kept). Both are undone from History like any other change.

The Resources tab now lists only what is neither drawn nor an individual (untyped resources, other vocabularies, reifiers); its filter can still show the individuals.

Checks (v0.183.0)

The Checks tab lists what is worth a look in the ontology. The badge counts the warnings. Nothing here blocks saving, and most findings describe legal RDFS / OWL -- they are hints, not errors.

Warnings	Information (collapsed)
Undeclared classes (used as a superclass, domain, range or type, but not declared -- so not drawn)	Self "is a" links (A is a A)
Subclass / subproperty cycles (the classes in a cycle are equivalent)	Properties without a domain or a range (marked when this keeps them off the canvas)
Kind conflicts (one IRI as two kinds of property, or as a class and a datatype)	Orphan declarations (declared, but nothing uses or refers to them)
Values that do not fit their datatype	Duplicate labels
Property characteristic notices, Functional properties with several values

Fixes. Declare as class adds one owl:Class statement (rdfs:Class in an RDFS ontology). Classes of your own namespace can be declared together with Declare all; a class from another vocabulary (for example schema:Person) asks first, because reusing it from its own vocabulary is usually better. In a cycle, Remove deletes one "is a" link. Every fix is one statement and can be undone from History. Other findings select the term so you can fix it in its Detail.

Ignore hides a finding in this browser only; Show ignored lists them again.

Imports (v0.184.0)

An ontology can build on other ontologies with owl:imports. ChatWalaʻau follows these imports only to ontologies in your catalog -- nothing is ever downloaded.

How an import is found. In this order: your mapping table (below); the W3C vocabularies rdf, rdfs, owl and xsd (always known); the catalog IRI https://chatwalaau.com/ontology/<id>, which every catalog ontology has; then the one catalog ontology that declares the IRI as its ontology IRI (<iri> a owl:Ontology) or its version IRI (owl:versionIRI). IRIs must match exactly. If two catalog ontologies match, the import is ambiguous and nothing is used until you map it. Imports of imports are followed; a cycle is cut; at most 20 ontologies and 50 MB in total are followed (App Settings > Ontology).

What it changes.

• Search and the assistant answer from the ontology and its imports. Untick Include imports in the Search pane (or turn the default off in App Settings) for the ontology alone.
• The canvas shows the imported classes your ontology refers to -- a superclass, the domain or range of your property, the type of your individual -- as faded nodes with the name of the ontology they come from. They are read-only: they are placed automatically, cannot be dragged and are never written into your file. Select one to see its statements and Open in its ontology. The Imported switch in the toolbar hides them.
• Checks treat classes declared in an import as declared, and point out imports that are not in the catalog, ambiguous or over the limit.
• Editing suggests imported classes and properties in the statement editor and in "Add a type"; choosing one writes the same single statement as typing it. The Data view lists your individuals under imported classes and offers imported properties as columns.

The Imports dialog (the Imports button above the canvas; its badge counts the imports that need attention):

• Add from the catalog or Add by IRI adds one owl:imports statement -- and the ontology header (<this ontology> a owl:Ontology) when there is none. Remove deletes that one statement. Click Save to apply; History can undo it.
• The Mapping tab is one table for the whole catalog: "this import IRI means that ontology". Use it when a file imports an IRI your copy does not declare (for example another version), or to settle an ambiguous import. Map... on an import fills the IRI in.

Deleting an ontology warns you when other ontologies import it.

Search with RDFS entailment (v0.186.0)

A search normally returns only what your files state. Choose Entailment: RDFS in the Search pane (next to Include imports) to also see what RDFS entails from it:

• Class membership through the hierarchy -- ex:rex a ex:Dog and ex:Dog rdfs:subClassOf ex:Animal give ex:rex a ex:Animal (sub-classes and sub-properties chain transitively).
• Values through sub-properties -- ex:alice ex:walks ex:rex with ex:walks rdfs:subPropertyOf ex:caresFor gives ex:alice ex:caresFor ex:rex.
• Types from domains and ranges -- the subject of a property gets its rdfs:domain as a type, an IRI or blank-node value gets its rdfs:range.

With Include imports, the hierarchy of the imported ontologies is used too (a superclass in a core ontology is the common case). The natural-language search follows the same choice.

What you see. Inferred rows get an Inferred badge and the summary counts them ("3 rows, 2 inferred"); a CONSTRUCT is shown as a table of triples (with a graph column for named graphs) whose inferred rows carry the same badge, the Turtle / TriG text folded below it; an ASK says when only the inference answers. Statements that hold for every graph and tell you nothing (?x a rdfs:Resource, a class being its own sub-class, ?p a rdf:Property, statements about the rdf / rdfs / owl / xsd vocabulary) are left out. A statement about a built-in term that your ontology itself describes is kept when the RDF / RDFS axioms alone do not give it: with rdf:langString a rdfs:Datatype and rdfs:Datatype rdfs:subClassOf rdfs:Class stated, a search finds rdf:langString a rdfs:Class (v0.187.0).

What it never does. Inferred statements are computed when a search asks for them and kept in memory with the search cache; they are never written to your file, its history or an export. The selection starts at None each time the workspace opens.

Named graphs. In an ontology with named graphs, each graph also holds what follows from its statements together with the schema of the whole ontology. With the class hierarchy in g:schema and the books in g:catalog, GRAPH g:catalog { ?item a ex:Publication } finds a book typed ex:Book -- marked Inferred. Statements that follow from the schema alone stay out of the other graphs. FROM and FROM NAMED see the same, and a CONSTRUCT lists inferred triples with their graph.

Limits. The reasoner is owlrl, checked against the W3C RDF semantics tests. It works in Python and needs about 10 seconds for 3,000 statements, so larger inputs (imports included) are refused with a message; the limit is App Settings > Ontology > Ontology RDFS entailment: largest input. Datatype entailment (comparing values of different datatypes, detecting ill-typed values as contradictions) is not done. owl:inverseOf, owl:TransitiveProperty, owl:SymmetricProperty, owl:equivalentClass and owl:sameAs are OWL rules -- choose OWL 2 RL for them (below).

For scripts. POST /api/ontology/{id}/query (and /nl-query) take "entailment": "simple" (the default) or "rdfs". Answers carry entailment; with rdfs, SELECT adds row_inferred (one flag per row) and inferred_count, CONSTRUCT returns the stated part in turtle and the inferred part in inferred_turtle, and ASK adds inferred. CONSTRUCT and DESCRIBE answers (every mode) also carry triples: rows of {s, p, o, graph, inferred}. "owl-rl": see below.

Search with OWL 2 RL entailment (v0.187.0)

Choose Entailment: OWL 2 RL to add the OWL 2 RL rules on top of RDFS. Everything RDFS gives is still there; in addition the OWL items you edit in the workspace take effect:

• Property characteristics -- a transitive ex:partOf gives ex:bolt ex:partOf ex:car from ex:bolt ex:partOf ex:engine and ex:engine ex:partOf ex:car; symmetric properties work both ways; ex:hasChild owl:inverseOf ex:hasParent answers ex:hasParent questions; functional and inverse-functional properties and keys (owl:hasKey) identify individuals.
• Equivalences and identity -- equivalent classes and properties share members and values; with ex:annie owl:sameAs ex:ann, every statement about one name also holds for the other.
• Class expressions -- someValuesFrom, allValuesFrom and hasValue restrictions, intersections, unions and property chains, and max cardinality 0 or 1.

Results are marked Inferred exactly as with RDFS and are never written. Declarations the rules add (?c a owl:Class), owl:Thing typing and a name being owl:sameAs itself are left out of the answers. In an ontology with named graphs, each graph also holds what follows from it with the OWL schema of the whole ontology.

Inconsistencies. When the rules find a contradiction -- two disjoint classes sharing a member, an irreflexive or asymmetric property used against itself, owl:sameAs together with owl:differentFrom, a member of owl:Nothing, max cardinality 0 with a value, two different values of a functional data property -- a red Inconsistent ontology (OWL 2 RL) box lists up to 20 findings (with their graph) above the answer. The answer is still shown: an inconsistent ontology entails everything, and the answer holds what the rules derived.

Limits. OWL 2 RL is about 7 times slower than RDFS: about 4 seconds for 1,000 statements. Two App Settings in Ontology bound it: Ontology OWL 2 RL entailment: largest input (1,000 statements, imports included) and largest output (50 inferred statements per stated statement -- many owl:sameAs pairs are the usual cause; the refusal is remembered until a file changes). Datatype reasoning is not done. The reasoner is checked against the W3C OWL 2 RL test cases.

For scripts. Send "entailment": "owl-rl". Answers may carry the notices entailment_inconsistent (count, truncated, items of {kind, graph, message, terms}) and entailment_same_as (count). A size refusal (422 entailment_too_large) names its reason (input or inferred_ratio) and the setting to raise; a reasoner failure is 422 entailment_failed.

Time limits, entailment after saves, Explain and inferred views (v0.188.0)

Import progress. Importing a file shows "Importing file name..." until the new ontology is laid out and drawn (screen readers announce it).

Time limits and Stop. Searches run in background search processes. A search on the Ontology screen is stopped after 30 seconds, one by the assistant after 20 seconds (waiting included; the model's SPARQL generation is not counted). The message names the App Settings key to raise. Stop in the Search pane ends a running search at once, and closing the dialog stops it too.

Entailment computed after every save. After each save, version restore, trash restore or file import -- and for every ontology that imports the saved one -- RDFS and OWL 2 RL are computed in the background as a Pipeline Job (ontology-entailment, visible in the Pipelines portal) and stored beside the ontology (never in its file, history or exports). Searches with entailment then answer from the stored result, without waiting for the reasoner. Next to the Entailment choice the Search pane shows its state: "Computing...", "Ready", or why it was not computed. A search that comes before the result waits within its time limit; otherwise it answers "still being computed, try again shortly". RDFS now uses a direct engine that gives exactly the reasoner's result about ten times faster, so the limits are 100,000 statements for RDFS and 10,000 for OWL 2 RL.

Consistency in Checks. The Checks tab lists the OWL 2 RL inconsistencies of the saved version under Inconsistent (OWL 2 RL), with their subjects to select; while the result is being computed, or when the ontology is too large, an info line says so. With unsaved edits the group says it is based on the last saved version.

Explain. The Explain tab shows why an inferred statement or an inconsistency holds: the rules applied (for example prp-trp: a transitive property chains) down to the stated statements, which you can click to select. Open it with Explain on an inconsistency in Checks, Why? on an inferred row of a CONSTRUCT answer, or by clicking an inferred item on the canvas or in the Data view. Statements that hold for every graph (axioms) are shown as such.

Inferred relationships. The Inferred: Off | RDFS | OWL 2 RL switch (canvas and Data view, remembered per browser, off by default) shows what follows from the saved ontology, faintly:

• on the canvas, dotted "is a" and "same as" edges and relationships a property inherits through sub-properties or class hierarchies -- only those that add information (transitive "is a" edges and the super-classes of a stated domain are not drawn) -- and the edges of inverse properties, marked derived from owl:inverseOf (OWL 2 RL itself gives an inverse property no domain or range); at most 500, with a legend;
• in the Data view, inferred class members ("+N inferred" in the class tree, marked rows and chips) and, in an individual's Detail, its inferred values with Why?.

Inferred items are never edited or saved. With unsaved edits they are labelled "from the last saved version".

For scripts. GET /api/ontology/{id}/entailment (state per mode), GET /api/ontology/{id}/entailment/findings (stored OWL 2 RL findings with stable keys), GET /api/ontology/{id}/entailment/statements?mode= (inferred statements for the views) and POST /api/ontology/{id}/explain ({mode, statement | finding}). New errors: 422 query_timeout (limit_seconds, phase, setting), query_stopped, entailment_pending, explain_not_inferred, and 503 query_worker_failed.

SHACL validation (v0.189.0)

RDFS and OWL 2 RL add facts; they never tell you that a value is missing or has the wrong type. SHACL does: a shape says what the data of a class must look like ("a book has exactly one ISBN", "a price is a non-negative decimal"), and validation lists every place that does not fit.

Where shapes live. Open Validation (header) and choose:

• Shapes graphs -- named graphs of the same ontology that hold shapes (add a new graph IRI in the dialog), and/or
• Shapes ontologies -- other ontologies in the catalog whose whole file is shapes, so one set of shapes can serve several ontologies.

Shapes are never part of the data: the declared shapes graphs are left out of validation, of the Schema canvas and of the Data view (pick the graph in the graph selector to see it). They stay ordinary named graphs of the file -- searchable, in History and in exports.

When it runs. After every save, version restore, trash restore or file import -- and when a shapes ontology or an imported ontology changes -- the data is validated in the background with pyshacl (Pipeline Job ontology-shacl) and the result is stored per version beside the stored entailment. Inference before validation is None by default (SHACL already follows rdfs:subClassOf for its targets, so members of sub-classes are checked); choose RDFS or OWL 2 RL when types follow from domains, ranges, equivalences or owl:sameAs.

SHACL Core only. SHACL-SPARQL, SHACL-AF and SHACL-JS constructs are ignored and listed in Checks; nothing is fetched from the network. The shapes are checked against SHACL-for-SHACL first; shapes that are not valid SHACL are reported instead of validated.

Results in Checks. SHACL violations (warnings), SHACL warnings and SHACL notes (information) list one finding per shape, path and constraint -- for example ex:BookShape -- ex:isbn -- sh:minCount 1 -- with the nodes that fail as chips (click to select), Show shape, and "and N more" for the full list. Individuals with results show a chip in the Data view; classes a shape targets show a shield badge on the canvas.

The Shapes view. The view switch gains Shapes when an ontology has shapes. Each node shape is a table: targets, severity, message, closed and deactivated at the top; one row per property shape with the path (ex:p or ^ex:p), value type (datatype, class or node kind), min and max count and message; the arrow in "other" opens in, has value, pattern, lengths, range bounds, languages, unique language, node shape and severity. Constructs the table does not cover (sh:or, qualified shapes, sequence paths, ...) are shown read-only and kept as written. Edits are saved with Save, like every other edit.

Strict mode (per ontology, off by default): a save whose new version has SHACL violations is refused with a dialog listing them -- Fix keeps editing, Save anyway saves and History records "despite SHACL violations". Warnings and notes never refuse a save; a check that does not finish within its time limit lets the save through with a notice; file imports and restores are never refused.

For scripts. PATCH /api/ontology/catalog/{id} with {"shacl": {"shapes_graphs": [...], "shapes_ontologies": [...], "inference": "none" | "rdfs" | "owl-rl", "strict": false}} (null turns it off); GET /api/ontology/{id}/shacl (state, counts, groups) and GET /api/ontology/{id}/shacl/results?severity=&shape=&path=&focus=&limit=. Strict mode answers 422 shacl_violations; send shacl_override: true to save anyway.

Merge, list order and panel tabs (v0.190.0)

Merge into an ontology. Uploading a file always creates a new ontology. To add a file's content to the ontology you have open, use Merge (header). Choose a file (any of the six formats) or another ontology of the catalog -- its content is copied, unlike Imports (owl:imports), which only refers to it. Before anything changes, a preview shows:

• how many statements are new and how many are already there (they change nothing);
• for a file with named graphs, one checkbox per graph -- leave graphs out to merge only part of the file; a Turtle file goes into the graph you pick (by default the editor's current graph);
• the prefixes added (only those the merged statements use) and those kept as they are because the name already means another namespace here;
• a change to VERSION 1.2 when the merged content uses RDF 1.2;
• the source's ontology header (owl:Ontology, its imports and annotations) -- left out unless you tick "Include the source's ontology header";
• graphs that are your SHACL shapes graphs.

Merge adds the statements as unsaved changes: check them on the canvas, then Save (or Undo merge, available until you save). Blank nodes of the source never join yours. The save is an ordinary one: History records it, strict SHACL mode applies, and entailment and validation run afterwards.

Reorder the list. Drag an ontology by its handle (shown when you point at the row), or focus the handle and press Space, the arrow keys and Space. The order is kept on the server, so every browser and the assistant see it. New ontologies -- created, uploaded or restored from the trash -- appear at the top.

Panel tabs. When the right pane is narrow, its tabs shrink: first only the open tab keeps its label, then all tabs show icons only. Point at a tab to see its name.

For scripts. POST /api/ontology/{id}/parse (multipart file) returns a file's projection -- relative IRIs resolved against this ontology's base -- and writes nothing. PUT /api/ontology/catalog/order with {"ids": [...]} sets the order (unknown ids are ignored; missing ones keep their order after the listed ones).

Import a table (v0.193.0)

Most instance data arrives as tables. Import table in the Data view turns a CSV or TSV file into individuals of one class, and checks them with the ontology's SHACL shapes before anything changes. Save or discard your edits first: the preview checks exactly what will be saved.

1. File. UTF-8 (with or without a BOM) and Excel's Shift_JIS are recognized, also EUC-JP, UTF-16 and Latin-1 when chosen; comma, tab, semicolon or bar; pick the header row if the file has a title above it.
2. Mapping. Choose the class of the rows (the class selected in the Data view is the default) and a subject IRI template built from key columns, for example http://example.org/library#book-{ISBN} -- the same row always gives the same individual, so importing a file twice adds nothing. For each column pick value (a datatype or "text with a language"), reference (an IRI from a template, or an existing individual found by a value, such as its label) or ignore; a separator splits cells with several values. The rules are suggested from the class's properties and SHACL shapes.
3. Preview. Every row is converted (1,234 -> 1234, 2024/4/1 -> 2024-04-01, yes / no -> true / false) and the ontology plus the rows is validated. Rows with violations are left out and listed with the line, key and reason; rows with only warnings are imported with the warning shown; violations that were already in the ontology are not blamed on the table. Download excluded rows saves them as a CSV with a _reason column, to correct and import again.
4. Add. The accepted rows arrive as unsaved changes (Undo import until you save) and are saved like any edit.

For individuals that already exist you choose to add the values (default), replace the values a row gives (an empty cell keeps the old value) or skip the row. Mappings can be saved under a name for the ontology, or downloaded and loaded as .json files. One import reads at most ontology_table_max_rows rows (10,000). A row becomes an individual of one class; a table cannot create nested values (blank nodes) -- give them their own table and refer to them. .xlsx files are not read: save them as CSV.

The knowledge-graph guide in the repository walks through it with sample files (STEP 17 / 18).

For scripts. POST /api/ontology/{id}/table/inspect (multipart file, optional class) reads a file and suggests a mapping; POST /api/ontology/{id}/table/preview (multipart file, mapping, revision) returns the statements to add and the row report. Both write nothing. GET /api/ontology/{id}/table/mappings, PUT / DELETE /api/ontology/{id}/table/mappings/{name} manage the saved mappings.

Your own IRIs (v0.194.0)

Every term needs an IRI. Until now new terms were named under ChatWalaʻau's domain (https://chatwalaau.com/ontology/ont_3f2a9c1b7d4e#Pump). Now an administrator can name new ontologies under a domain your organization controls, so the IRIs can be used as your identifiers in other systems (maintenance systems, Excel registers, P&ID conversions).

1. Set the IRI base once. App Settings > Ontology > IRI base, for example https://kg.acme.co.jp/ (an absolute http(s) IRI ending with /).

2. Give a new ontology a short name. The New ontology dialog shows an IRI section with Short name (lower-case letters, digits and -, 2 to 40 characters) and a preview:

   Kind	IRI
   ontology	https://kg.acme.co.jp/plant
   terms (classes, properties)	https://kg.acme.co.jp/plant#Pump
   individuals	https://kg.acme.co.jp/plant/id/P-101

   Without a short name the ontology's id is used under your base. Use a custom ontology IRI takes one full IRI instead (also possible without an IRI base of your own).

3. The new file starts with <https://kg.acme.co.jp/plant> a owl:Ontology and the prefixes : (terms) and id: (individuals). New individuals in the Data view and the Import table suggestions use .../plant/id/.

Rules that keep IRIs stable:

• The IRI is decided once and kept with the ontology. Changing the IRI base later only affects ontologies created afterwards; a short name cannot be changed.
• Short names are unique, including ontologies in the trash (they keep theirs until the trash expires). api, id, sparql and a few other words are reserved for later features.
• Another ontology can write owl:imports <https://kg.acme.co.jp/plant> (or <...plant#>) and it is found in the catalog. The old form https://chatwalaau.com/ontology/{id} keeps working.
• Rename ontology shows the IRIs with a copy button. An ontology created before has a one-time Set IRI...: its existing IRIs stay as they are, and only new terms use the new namespace.

Opening one of these IRIs in a browser does not return anything yet; serving them is planned for a later release. Downgrading to an older version drops the stored IRI settings from the catalog when it is next written (the ontology files keep their IRIs).

For scripts. POST /api/ontology/catalog accepts short_name or ontology_iri (POST /api/ontology/import the same as form fields); PATCH /api/ontology/catalog/{id} accepts namespace: {short_name} or {ontology_iri} once. Answers carry iri: {ontology, vocabulary, individuals, short_name, custom, fixed} beside base_iri, and GET /api/ontology/catalog reports iri_base.

Ask the assistant

In any chat, the assistant can use the ontology_query tool (named query_ontology before v0.186.0): it lists your catalog, picks the right ontology from your descriptions, converts your question into a read-only SPARQL query, and answers with the matching RDF in a fenced Turtle block -- capped in size so a large ontology never floods the conversation. The answer uses your ontology's own prefixes and spellings, and the model sees the same notes as the search view, so it does not report a count the file contradicts. For an ontology with named graphs the answer is TriG, so the assistant can tell you which graph a fact comes from, and it can ask about one graph only. Answers include the ontologies an ontology imports (v0.184.0) unless the default is turned off, and the catalog tells the assistant which ontologies import which. For questions about class membership or hierarchies the assistant can ask with RDFS entailment (v0.186.0): the inferred triples then come in a separate block, and the assistant is told to say they are inferred. For questions that depend on OWL (transitive or inverse properties, equivalences, owl:sameAs) it can ask with OWL 2 RL entailment (v0.187.0); an answer from an inconsistent ontology starts with the findings, and the assistant is told to pass that warning on. Since v0.188.0 the assistant's searches stop after 20 seconds (it is then told to ask a narrower question), and it can explain why a statement holds -- the rules and the stated statements behind it. Since v0.189.0 it can answer "does the data satisfy its shapes?" from the stored SHACL validation (counts, the failing shapes and examples, or the results about one node).

Everything on the query side is read-only by construction: searches and assistant queries can never modify your ontologies.

Settings

Setting	Default	Meaning
ONTOLOGY_ENABLED	true	Master gate for the whole feature (default was false before v0.130.2)
ONTOLOGY_DIR	.ontologies	Folder holding the catalog + Turtle / TriG files
ONTOLOGY_RESULTS_DIR	.entailment	Folder of computed results (stored entailment and SHACL validation); relative = under ONTOLOGY_DIR, absolute as is; a cache, safe to delete (v0.189.0)
ONTOLOGY_MAX_FILE_BYTES	10485760	Import/save size cap (10 MiB)
ONTOLOGY_TOOL_MAX_TRIPLES	200	Cap on triples in an assistant answer
Ontology query cache (MiB) (ontology_query_cache_mb, App Settings > Ontology)	1024	Memory kept for loaded ontologies between searches, shared by the search processes; 0 turns it off (v0.178.0; 512 before v0.188.0)
Ontology history: recent versions kept (ontology_history_keep_recent, App Settings > Ontology)	20	Newest backups always kept per ontology (v0.179.0)
Ontology history: days kept (ontology_history_keep_days)	30	One version per day kept this long; also how long a deleted ontology stays restorable (v0.179.0)
Ontology history: size limit per ontology (ontology_history_max_mb)	200	Oldest backups removed above this size; 0 = no limit (v0.179.0)
Ontology search includes imports (ontology_query_include_imports, App Settings > Ontology)	on	Searches, natural-language questions and the assistant also answer from imported ontologies; the Search pane's switch starts with this value (v0.184.0)
Ontology imports: ontologies loaded (ontology_imports_max_ontologies)	20	Most imported ontologies followed for one ontology (v0.184.0)
Ontology imports: total size (MiB) (ontology_imports_max_mb)	50	Largest total size of the imported files followed (v0.184.0)
Ontology RDFS entailment: largest input (statements) (ontology_entailment_max_triples, App Settings > Ontology)	100000	Largest number of stated statements (imports included) RDFS entailment accepts; computed in the background after each save, about 13 seconds at 100,000 (v0.186.0; 3000 before v0.188.0)
Ontology OWL 2 RL entailment: largest input (statements) (ontology_owl_rl_max_triples, App Settings > Ontology)	10000	Largest number of stated statements (imports included) OWL 2 RL entailment accepts; computed in the background, about 20-50 seconds at 10,000 (v0.187.0; 1000 before v0.188.0)
Ontology OWL 2 RL entailment: largest output (inferred per stated statement) (ontology_owl_rl_max_inferred_ratio, App Settings > Ontology)	50	More inferred statements per stated one are refused (usually many owl:sameAs pairs); remembered until a file changes or the limit is raised (v0.187.0)
Ontology search worker processes (ontology_query_workers, App Settings > Ontology)	2	Background processes searches run in; 0 runs them in the server process without time limits (v0.188.0)
Ontology screen: search time limit (seconds) (ontology_query_timeout_seconds)	30	A search from the Ontology screen is stopped after this long; 0 = no limit (v0.188.0)
Agent ontology_query tool: time limit (seconds) (ontology_tool_timeout_seconds)	20	An assistant search is stopped after this long; 0 = no limit (v0.188.0)
Ontology screen: largest search result (rows) (ontology_query_max_rows)	1000	SELECT rows and CONSTRUCT triples shown by a search (v0.188.0)
Ontology: compute entailment after each save (ontology_entailment_precompute)	on	Off: entailment is computed when a search first asks for it (v0.188.0)
Ontology: entailment computation time limit (seconds) (ontology_entailment_build_timeout_seconds)	600	A background entailment computation running longer is stopped and reported (v0.188.0)
Ontology SHACL validation: largest data (statements) (ontology_shacl_max_triples)	100000	Data statements (stated and inferred, imports included) validated at most; about 10 seconds at 100,000 with simple shapes (v0.189.0)
Ontology SHACL validation: results kept per version (ontology_shacl_max_results)	10000	Results stored for each version; the counts stay exact (v0.189.0)
Ontology SHACL validation: time limit (seconds) (ontology_shacl_build_timeout_seconds)	300	A background validation running longer is stopped and reported (v0.189.0)
Ontology SHACL strict mode: check time limit (seconds) (ontology_shacl_strict_timeout_seconds)	30	In strict mode a check that does not finish this fast lets the save through with a notice (v0.189.0)
Ontology table import: data rows (max) (ontology_table_max_rows)	10000	A CSV / TSV file imported from the Data view may hold at most this many data rows; a larger file is refused with its row count (v0.193.0)
Ontology IRI base (ontology_iri_base)	https://chatwalaau.com/ontology/	The namespace NEW ontologies are named under, for example https://kg.example.com/; with your own base, ontologies get short names. Existing ontologies keep their IRIs (v0.194.0)

The ontology keys live in App Settings > Ontology since v0.184.0 (they were under Limits; keys and values did not change). With imports, a search keeps the ontology and its imports in the query cache; a closure larger than about 36 MB does not fit the default 1,024 MiB budget and is rebuilt on each search -- raise the cache budget if you search such ontologies often.

Under DEMO_MODE

On a demo host the ontology workspace is read-only. Creating, importing, renaming, saving and deleting refuse with 409; browsing, the graph canvas, export and both SPARQL lanes still work -- a SPARQL query cannot modify the store, so it is a read.

The store is shared by everyone using the demo: the catalog lists every ontology by name and export returns the whole Turtle, so a writable demo would make one visitor's model readable, editable and deletable by the next.

Two limitations to expect on a demo host: the catalog starts empty (no demo ontology ships with the app), and the natural-language question box returns an error, because the demo runs a stub model whose output is not SPARQL.

The natural-language-to-SPARQL model is assigned in the Model Offering Catalog under App Settings -> Model Offering Catalog -> Task model assignments (roles.ontology_nl, or chatwalaau models role set ontology_nl <offering-id>); leave it unset to use the default model. The dedicated ONTOLOGY_NL_MODEL variable was removed in v0.109.0.