Mention comonadicity.

]]>Added a cross-reference to slice of presheaves is presheaves on slice. At the moment, this content is duplicated here.

]]>Re #53: do you mean a reference predating Lawvere’s introduction of comma categories in his thesis?

Yes. I notice that in Marta Bunge’s thesis, she attributes the concept both to Grothendieck and Beck, but does not give an explicit reference.

]]>Re #53: do you mean a reference predating Lawvere’s introduction of comma categories in his thesis?

]]>It would be nice to have a reference for where slice categories were introduced. Does anyone have an idea where this might be?

]]>A special case of the second example is the construction of monoidal toposes as slice toposes over monoid objects. I have added (here) pointer to that example.

]]>Added in examples

The fundamental theorem of topos theory states that the slice category for any object in a topos is itself a topos.

For a monoidal category the slice category over any monoid object is monoidal.

Is there more to be said about the latter case?

Anonymous

]]>Next, the notation and terminology between this and the following proposition really ought to be harmonized. Much room left for someone energetic about it to polish these entries…

]]>I have copied over the statement and proof to *undercategory*, then dualized the statement here and added pointer to there.

(Being interrupted now, hope all is consistent.)

]]>Yes I think this was laziness on my part. The bit on (co)limits was written for undercategories, but the entry for overcategories was the more comprehensive one which should contain such information.

We should (copy it over to “undercategory”) and edit it to apply to overcategories.

]]>Yeah, I guess so, although I guess the author meant to dualize and then forgot?

]]>Proposition 3.4 in the article overcategory suddenly starts talking about limits in undercategories. Yet there is a separate article undercategory. Should this proposition be moved there?

]]>Fortunately, most mathematicians are not machines.

]]>it’s always obvious to me from context what is a category and what is an object

$x/y$ is not machine parsible into something that adds inclusions and identities without knowing the types of its arguments which makes the parsing much more complicated. For parsing the common abbreviated notation one really needs 3 operators - slice, coslice, and real comma category where the latter has arguments that are explicitly functors and doesn’t imply additional structure.

]]>Todd: That does help.

]]>My problem is with ’slice’ and ’coslice’ as they do not conjure up an image

I was addressing precisely that in #30, and offering a possible image to keep in mind.

]]>I’ve never ever been confused by this – it’s always obvious to me from context what is a category and what is an object, especially because people tend to use separate typefaces for categories and their objects, such as $c\in C$ or $X\in \mathcal{C}$. Whereas I have frequently been confused by $c\backslash C$.

]]>$C/c$ and $c/C$ are not two different operations; they are both special cases of the same operation $f/g$, usually called a comma category.

Yes, formally, Often informally one speaks of $c$ being an object in $C$ and doesn’t explicitly state that the two symbols in $c/C$ really stand for an inclusion of $c$ into $C$ and the identity on $C$. It is this rotational convention and elision where the two distinct operations exist.

]]>I was meaning the notation $(A,c_a)$ or $A\downarrow c_a$. They are cumbersome but unambiguous. I like A/a and probably a/A is not too bad, but the / and \ based notations mix poorly with other contexts sometimes e.g. in groups. My problem is with ’slice’ and ’coslice’ as they do not conjure up an image (unlike ‘over’ and under’, as you say.) I am not suggesting any change but those names are not that clear to me.

]]>$C/c$ and $c/C$ are not two different operations; they are both special cases of the same operation $f/g$, usually called a comma category.

]]>’slice’ was not clear as it gave no intuition as whetehr it was ’a/A’ or ’A/a’.

More confusingly is that one of those things is a coSlice.

under category rather disparagingly says

Given a category $C$ and an object $c \in C$, the

under category(also calledcoslice category) $c \downarrow C$ (also written $c/C$ and sometimes, confusingly, $c\backslash C$) is the category whose …

I think it is confusing to use the same operator symbol for two different operations where you have to disambiguate by from the type of the arguments.

I’ve been looking at the category of bi-pointed edge labeled quivers on a fixed set of labels $L$ which involve slice and coslice in its definition.

$\bot_L \backslash \, \bot_L \backslash \, Quiv / \top_L$($\top_L$ is the one object quiver with $L$ edges, $\bot_L$ is the free rooted action of $L$ on a set - the infinite edge labeled tree)

At least with different symbols you know what things are supposed to be categories and what are objects.

[ people like me with camelCased last names are more sympathetic to camelCase ]

]]>You think $(A,a)$ is less ambigous than $A/a$? Or are you talking about $A\downarrow a$? I find it perfectly clear in $A/a$ that $A$ is “over” $a$, just like in $1/2$ the 1 is “over” the 2.

The only notation that I find really execrable (apart from $(f,g)$ that no one seems to use any more, thankfully, but has left its trace in the name “comma category”) is $a\backslash A$, in which it looks like $A$ is still “over” $a$ but what is meant is the co-slice *under* $a$.

I was just editing a manuscript and the ’over’ v. ’slice’ terminological point was relevant so let me say that I have always found that ’slice’ was not clear as it gave no intuition as whetehr it was ’a/A’ or ’A/a’. Oh I know it is properly defined in the usual sources, but the image of ‘slicing’ was vague. I think the use of the comma category notation is less ambiguous, whilst still talking about objects over a or under a.

]]>The notation might be from Grothendieck, I have a vague feeling that the pure category theorists in old times preferred the comma notation (which is more general).

]]>