⚡️ Ideas
Tony Huang Tony Huang Jul 21, 2023

Ability to define a given supertag as a subclass of another supertages in Schema - then exploit the class structure to make inheritance and queries better

Explain the problem as you see it

Note that this idea is built on the endorsement of a previous idea from Chen.

Problem:

Users do not have a simple and intuitive interface to visually define general properties for a high-level concept once and then inherit them in more specific concepts subsumed by the general. (A concept is the same as supertag.) They also don't have a way to exploit the concept subsumption relation (or subclass / concept subsumption relation) when building queries.

This is holding users back from 1) a visual and more logical structure to organize their information, 2) maintainability of their information, in virtue of the previous point, and 3) having simpler expressions of more powerful queries.

Why is this a problem for you?

It is cumbersome to rely on "extend" option in the supertag definition window for inheritance. If there are many inheritances, it is also difficult for users to gain an overview. Furthermore, without an explicit class-subclass structure, a user cannot exploit the transitive "subclass" relations when writing a query.

image.png

Suggest a solution

Let's start with an example of how the super tags should be organized in the schema page.

  • #work_process {properties: participants, date & time}
    • #task {properties: participants(i), date & time(i)}
      • #work_order_execution {properties: participants(i), date & time(i), equipment}
    • #meeting {properties: participants(i), date & time(i), topic, project}
      • #project-X_daily_meeting {properties: participants(i), date & time(i), topic(i), project(i), today's task}
      • #one-on-one_meeting {properties: participants(i), date & time(i), topic(i), project(i), task to follow-up}

Representing classes in a hierarchal structure is much easier to read and understand.
If I want to write a query to list all meetings I was involved in, then by default I should see all my project meetings and one-on-one meetings. (The query should by default list the instances of the subclasses.) What is important for Tana Inc. is that by introducing a class structure in the Schema page, you make some advanced queries more intuitive without referencing recursion, which makes it easier for more users to adopt.