# Where to store type metadata?

**URL:** <https://forum.typedb.com/t/where-to-store-type-metadata/195>\
**Category:** TypeDB\
**Tags:** schema-design\
**Created:** [6 September 2022 18:48 UTC](https://forum.typedb.com/t/where-to-store-type-metadata/195 "2022-09-06T18:48:02Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![mike](https://avatars.discourse-cdn.com/v4/letter/m/58f4c7/32.png) [@mike](https://forum.typedb.com/u/mike)\
**Post date:** [6 September 2022 18:48 UTC](https://forum.typedb.com/t/where-to-store-type-metadata/195/1 "2022-09-06T18:48:02Z")

</div>

Is there an elegant way to store type metadata?

Examples:

- We want entities of type T1 to be displayed at the diagram as a circle, and type T2 – as a square
- We have to attach to the string attribute a list of allowed values (not as a db constraint but for use in the UI)
- We want to mark an attribute as read-only for the UI

We can store it outside of TypeDb of course, but it would be more consistent to use some internal mechanics to do this.

---

<div class="post-metadata">

**Author:** ![alex](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.typedb.com/alex/32/148_2.png) [@alex](https://forum.typedb.com/u/alex)\
**Post date:** [7 September 2022 14:48 UTC](https://forum.typedb.com/t/where-to-store-type-metadata/195/2 "2022-09-07T14:48:57Z")

</div>

I can think of two possible approaches, each with their pros and cons:

### 1. Metadata as schema

```typeql
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:

```typeql
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 🙂