It looks like you're new here. If you want to get involved, click one of these buttons!

- All Categories 2.2K
- Applied Category Theory Course 352
- Applied Category Theory Seminar 4
- Exercises 149
- Discussion Groups 49
- How to Use MathJax 15
- Chat 479
- Azimuth Code Project 108
- News and Information 145
- Azimuth Blog 149
- Azimuth Forum 29
- Azimuth Project 189
- - Strategy 108
- - Conventions and Policies 21
- - Questions 43
- Azimuth Wiki 711
- - Latest Changes 701
- - - Action 14
- - - Biodiversity 8
- - - Books 2
- - - Carbon 9
- - - Computational methods 38
- - - Climate 53
- - - Earth science 23
- - - Ecology 43
- - - Energy 29
- - - Experiments 30
- - - Geoengineering 0
- - - Mathematical methods 69
- - - Meta 9
- - - Methodology 16
- - - Natural resources 7
- - - Oceans 4
- - - Organizations 34
- - - People 6
- - - Publishing 4
- - - Reports 3
- - - Software 21
- - - Statistical methods 2
- - - Sustainability 4
- - - Things to do 2
- - - Visualisation 1
- General 39

Options

This is the place for discussing Chapter 3 of this book:

- Brendan Fong and David Spivak,
*Seven Sketches in Compositionality*. See also the website with videos.

Chapter 3 is about databases - and now we will finally meet categories, functors, and universal constructions.

Lectures will start on Monday 28 May 2018. But you can start reading the book and doing exercises now!

Fredrick Eisele is putting some exercises onto this forum. Please try some and put up your answers! If one of them is not up yet at the following location, you can put it there.

- Exercise 1 - Chapter 3
- Exercise 3 - Chapter 3
- Exercise 4 - Chapter 3
- Exercise 5 - Chapter 3
- Exercise 7 - Chapter 3
- Exercise 8 - Chapter 3
- Exercise 9 - Chapter 3
- Exercise 11 - Chapter 3
- Exercise 13 - Chapter 3
- Exercise 14 - Chapter 3
- Exercise 17 - Chapter 3
- Exercise 22 - Chapter 3
- Exercise 23 - Chapter 3
- Exercise 24 - Chapter 3
- Exercise 25 - Chapter 3
- Exercise 29 - Chapter 3
- Exercise 31 - Chapter 3
- Exercise 32 - Chapter 3
- Exercise 35 - Chapter 3
- Exercise 37 - Chapter 3
- Exercise 39 - Chapter 3
- Exercise 45 - Chapter 3
- Exercise 48 - Chapter 3
- Exercise 51 - Chapter 3
- Exercise 53 - Chapter 3
- Exercise 54 - Chapter 3
- Exercise 59 - Chapter 3
- Exercise 61 - Chapter 3
- Exercise 62 - Chapter 3
- Exercise 65 - Chapter 3
- Exercise 66 - Chapter 3
- Exercise 67 - Chapter 3
- Exercise 72 - Chapter 3
- Exercise 74 - Chapter 3
- Exercise 75 - Chapter 3
- Exercise 81 - Chapter 3
- Exercise 82 - Chapter 3
- Exercise 84 - Chapter 3

## Comments

About Definition 3.41: when the authors say "A

diagramin \(\mathcal{C}\) is a functor from any category \( D\)", do they actually mean "Adiagramin \(\mathcal{C}\) is a functor \( D\) from any category" (i.e. with D referring to "functor" instead of "any category")?`About Definition 3.41: when the authors say "A _diagram_ in \\(\mathcal{C}\\) is a functor from any category \\( D\\)", do they actually mean "A _diagram_ in \\(\mathcal{C}\\) is a functor \\( D\\) from any category" (i.e. with D referring to "functor" instead of "any category")?`

I don't think so. The Category D determines what kind of diagram/(limit/co limit) the functor is.

`I don't think so. The Category D determines what kind of diagram/(limit/co limit) the functor is.`

Let me take a shot.

With reference to comment 1. Yes, \(D\) is a functor the category is \(\mathcal{J}\)

Definition 3.41A

diagramin \(C\) is a functor from any category \( D : \mathcal{J} \rightarrow C \). We say that the diagram \(D\)commutesif \( D f = D f' \) holds for every parallel pair of morphisms \(f , f' : a \rightarrow b\) in \(\mathcal{J}\) . We call \(\mathcal{J}\) theindexing categoryfor the diagram.Paraphrased Definition 3.41A

