Replace trait with interface in new docs

Author: flyingsilverfin

new_home/modules/ROOT/pages/get_started/schema.adoc

@@ -130,14 +130,12 @@ Finally, commit the transaction by typing:
 commit
 ----
 
-Alternatively, you could use the command `close` to discard your changes and close the transaction.
---
-====
-
 [NOTE]
-====
+=====
 A quick *tip* if you are using Console for this course. Queries on this page can be turned into runnable *Console scripts* by clicking the "`hidden lines`" button (image:{page-version}@new_home::/svg/eye.svg[width=24]).
 These scripts can then be *pasted* directly into the server-level interface of Console, and run end-to-end simply by pressing kbd[Enter].
+=====
+--
 ====
 
 == Defining your schema
@@ -201,10 +199,10 @@ Finally, commit the transaction by typing `commit` and press kbd[Enter]. You hav
 
 Let us dissect the second query in a bit more detail.
 
-* In the first line of the query we introduce the relation type `friendship` with a `friend` *role* (in _programmer lingo_: think of a role as a *trait* that other types can implement). In the same line, we also declare that each friendship requires _exactly two friends_ when created (`card` is short for "`cardinality`", and is a first example of an *annotation*. Annotations make schema statements much more specific - but more on that in a moment).
-* In the second line, we then define that users *can play* the role of friends in friendships (in _programmer lingo_: the type `user` *implements* the "`friend-role`" trait).
+* In the first line of the query we introduce the relation type `friendship` with a `friend` *role* (in _programmer lingo_: think of a role as a *interface* that other types can implement). In the same line, we also declare that each friendship requires _exactly two friends_ when created (`card` is short for "`cardinality`", and is a first example of an *annotation*. Annotations make schema statements much more specific - but more on that in a moment).
+* In the second line, we then define that users *can play* the role of friends in friendships (in _programmer lingo_: the type `user` *implements* the "`friend-role`" interface).
 
-It's worth pointing out that roles are only one of two kinds of traits that types may implement, the other being *ownership*: for example, in our first query above we defined that the `user` type "`implements the username owner trait`". These traits make our life very easy as we'll see, especially when dealing with type hierarchies!
+It's worth pointing out that roles are only one of two kinds of interfaces that types may implement, the other being *ownership*: for example, in our first query above we defined that the `user` type "`implements the username owner interface`". These interfaces make our life very easy as we'll see, especially when dealing with type hierarchies!
 
 Let's write a few more definition queries to get a feel of database schemas in TypeDB.
 
@@ -224,7 +222,7 @@ For example:
 include::./schema.adoc[tag=define3]
 ----
 
-This defines a `start-date` attribute and then declares each friendship may own a `start_date` (i.e., the type `friendship` implements the "`start-date owner`" trait). The definition is followed by a `@card` annotation, which specifies that friendships own _between_ zero or one start dates. In fact, this is the default cardinality, so you don't actually need `@card` here at all.
+This defines a `start-date` attribute and then declares each friendship may own a `start_date` (i.e., the type `friendship` implements the "`start-date owner`" interface). The definition is followed by a `@card` annotation, which specifies that friendships own _between_ zero or one start dates. In fact, this is the default cardinality, so you don't actually need `@card` here at all.
 
 The next query illustrates usage of "`unbounded`" cardinality together with another useful annotation, `@key`. This specifies that the `username` of a `user` should uniquely identify a user, i.e., it is a _key attribute_.
 
@@ -233,7 +231,7 @@ The next query illustrates usage of "`unbounded`" cardinality together with anot
 include::./schema.adoc[tag=define4]
 ----
 
-Importantly, different types may own the same attributes; and, similarly, different types may play the same role of a relation type. This flexibility of connecting types is a central feature of data modeling with TypeDB. Run the next query to define an `organization` type which shares many of the traits of `user`:
+Importantly, different types may own the same attributes; and, similarly, different types may play the same role of a relation type. This flexibility of connecting types is a central feature of data modeling with TypeDB. Run the next query to define an `organization` type which shares many of the interfaces of `user`:
 
 [,typeql]
 ----
@@ -268,7 +266,7 @@ friendship owns start-date @card(0..1);
 include::./schema.adoc[tag=define3]
 ----
 
