TypeDB 3.0: list attribute ownerships and ownership defaults

[flyingsilverfin]

Problem to Solve

Currently there is no way to operate over ordered collections in TypeDB. We address one aspect of this, which is ordering attribute ownerships.

Current Workaround

Currently, any ordering requires creating entities with an attribute representing the value, and one representing the index, and manipulating these manually.

Proposed Solution

We aim to consistently extend TypeQL to attribute list ownerships.

Modifications to existing set semantics

Current set-semantics syntax:

person sub entity, owns name;

As a simplification and setting of sensible defaults, we will make attribute set ownership default to @card(0,1).

Extension to list semantics

Defining ordered attribute ownership

We will allow extending ownership to be 'ordered':

person sub entity, owns name[];

We should consider this to be a modification of the extisting person-name ownerships, except that now these can be considered a list instead of a set: ordering is provided, duplicates are allowed, and there is no restriction on cardinality. In short, this switches from set semantics to proper list semantics.

If one requires ordered-set semantics, we can enforce this with an @distinct annotation:

person sub entity, owns name[] @distinct;

Inserting ordered attributes

List-semantic attributes must be inserted using lists:

insert $x isa person, has name[] ["John", "Doe"];

An entire list must always be provided. To avoid unnecessary delete clause, we provide an @replace annotation. For example, to prepend a new element to a list, we may write

match $x isa person, has name[] $names;
insert $x has name[] ["Johnson"] + $names @replace; 

Similarly to replace the $i$ th element, we may write:

match $x isa person, has name[] $names;
insert $x has $names[:i] + ["Johnson"] + $names[i+1:] @replace; 

Remark on type checking. Note that the expression ["Johnson"] + $names (similarly to the expression "Johnson" by itself) will have inferred type list(string). Therefore, we cannot write
insert $x has ["Johnson"] + $names (just has we cannot write $x has "Johnson"), since this would yield an attribute insert statement without an inferable attribute type.

Deleting ordered attributes

Similarly to insert, entire lists must be provided in delete statements. To only delete parts of a lists, we can use update queries, or (for short) insert statements with @replace annotation.

Reading ordered attributes

Set-semantically defined attribute data can be read as before:

match $x isa person, has name $name;

However, lists can be read as either individual elements of a collection or as an entire ordered list:

match $x isa person, has name $name; // one name at a time
match $x isa person, has name[] $names; // an ordered collection of names

Note that we are now introducing variables that contain an ordered collection of concepts! Eg. the type of $names is List<Name> or OrderedSet<Name> depending on the annotations provided in the schema.

We should be able to index into the ordered collection as one would expect:

match 
$x isa person, has name[] $names;
$names[0] == "John";

Reading ordering attribute types (schema read)

This works analogous to #7029.