diagramin \(C\) is a functor, \(D\), from anindexing category, \(\mathcal{J}\). The functor \(D\) must preserve structure, i.e. itcommutes, parallel paths are preserved by \(D\). $$ D : \mathcal{J} \rightarrow C $$ The subsequentExample 3.42can be confusing.In

Definition 3.41\( D \) is a functor, a morphism between categories \(\mathcal{J}\) and \( C \).In

Example 3.42\(\mathcal{D}\) is a category.Here is a mapping between the names:

$$ \begin{array}{c c | l } Definition 3.41 & Example 3.42 & \text{role} \\ \mathcal{J} & \mathcal{C} & \text{index category} \\ C & \mathcal{D} & \text{diagram in category} \\ D & F, G & \text{diagram} \end{array} $$ The diagram is a formal version of the informal idea of a template.

`Let me take a shot. With reference to [comment 1](https://forum.azimuthproject.org/discussion/comment/18762/#Comment_18762). Yes, \\(D\\) is a functor the category is \\(\mathcal{J}\\) **Definition 3.41** A _diagram_ in \\(C\\) is a functor from any category \\( D : \mathcal{J} \rightarrow C \\). We say that the diagram \\(D\\) _commutes_ if \\( D f = D f' \\) holds for every parallel pair of morphisms \\(f , f' : a \rightarrow b\\) in \\(\mathcal{J}\\) . We call \\(\mathcal{J}\\) the _indexing category_ for the diagram. **Paraphrased Definition 3.41** A _diagram_ in \\(C\\) is a functor, \\(D\\), from an _indexing category_, \\(\mathcal{J}\\). The functor \\(D\\) must preserve structure, i.e. it _commutes_, parallel paths are preserved by \\(D\\). \[ D : \mathcal{J} \rightarrow C \] The subsequent **Example 3.42** can be confusing. In **Definition 3.41** \\( D \\) is a functor, a morphism between categories \\(\mathcal{J}\\) and \\( C \\). In **Example 3.42** \\(\mathcal{D}\\) is a category. Here is a mapping between the names: \[ \begin{array}{c c | l } Definition 3.41 & Example 3.42 & \text{role} \\\\ \mathcal{J} & \mathcal{C} & \text{index category} \\\\ C & \mathcal{D} & \text{diagram in category} \\\\ D & F, G & \text{diagram} \end{array} \] The diagram is a formal version of the informal idea of a template.`

This is awesome, @Fredrick! Thanks so much for the clarification (and also thank you @Christopher for the comment)!

`This is awesome, @Fredrick! Thanks so much for the clarification (and also thank you @Christopher for the comment)!`

In example 3.51 I think objects \(u\) and \(z\) and morphisms \(a, b, h, k\) could mislead someone, one could delete them and have just an elaborated naturality square 3.49, and to elaborate it more, paint also a complex conmutative diagram in \(\mathcal{C}\), that would have two separate, blue and a red same-shape "shadows" in \(\mathcal{D}\), with a green \(\mathcal{D}\)-morphism between each blue and red shadow of the objects of the diagram in \(\mathcal{C}\).

\(a, b, h, k\) were happy denizens of \(\mathcal{D}\) that didn't knew they had to relate with the new blue and red images of morphisms of \(\mathcal{C}\).

`In example 3.51 I think objects \\(u\\) and \\(z\\) and morphisms \\(a, b, h, k\\) could mislead someone, one could delete them and have just an elaborated naturality square 3.49, and to elaborate it more, paint also a complex conmutative diagram in \\(\mathcal{C}\\), that would have two separate, blue and a red same-shape "shadows" in \\(\mathcal{D}\\), with a green \\(\mathcal{D}\\)-morphism between each blue and red shadow of the objects of the diagram in \\(\mathcal{C}\\). \\(a, b, h, k\\) were happy denizens of \\(\mathcal{D}\\) that didn't knew they had to relate with the new blue and red images of morphisms of \\(\mathcal{C}\\).`

Regarding the introduction, one real life case that happens in industry is that software projects are evolving animals with incremental versions, updates, upgrades, new features, fixes... and the transition from waterfall to agilistic requirement management demands that data schemas need to be adaptable. One must provide a mechanism that allow a version deployed at a client to be actualized to a newer one without the client loosing its data. So frequently even in the same project an update implies a sort of data "migration".

