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

- All Categories 2.1K
- Applied Category Theory Course 279
- Applied Category Theory Exercises 138
- Applied Category Theory Discussion Groups 40
- Applied Category Theory Formula Examples 15
- Chat 450
- Azimuth Code Project 107
- News and Information 145
- Azimuth Blog 148
- Azimuth Forum 29
- Azimuth Project 190
- - Strategy 109
- - Conventions and Policies 21
- - Questions 43
- Azimuth Wiki 707
- - Latest Changes 699
- - - 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 20
- - - Statistical methods 2
- - - Sustainability 4
- - - Things to do 2
- - - Visualisation 1
- General 38

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.`