#### Howdy, Stranger!

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

Options

# Chapter 3

edited May 29

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

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.

• Options
1.

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")?

Comment Source: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")?
• Options
2.

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

Comment Source:I don't think so. The Category D determines what kind of diagram/(limit/co limit) the functor is.
• Options
3.
edited May 30

Let me take a shot.

With reference to comment 1. 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.

Comment Source: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.
• Options
4.
edited May 30

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

Comment Source:This is awesome, @Fredrick! Thanks so much for the clarification (and also thank you @Christopher for the comment)!
• Options
5.
edited June 3

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}$$.

Comment Source: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}\$$.
• Options
6.

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

Comment Source: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".
• Options
7.
edited June 5

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.

Comment Source: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.