-This defines a `start-date` attribute and then declares each friendship may own a `start_date` (i.e., the type `friendship` implements the "`start-date owner`" trait). The definition is followed by a `@card` annotation, which specifies that friendships own _between_ zero or one start dates. In fact, this is the default cardinality, so you don't actually need `@card` here at all.
+This defines a `start-date` attribute and then declares each friendship may own a `start_date` (i.e., the type `friendship` implements the "`start-date owner`" interface). The definition is followed by a `@card` annotation, which specifies that friendships own _between_ zero or one start dates. In fact, this is the default cardinality, so you don't actually need `@card` here at all.
 
 The next query illustrates usage of "`unbounded`" cardinality together with another useful annotation, `@key`. This specifies that the `username` of a `user` should uniquely identify a user, i.e., it is a _key attribute_.
 
@@ -289,7 +287,7 @@ user owns username @key;
 include::./schema.adoc[tag=define4]
 ----
 
-Importantly, different types may own the same attributes; and, similarly, different types may play the same role of a relation type. This flexibility of connecting types is a central feature of data modeling with TypeDB. Run the next query to define an `organization` type which shares many of the traits of `user`:
+Importantly, different types may own the same attributes; and, similarly, different types may play the same role of a relation type. This flexibility of connecting types is a central feature of data modeling with TypeDB. Run the next query to define an `organization` type which shares many of the interfaces of `user`:
 
 ////
 [,typeql]
@@ -325,14 +323,14 @@ Let's define two types that specialize our earlier `organization` type: namely,
 ----
 include::./schema.adoc[tag=define6]
 ----
-Note that we haven't defined any traits for companies and universities; indeed, all traits of the supertype `organization` are automatically *inherited*! That doesn't stop from defining new traits for our subtypes, of course:
+Note that we haven't defined any interfaces for companies and universities; indeed, all interfaces of the supertype `organization` are automatically *inherited*! That doesn't stop from defining new interfaces for our subtypes, of course:
 
 [,typeql]
 ----
 include::./schema.adoc[tag=define7]
 ----
 
-Of course, you would be able to give the new subtypes additional traits that are not inherited from the supertype as well!
+Of course, you would be able to give the new subtypes additional interfaces that are not inherited from the supertype as well!
 
 --
 
@@ -355,7 +353,7 @@ entity university sub organization;
 #!test[schema]
 include::./schema.adoc[tag=define6]
 ----
-Note that we haven't defined any traits for companies and universities; indeed, all traits of the supertype `organization` are automatically *inherited*! That doesn't stop from defining new traits for our subtypes, of course:
+Note that we haven't defined any interfaces for companies and universities; indeed, all interfaces of the supertype `organization` are automatically *inherited*! That doesn't stop from defining new interfaces for our subtypes, of course:
 ////
 [,typeql]
 ----
@@ -374,7 +372,7 @@ user plays enrolment:student;
 include::./schema.adoc[tag=define7]
 ----
 
-Of course, you would be able to give the new subtypes additional traits that are not inherited from the supertype as well!
+Of course, you would be able to give the new subtypes additional interfaces that are not inherited from the supertype as well!
 
 Don't forget to commit the transaction by typing `commit` and pressing kbd[Enter].
 

new_reference/modules/ROOT/pages/typeql/annotations/card.adoc

@@ -10,17 +10,17 @@ to specify cardinality ranges for roles and ownerships.
 .Range Argument Syntax
 [,typeql]
 ----
-<type label> <trait> <type label 2> @card(N..M);
-<type label> <trait> <type label 2> @card(N..);
+<type label> <interface> <type label 2> @card(N..M);
+<type label> <interface> <type label 2> @card(N..);
 ----
 
 .Single Scalar Argument Syntax
 [,typeql]
 ----
-<type label> <trait> <type label 2> @card(N);
+<type label> <interface> <type label 2> @card(N);
 ----
 
-The `@card` annotation can be defined for any `<trait>` of: `owns`, `relates`, or `plays`.
+The `@card` annotation can be defined for any `<interface>` of: `owns`, `relates`, or `plays`.
 
 It accepts either a range argument or a single scalar argument.
 Arguments must be integers.
@@ -32,7 +32,7 @@ Arguments must be integers.
 == Usage
 
 // TODO: Update for ordered/unordered when lists are implemented
