Role names of a relation cannot be reused in its sub-relations via override about typeql

[james-whiteside]

There's a big difference. If I say that I want something to play group-membership:member then I don't want it to be able to play membership:member or member in other subtypes of membership.

[flyingsilverfin]

The final behaviour here was discussed and implemented.

1. Role types are now concrete separately from their relations' abstractness, therefore inheritable and reusable (vaticle/typedb#6885)
2. Inherited role types are no longer allowed to be accessed via alias in the sub-relation type (vaticle/typedb#6916)
   Given

define
employment sub relation, relates employee;
part-time-employment sub employment;

We now disallow

define
person plays part-time-employment:employee;

Since part-time-employment:employee is an alias for employment:employee

Previously, allowing this plays would actually implicitly allow playing other types of relations that inherited emplyoment:employee as well, such as for example non-profit-employment sub employment, even though a person maybe only should be restricted to part-time-employments in a model.

3. We disallow creating a sub-role type with the same name to avoid confusion and ambiguity in the following use case (pre-existing behaviour)

define
  multi-employment sub employment,
    relates employee-1 as employee,
    relates employee-2 as employee,
    ...
    relates employee as employee;

Here, querying match (employee: $x) isa multi-employment is ambiguous we either want to query for specifically the new 'employee' in multi-employment or all employee-* in multi-employment (via subtyping).

Another way to see this from a set semantics is that we can see multi-employment as sharing (ie being a subset) of employment - therefore we can ignore the scoping of role types when considering role names. In this model, calling a subtype employee while the parent is employee is as confusing as naming an attribute supertype name and its subtype name as well. If they have the same name, they should occupy the same 'space'.

The solution to this is create a new role type when you want to carve out a subset specific to the relation subtype.

define
  multi-employment sub employment,
    relates employee-1 as employee,
    relates employee-2 as employee,
    ...
    relates multi-employee as employee;

[james-whiteside]

Related issue: #203

[james-whiteside]

This issue might also be related: vaticle/typedb#6534

[brettforbes]

i agree this is an important logic problem. Roles are not always a logical sub-set of a larger role, and in fact sometimes the roles are the same. This is really due to the construction of language, and TypeQL should allow this since the role is always fully qualified (ie. it is called with the relation name as well)

[flyingsilverfin]

define

# not abstract
membership sub relation,
    relates parent,
    relates member;

group-membership sub membership,
    relates group as parent,
    relates member as member;

This one - i agree it might be nice but how important is it to actually have group-membership:member and membership:member being different role types? This is much harder to implement than allowing abstract relations to have concrete role types inside them :)

[flyingsilverfin]

Humm okay, interesting. Not sure that one will be coming yet, have to think about it more

[flyingsilverfin]

Note: for abstract relations/roles, we will want to be able to do something like this:

request sub relation @abstract,
  relates subject @abstract,
  relates requester,
  relates respondent;