You can use expressions in various other places

• translated to EDMX-expressions
• to define projections between types
• projections can be resolved at runtime (runtime views)
• expressions can be evaluated in memory

Query does not mean that it is a database query. There can be multiple vehicles for an expression. Conceptually though, it can be understood as part of a query - whether it is either sent to the database, converted to edmx (and then sent to the backend again), or evaluated in memory.
This is an important point though. Expressions are not only meant for database queries.

Keeping this open -> happy for suggestions on how to formulate this.

I think this is way to complicated to illustrate path expressions. Why not use something like

address[kind = 'home'].street

this would result in SQL, which readers can actually understand

make an association more specific

i.e. to navigate to a subset of the associated entities

don't forget to specify the literal formats for

• Date
• Time
• Timestamp
• Binary

Whenever I see Venn diagrams explaining JOINs I'm reminded of this article/rant, where the author makes the case that set theory is a false analogy as JOINs are rather a cross product filtered by a predicate with an optional UNION:
https://blog.jooq.org/say-no-to-venn-diagrams-when-explaining-joins/

Food for thought 🤔 The JOIN diagrams shown there could also come in helpful in some Capire guides.

Thanks for the link! This topic also came up when writing the theory section, because the inner join is indeed $\{ (a, b) \in \text{Authors} \times \text{Books} | a.\text{id} = b.\text{author\_id} \}$ -> a cross product with a filter.

Just jotting down my thoughts:
The key point of the blog entry in regards to why this can not be shown as a Venn diagram is that the sets (Authors and Books) are of a different type and are not union-compatible. So $\text{Authors} \cap \text{Books}$ is indeed not correct.
Rather, we implicitely look at the cross product
$$X = \{ \space (a_1, \dots, a_n, b_1, \dots, b_m) \in \{ \text{Authors} \cup \{(\omega, \dots, \omega)\} \} \times \{ \text{Books} \cup \{(\omega, \dots, \omega)\} \} - \{(\omega, \dots, \omega)\} \space \}$$
with each circle representing:
$$\text{Authors}' = \{ (a_1, \dots, a_n, b_1, \dots, b_m) \in X | a_\text{id} \ne \omega \}$$
$$\text{Books}' = \{ (a_1, \dots, a_n, b_1, \dots, b_m) \in X | b_\text{id} \ne \omega \}$$

Getting the actual authors back is now only an exercise of projection:
$$\{ (a_1, \dots, a_n) \} = \{ \pi_{a_1, \dots, a_n}(\text{Authors}') \} = \text{Authors}$$
-> Select distinct a.* from Authors a full join Books b on 1 = 1

Since the sets are independent of the projection (what we select), any join operations simply filter on the cross product, which imho can be nicely displayed using venn diagrams. So I do disagree with the author of the blog even though they have a point. I also think the join diagrams could come in helpful.

One of the key points in cql / cxl is that path navigation allows us to work on sets and only consider the select list (projection in relational algebra) at the end. When actually writing relational algebra, the tuple needs to be defined explicitely. CQL and SQL also handle null values nicely. When writing relational algebra, null values need to be explicitely included.