TypeDB 3.0: Remove 'thing' and 'type' from the public interface

[flyingsilverfin]

Problem to Solve

The terms 'thing' and 'type' can be removed from the public interface of TypeDB and TypeQL.

Proposed Solution

The public APIs of TypeQL and TypeDB currently include the idea of thing (eg match $x sub/isa thing;, or that the supertype of Entity is a Thing), as well as the idea of type (eg. the superty of EntityType is a Type).

However, we can simplify the model to ensure there is a minimal set of ideas to learn. Now, we will have a flat hierarchy:

Concept

is the supertype of:

EntityType RelationType RoleType AttributeType Entity Relation Attribute

To query for all instances, users will have to query disjunctions match $x isa/sub $t; { $t type entity; } or { $t type relation; } or { $t type attribute; };

Internal decisions

We still must decide whether or not to continue having the abstractions of thing and type in the internal server code. They could be removed or introduced as interfaces/traits parallel to Concept.

[lveillard]

I love how this opens a lot of possibilities!

1. would match $x isa concept; also work?
2. is there some disadvantages on keeping "thing" as a sugarcoat of

{ $t type entity; } or { $t type relation; } or { $t type attribute; };

A random idea: To have SimplifiedTypeQL and ParsedTypeQL where SimplifiedTypeQL stays super intuitive (and maybe retrocompatible also with typeDB 2.0) and is translated into ParsedTypeQL which is typeQL without sugarcoats. Not sure about performance drop tho 🤔

[flyingsilverfin]

Probably if it is going to induce a chunk of new work we will keep it out of the roadmap for now