I am intermittently thinking about categories again, and I think I got something wrong in the current set of notes. I there defined slice categories in a way that doesn’t work, at least given my initial preferred definition of categories (which is the same as Awodey’s or Riehl’s).
OK: What is an arrow in a slice category from the object to the object — where, of course, are -objects, and are -arrows?
Since we are constructing from data in the natural thing to do is to use a -arrow which interacts appropriately with and , giving us a commuting triangle with .
But that still leaves two options. The simpler option (1) identifies the needed -arrow with by itself. A more complex option (2) takes the needed -arrow to be the whole commuting triangle, or if you like, the triple . In the earlier set of notes I went for the simpler (1). But I don’t think this can be right for a reason I explain. And I now note that Leinster initially goes for (2) (though his language then wobbles).
So here are two improved(?)pages on slice categories which I do hope now get things right. But let me know if I have gone off-piste!
4 thoughts on “Two pages on slice categories”
To my mind, the second, more complex definition is the right one. However, I think there is a deeper problem here rooting in some sloppiness of the definition of what constitutes an arrow in general. My feedback stems from the perspective of a non-mathematician (I am a computer scientist with some mathematical interest) who seriously tries to learn category theory (but is still at the beginning because of too much other things to do).
My discomfort with your definition (Def. 13, Category, p. 30) as with the corresponding definitions from the standard textbooks on which I had a glimpse before (Awodey, Leinster) stems from the fact that none of you states clearly (and you yourself possibly forget later on) that an arrow is really a thing with three components. You only mention two of them, domain and codomain (or source and target). But what is the third one? You don’t even have a name for it and this is probably where the problem starts. I suggest to call it »naked arrow« and to contrast it with »full« or »fully specified arrow«. The latter is the thing you and the other textbook authors call just »arrows« and I suggest to understand henceforth the expression »arrow« whenever used without qualifier as a fully specified one.
To have a precise formal notation (and leaving possible set theoretic issues aside), I suggest to model arrows as triples , where is the name of the fully specified arrow, the derived notation for its naked arrow, and and denote source and target, respectively. As objects in a category, naked arrows are (from a categorical perspective) opaque entities without any required properties. They basically can be anything. Since they normally play no role in isolation, their notation as the name of the fully specified arrow decorated with an underscore suffices – if one wants to mention them at all. I admit, it is a bit difficult to maintain compatibility with the other standard notation for arrows. Let us interpret the in this notation – somewhat inconsistent but in accordance with standard notation – as the name for the fully specified arrow. Thus, the respective naked arrow is not mentioned at all within this notation and this is a problem in the rare cases where it has an independent life. Slice categories are such an occasion. Thus, for the latter arrow notation I suggest the following variant to make the naked arrow explicit: where , i.e. in this case is the naked arrow belonging to the fully specified arrow . Thus, the -notation, if present, signals that the such wrapped entity denotes the naked, not the full arrow.
As for the slice category, accordingly, I suggest the following modified definition: If for -objects and (note that according to the present convention, and denote fully specified -arrows) there is a -arrow such that , then there exists a -arrow or . That is, the construed -arrow has the -arrow as its naked arrow and as its source and target the -objects and , respectively (in fact, I think it would be more consistent to leave out the superfluous -objects and and to define the -objects just as the respective (fully specified) -arrows and , respectively, while we remember that and ).
Composition: Let be a -arrow for , and such that , and let be another -arrow for and such that . Then .
Identity: The identity arrow for is .
For another \left(C/X\right)-object (you have a typo on p. 49 before Def. 25 where you write »… giving us a distinct -object …« instead of »… …«) with we have with as required.
Correction for the identity arrow definition: If I keep on with your definition of -objects as pairs of -objects and -arrows, rather than as just the -arrows, then, of course:
The identity arrow for is and for another -object with we have with as required.
OK, I had a fresh look on your Def. 12 of a Category (Version January 24, 2023): You define “… For each arrow f, there are unique associated objects src(f) and tar(f), …”.
I disagree: Source and target are not merely associated to an arrow. They are proper parts. An arrow is a composite of three components where source and target are two of them, the third one I suggest to call “bare arrow” (This possibly sounds better than “naked” arrow, I am sorry, I am not a native English speaker).
I admit, this is not a matter of truth but one of practicality. Treating source and target as proper parts of an arrow absolves us from introducing a special, an ad hoc treatment of slice categories. And there are probably more occasions that require special treatment if one insists that source and target are merely associated but not genuine parts of arrows.
To me, the more fundamental issue with (1) is that src(j) and tar(j) cannot be uniquely defined; the specific example just reiterates that an arrow j can be part of more than one commuting triangle.