TypeQL section for docathon #949
Conversation
|
|
||
| E.g. An `employment` relation exists to relate an `employer` to an `employee`. | ||
| An `employment` instance cannot exist without the other instances which play these roles. |
There was a problem hiding this comment.
I think it's often useful to repeat an important and possibly confusing concept a couple times:
Relations are types with one-or-more associated "role" types, <which you define in the schema>.
An instance of a relation "depends" on instances of other types which "play" these roles <you define>. <This is the primary distinction between entities, and relations!>
E.g. An `employment` relation exists to relate an `employer` to an `employee`.
<Consider that an> `employment` <relation> instance cannot exist without the other instances which play these roles<, hence the idea that `employment`s "depend" on the participating players.>
| [,typeql] | ||
| ---- | ||
| attribute age, value integer;` |
| ---- | ||
| person owns age; | ||
| ---- |
There was a problem hiding this comment.
Worth noting what this does - <This is the only way to associate concrete data with entities or relations, so you'll be doing this frequently>
| == Polymorphism | ||
|
|
||
| Polymorphism in TypeDB comes is realised in two ways: |
|
|
||
| === Interfaces | ||
| Multiple types may "implement" the same interface. In the following schema snippet, the `employer` role in the `employment` relation can be played by a `company` or an `charity`. |
There was a problem hiding this comment.
I think it's worth pulling up the idea that a role is a kind of interface you define by creating the role, and can impement with plays, and that attributes define an implicit interface you impement with owns.
Then go on to say that:
< multiple types may implement the same interface (i.e. use own the same attribute, or play the same role >
Again this is a new/different idea so I think worth repeating multiple times in slightly different ways.
|
|
||
| === Subtyping | ||
| A single-inheritance *subtyping* system allows types to specialize an existing type. |
There was a problem hiding this comment.
Specify directly:
TypeDB supports a single-inheritance subtyping system. This allows types to specialize an existing type, and automatically gain any owns or plays implementations from their supertypes,
| relates subject, | ||
| relates content; | ||
| relation content-engagement @abstract, sub interaction, |
There was a problem hiding this comment.
Let's put the sub on the next line as a style IMO
| [NOTE] | ||
| ==== | ||
| An attribute type inherits and implicitly specialises the interface of its supertype. |
There was a problem hiding this comment.
Not sure it's worth saying as the user never sees this IMO?
There was a problem hiding this comment.
That's why it's in a note rather than in the main text.
I think it's easier to understand the behaviour of attribute ownerships if they understand how plays works and know the mapping to attributes.
There was a problem hiding this comment.
Fair enough, i think it's a usefu parallel
| === Cardinality constraints on specialisation | ||
| Cardinality constraints declared on an interface applies to all instances of that interface (including specialisations). | ||
| A specialisation of an interface can also "tighten" the constraint. |
There was a problem hiding this comment.
I think our mental model is now simpler - we just require that data conforms to ALL the constraints that are directly declared or on all parents declarations
Goal
Implementation