-Every trait has a default `cardinality` constraint, accessible in <<_default_cardinality>>.
+Every interface has a default `cardinality` constraint, accessible in <<_default_cardinality>>.
 
 // tag::description[]
 When defined, the `@card` annotation overrides the default `cardinality` with the specified arguments.
@@ -66,7 +66,7 @@ include::{page-version}@new_reference::example$tql/schema_annotations.tql[tags=d
 === Subtyping
 
 // TODO: Put somewhere in a common place and reference it
-Similarly to inherited type constraints, trait constraints also affect subtypes from both sides.
+Similarly to inherited type constraints, interface constraints also affect subtypes from both sides.
 For example, the following query defines that:
 
 - A `page` instance must have between 1 and 3 names.
@@ -93,14 +93,14 @@ Cannot be used with the xref:{page-version}@new_reference::typeql/annotations/ke
 == References
 
 [#_default_cardinality]
-=== Default trait cardinalities
+=== Default interface cardinalities
 
-The following `cardinality` constraints are set for traits by default if no `@card` annotations are declared:
+The following `cardinality` constraints are set for interfaces by default if no `@card` annotations are declared:
 
-.Default Trait Cardinalities
+.Default interface Cardinalities
 [cols=".^1,^.^1"]
 |===
-^| Trait ^| Cardinality
+^| interface ^| Cardinality
 | `owns`
 | `card(0..1)`
 

new_reference/modules/ROOT/pages/typeql/annotations/distinct.adoc

@@ -23,12 +23,12 @@ The `@distinct` annotation does not accept any arguments.
 
 == Usage
 
-The `@distinct` annotation enforces the `distinct` constraint for an ordered type trait.
+The `@distinct` annotation enforces the `distinct` constraint for an ordered type interface.
 This constraint ensures that lists contain only distinct values.
 // TODO: Add a reference to lists and their behavior
 
 [NOTE]
 ====
-Ordered traits, lists, and related annotations like `@distinct` are not yet available in TypeDB.
+Ordered interfaces, lists, and related annotations like `@distinct` are not yet available in TypeDB.
 Coming soon!
 ====

new_reference/modules/ROOT/pages/typeql/data_model.adoc

@@ -5,7 +5,7 @@ This page gives a brief technical overview of TypeDB's type system and query mod
 In short, TypeDB's data model is based on a *type system* built from two key ingredients:
 
 * a _single-inheritance_ subtyping system, allowing a type to specialize to zero or more subtypes.
-* a _trait-based_ reference system, allowing instances to refer to other instances.
+* a _interface-based_ reference system, allowing instances to refer to other instances.
 
 TypeDB's query model is tailored to this type system, directly expressing subtyping and references in its query statements, but also  allowing users to chain together queries and data operations into powerful *multi-stage data pipelines* for all types of workloads.
 
@@ -32,7 +32,7 @@ Instances of entity types, simply called entities, can be created _indepdently_,
 11. *Relation types*, specified using the keyword `relation`, and are required to have at least one *associated role type* specified with the keyword `relates`.
 +
 --
-Instances of relation types may reference (or "link") zero or more data instances for each associated role type, called their *players* of that role (these data instance must have types with corresponding *player trait*).
+Instances of relation types may reference (or "link") zero or more data instances for each associated role type, called their *players* of that role (these data instance must have types with corresponding *player interface*).
 
 For example, a friendship relations may link two friends (implemented by, say, two user entities).
 
@@ -41,7 +41,7 @@ Relations without role players will be removed (no "`dangling relations`").
 11. *Attribute types*, specified using the keyword `attribute`, and required to have an *associated value type* (either structured or primitive) specified with the keyword `value`.
 +
 --
-Instances of attribute types carry an *associated value* of the associated value type. They may also reference other data instances, called their *owners* (these data instances must have direct types with the corresponding *owner trait*). Two attributes are considered equal if they have the same associate value and have the same (origin) type.
+Instances of attribute types carry an *associated value* of the associated value type. They may also reference other data instances, called their *owners* (these data instances must have direct types with the corresponding *owner interface*). Two attributes are considered equal if they have the same associate value and have the same (origin) type.
 
 Attributes without owners will be removed (no "`dangling attributes`", unless the attribute type is marked as independent).
 --
@@ -65,15 +65,15 @@ Two instances of a value type are equal exactly when their literal values are eq
 Coming soon.
 ====
 
-=== Type traits and "`objects vs attributes`"
+=== Type interfaces and "`objects vs attributes`"
 
-Entity types can have traits, i.e. play roles or own attribute types. This allows us to create connections of entities with other data.
+Entity types can have interfaces, i.e. play roles or own attribute types. This allows us to create connections of entities with other data.
 
-Relation types can also have traits, i.e. play roles or own attribute types. This, for example, allows the creation of nested relations (i.e., relations playing roles in other relations).
+Relation types can also have interfaces, i.e. play roles or own attribute types. This, for example, allows the creation of nested relations (i.e., relations playing roles in other relations).
 
-Since entity and relation types together make up "`first-class`" types in TypeDB's type system (when it comes to type traits) they are, together, also referred to as *object types*, whose instances are data *objects*.
+Since entity and relation types together make up "`first-class`" types in TypeDB's type system (when it comes to type interfaces) they are, together, also referred to as *object types*, whose instances are data *objects*.
 
-Attributes cannot have traits; they are merely typed associations of values to objects.
+Attributes cannot have interfaces; they are merely typed associations of values to objects.
 
 === Subtyping
 
@@ -88,7 +88,7 @@ Data instances (i.e., entities, relation, are attributes) are stored using datab
 
 == Definitions
 
-User-defined types, their traits, and their subtyping structure, are created and modified through xref:{page-version}@new_reference::typeql/index.adoc#statements[definition statements] in xref:{page-version}@new_reference::typeql/index.adoc#queries[schema queries].
+User-defined types, their interfaces, and their subtyping structure, are created and modified through xref:{page-version}@new_reference::typeql/index.adoc#statements[definition statements] in xref:{page-version}@new_reference::typeql/index.adoc#queries[schema queries].
 
 == Data pipelines
 

new_reference/modules/ROOT/pages/typeql/index.adoc

@@ -106,14 +106,14 @@ The former query introduces types, while the latter will query for types. The ge
 Definitions in schema queries concern:
 
 * *type* definitions, introducing new types via the appropriate keyword (`entity`, `relation` + `relates`, `attribute` + `value`). Types are referred to by a unique type *labels*; multiple aliases of the latter can be introduced (coming soon).
-* *trait* definitions, introducing player or owner traits (via `plays` and `owns` keywords). Player traits allow type instances to be referred to as players in roles of relations. Owner traits allow type instances to be referred to as
-* *subtyping* definitions, declare types to be subtypes of other types (via the keyword `sub`). Traits of supertypes are inherited by subtypes.
+* *interface* definitions, introducing player or owner interfaces (via `plays` and `owns` keywords). Player interfaces allow type instances to be referred to as players in roles of relations. Owner interfaces allow type instances to be referred to as
+* *subtyping* definitions, declare types to be subtypes of other types (via the keyword `sub`). interfaces of supertypes are inherited by subtypes.
 
 === Pattern statements
 
 In contrast, in patterns we support a wide variety of syntax, including for:
 
-* *Retrieving types* based on label, traits, and inheritance.
+* *Retrieving types* based on label, interfaces, and inheritance.
 * *Retrieving data* in types, e.g. based on references between data instance such as attribute ownerships and relation linkages (via keywords such as `has`, `links`, and anonymous versions thereof)
 * Function calls (`let $a, $b in <FUN-CALL>`)
 * Computation with values (`let $x = <EXPR>`)

new_reference/modules/ROOT/pages/typeql/keywords.adoc

@@ -290,7 +290,7 @@ Denotes the return signature of a function. See xref:{page-version}@new_referenc
 Used to remove ownership of attributes and players of roles in xref:{page-version}@new_reference::typeql/pipelines/delete.adoc[Delete stages] of data pipelines.
 
 `from`::
-Used to remove traits, role specialisation, and annotations in xref:{page-version}@new_reference::typeql/schema/undefine.adoc[Undefine queries].
+Used to remove interfaces, role specialisation, and annotations in xref:{page-version}@new_reference::typeql/schema/undefine.adoc[Undefine queries].
 
 `in`::
 Used to access stream or list elements. See xref:{page-version}@new_reference::typeql/statements/let-in.adoc[] for more information.