`Regarding the introduction, one real life case that happens in industry is that software projects are evolving animals with incremental versions, updates, upgrades, new features, fixes... and the transition from waterfall to agilistic requirement management demands that data schemas need to be adaptable. One must provide a mechanism that allow a version deployed at a client to be actualized to a newer one without the client loosing its data. So frequently even in the same project an update implies a sort of data "migration".`

Julio - I guess you're happy now, but a "diagram of shape \(\mathcal{A}\) in the category \(\mathcal{B}\)" is just a functor \(F : \mathcal{A} \to \mathcal{B}\). (I'm deliberately using completely different letters, because you should never get attached to particular letters.)

So, for example, there's a category \(\mathcal{A}\) called the

square:and we can look at a diagram of this shape in any category \(\mathcal{B}\). Very roughly speaking, it's like a picture of shape \(\mathcal{A}\) drawn on the canvas \(\mathcal{B}\). This is a very important and beautiful idea.

`Julio - I guess you're happy now, but a "diagram of shape \\(\mathcal{A}\\) in the category \\(\mathcal{B}\\)" is just a functor \\(F : \mathcal{A} \to \mathcal{B}\\). (I'm deliberately using completely different letters, because you should never get attached to particular letters.) So, for example, there's a category \\(\mathcal{A}\\) called the **square**: <center><img src = "http://math.ucr.edu/home/baez/mathematical/7_sketches/graph_square.png"></center> and we can look at a diagram of this shape in any category \\(\mathcal{B}\\). Very roughly speaking, it's like a picture of shape \\(\mathcal{A}\\) drawn on the canvas \\(\mathcal{B}\\). This is a very important and beautiful idea.`

$$\times \vdash \Delta \vdash +$$ I've been so intrigued with this idea. It is mind blowing for me for some reason like finding out Vader is Luke's father. But in reading Chapter 3 of Spivak and Fong text, they also use a similar notation \(\Pi_{F} \vdash \Delta_{F} \vdash \Sigma_{F}\) and then use this to explain left and right adjunctions. The way they explain it sounds like they are saying that left adjoints are "sum-like" somehow acting like colimits in that they pick out interconnected parts and right adjoints are "product-like" somehow acting like limits in that they find tuples with common traits.

Is this a safe intuition to have for adjunctions in general or only true for the examples they use in the book? It seems to go well with left=liberal, right=conservative analogy John uses as well but being a newby not sure how far the analogy can be taken.

`$$\times \vdash \Delta \vdash +$$ I've been so intrigued with this idea. It is mind blowing for me for some reason like finding out Vader is Luke's father. But in reading Chapter 3 of Spivak and Fong text, they also use a similar notation \\(\Pi_{F} \vdash \Delta_{F} \vdash \Sigma_{F}\\) and then use this to explain left and right adjunctions. The way they explain it sounds like they are saying that left adjoints are "sum-like" somehow acting like colimits in that they pick out interconnected parts and right adjoints are "product-like" somehow acting like limits in that they find tuples with common traits. Is this a safe intuition to have for adjunctions in general or only true for the examples they use in the book? It seems to go well with left=liberal, right=conservative analogy John uses as well but being a newby not sure how far the analogy can be taken.`

Yeah! Even more so: category theory revealed that our

basic concepts in arithmetic and logicare related in ways that nobody had suspected before! It's astounding!It's pretty safe for adjunctions between categories that are fairly similar to \(\mathbf{Set}\). You'll noticed that in our study of databases we're focusing on categories of the form \(\mathbf{Set}^{\mathcal{C}}\). These are fairly similar to \(\mathbf{Set}\) in many ways. (Technically we say they are "toposes".)

If we were working with categories like \(\mathbf{Set}^{\text{op}}\), everything would be turned around and your intuitions would be destroyed. A left adjoint functor from \(\mathcal{C}\) to \(\mathcal{D}\) gives a right adjoint functor from \(\mathcal{C}^{\text{op}} \) to \(\mathcal{D}^\text{op}\), and vice versa!

Then there are categories like \(\mathbf{FinVect}\), the category of finite-dimensional vector spaces and linear maps, that are equivalent to their own opposite. These are neither like \(\mathbf{Set}\) nor like \(\mathbf{Set}^{\text{op}}\), but somehow poised right in between.

It takes some time to develop intuitions refined enough to handle all these different flavors of category. However, you are on the right track... thinking about important stuff!

`> It is mind blowing for me for some reason like finding out Vader is Luke's father. Yeah! Even more so: category theory revealed that our _basic concepts in arithmetic and logic_ are related in ways that nobody had suspected before! It's astounding! > The way they explain it sounds like they are saying that left adjoints are "sum-like" somehow acting like colimits in that they pick out interconnected parts and right adjoints are "product-like" somehow acting like limits in that they find tuples with common traits. Is this a safe intuition to have for adjunctions in general or only true for the examples they use in the book? It's pretty safe for adjunctions between categories that are fairly similar to \\(\mathbf{Set}\\). You'll noticed that in our study of databases we're focusing on categories of the form \\(\mathbf{Set}^{\mathcal{C}}\\). These are fairly similar to \\(\mathbf{Set}\\) in many ways. (Technically we say they are "toposes".) If we were working with categories like \\(\mathbf{Set}^{\text{op}}\\), everything would be turned around and your intuitions would be destroyed. A left adjoint functor from \\(\mathcal{C}\\) to \\(\mathcal{D}\\) gives a right adjoint functor from \\(\mathcal{C}^{\text{op}} \\) to \\(\mathcal{D}^\text{op}\\), and vice versa! Then there are categories like \\(\mathbf{FinVect}\\), the category of finite-dimensional vector spaces and linear maps, that are equivalent to their own opposite. These are neither like \\(\mathbf{Set}\\) nor like \\(\mathbf{Set}^{\text{op}}\\), but somehow poised right in between. It takes some time to develop intuitions refined enough to handle all these different flavors of category. However, you are on the right track... thinking about important stuff!`

WOW. I knew vector spaces are beautiful mathematical objects but this is yet again mind blowing. Sounds like they are kind of like a hologram of adjunctions.

`>Then there are categories like \\(\mathbf{FinVect}\\), the category of finite-dimensional vector spaces and linear maps, that are equivalent to their own opposite. These are neither like \\(\mathbf{Set}\\) nor like \\(\mathbf{Set}^{\text{op}}\\), but somehow poised right in between. WOW. I knew vector spaces are beautiful mathematical objects but this is yet again mind blowing. Sounds like they are kind of like a hologram of adjunctions.`

Whenever you take the transpose of a matrix, you are exploiting the fact that \(\mathbf{Vect}\) is equivalent to its own opposite! You're turning a linear map \(T : \mathbb{R}^m \to \mathbb{R}^n \) into a linear map \(T^\top : \mathbb{R}^n \to \mathbb{R}^m \), which is somehow the same map seen backwards.

This is part of why linear algebra is so powerful. Among other things, quantum mechanics explains our world using linear algebra. Every process in quantum mechanics has a time-reversed process!

`Whenever you take the transpose of a matrix, you are exploiting the fact that \\(\mathbf{Vect}\\) is equivalent to its own opposite! You're turning a linear map \\(T : \mathbb{R}^m \to \mathbb{R}^n \\) into a linear map \\(T^\top : \mathbb{R}^n \to \mathbb{R}^m \\), which is somehow the same map seen backwards. This is part of why linear algebra is so powerful. Among other things, quantum mechanics explains our world using linear algebra. Every process in quantum mechanics has a time-reversed process!`

Here's a

Puzzleusing Chapter 3's concepts:Consider your favorite database schema \(\mathcal{C}\). Suppose you have two instances of the databases that you wish to merge. Let \(I:\mathcal{C}\to\mathbf{Set}\) and \(J:\mathcal{C}\to\mathbf{Set}\) be the instances of each database. For example, company A (database \(I\)) and company B (database \(J\)) are merging their employee records, and luckily for you, both databases have the same structure \(\mathcal{C}\).

Merging these databases is equivalent to a universal construction in a certain category. What is the construction and in what category? Here's a hint, the merged database is another instance of \(\mathcal{C}\) so call it \(K:\mathcal{C} \to \mathbf{Set} \).

`Here's a **Puzzle** using Chapter 3's concepts: Consider your favorite database schema \\(\mathcal{C}\\). Suppose you have two instances of the databases that you wish to merge. Let \\(I:\mathcal{C}\to\mathbf{Set}\\) and \\(J:\mathcal{C}\to\mathbf{Set}\\) be the instances of each database. For example, company A (database \\(I\\)) and company B (database \\(J\\)) are merging their employee records, and luckily for you, both databases have the same structure \\(\mathcal{C}\\). Merging these databases is equivalent to a universal construction in a certain category. What is the construction and in what category? Here's a hint, the merged database is another instance of \\(\mathcal{C}\\) so call it \\(K:\mathcal{C} \to \mathbf{Set} \\).`