Skip to content

The ontology can only be read one class at a time #498

Description

@WaylandYang

The ontology page reads one class at a time. A rail of names, a diagram, and a panel showing whichever one you clicked. Every question that spans the ontology is unanswerable there:

  • which properties are functional, and which were never declared either way;
  • which classes have no instances after a pack import brought in nine hundred;
  • which relations have no domain, so the extractor gets no signature for them;
  • which of them are events rather than states, now that the difference drives the engine (0031);
  • what attributes this base has at all — attributes appear only inside a class's panel, one class at a time, so the base-wide list exists nowhere.

Every other page of this kind was rebuilt as a table this month: tokens, data sources, members, the deployment's users, and business rules (#482, which said in as many words that a column of cards did not look like anything else we had just rebuilt). The ontology is the last one standing, and it is the one with the most columns.

What to build

Three tables behind a segmented control.

columns
Classes name, with its colour dot and shape, indented by depth; key; parent; disjoint; instances; attributes; description
Properties name; key; the subject and object signature; temporal semantics; the six axioms as chips; inverse; super-property; facts
Attributes name; key; the class it hangs on; datatype; unit; single-valued; usage

Attributes get their own table because the base-wide list has no home today.

The axioms are chips, not six checkboxes: six boxes in a row cannot be read as "what does this property guarantee", and a few letters can be scanned down a column.

A row opens the edit dialog that already exists (#480). The instance and fact counts are links into the graph page, filtered. Each row carries a "see it in the diagram" action that deep-links to the graph page's schema level (#497).

The hierarchy in a table

subClassOf is the ontology's backbone and a flat list loses it. The rule: the default order is the hierarchy, with the name column indented, the way the rail's tree already indents. Sorting by any other column flattens the list, and the parent column is always present, so flattening loses nothing but the shape. That is what a file manager does, and it is honest about which of the two readings you are in.

Two consequences

The page loses its canvas. The diagram lives on the graph page's schema level after #497. The ontology page is tables and dialogs.

Usage counts come back. The rail's tree deliberately omits them, and its comment gives the reason: counting and rendering are a burden once the numbers grow. usage is already returned on both views; the burden was rendering hundreds of rows at once, which paging solves.

Needs one thing in ui/

ui/table.tsx has Table, Tr, Th, Td and no sorting. Sortable headers belong there, not in this page — members, tokens and the rules table all want them.

Not in this cut

A checkbox column with bulk delete and bulk retype. It is the thing tables unlock, and it is the right answer for cleaning up after a pack import, but land the tables first and see whether it is reached for.

The five workflows pinned to the rail — import, refine, uniqueness candidates, misses — are a separate move. Three of them are queues, and the code's own comments say so: they are both "the ontology and the data disagreeing" and "the data saying the ontology is missing something". That is the shape of the Review page. Import is not a queue and wants its own route. Rules already left in #482.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions