I can think of two possible approaches, each with their pros and cons:
1. Metadata as schema
define
diagram-shape-circle sub attribute, value long;
diagram-shape-square sub attribute, value long;
t1 sub entity, owns diagram-shape-circle;
t2 sub entity, owns diagram-shape-square;
readonly sub attribute, value boolean;
t3 sub attribute, value string;
t4 sub attribute, value string, owns readonly;
Easy to query using schema queries, not very extensible though and may require regular schema updates which can interrupt regular usage of the DB.
2. Metadata as data
There are a few options here - the solution proposed here may not be the most elegant model, but it is one option:
define
type-metadata sub entity, abstract, owns type-label;
type-metadata-diagram-shape sub type-metadata, owns diagram-shape;
type-metadata-is-readonly sub type-metadata, owns is-readonly;
type-label sub attribute, value string;
diagram-shape sub attribute, value string;
is-readonly sub attribute, value boolean;
t1 sub attribute, value long;
t2 sub attribute, value string;
...
insert
$t1 "t1" isa type-label;
$t2 "t2" isa type-label;
$diagram_shape_circle "circle" isa diagram-shape;
$diagram_shape_square "square" isa diagram-shape;
$readonly_true true isa is-readonly;
$tm1 isa type-metadata, owns $t1, owns $diagram_shape_circle, owns $readonly_true;
$tm2 isa type-metadata, owns $t2, owns $diagram_shape_square;
Queries are slightly longer, but can be significantly more expressive. We are able to define a type for every possible “metadata ownership”, and create these metadata ownerships (subtypes of type-metadata
) on the fly by inserting them as data.
It might even be more elegant to have the type-label
own the metadata
directly - however, be aware that attributes owning other attributes is a rarely-used feature of TypeDB and could be deprecated in future versions 