Want to take part in these discussions? Sign in if you have an account, or apply for one below
Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.
This entry appears to duplicate descent object. Should it be deleted?
Ideally the entry is either expanded to spell this out in great detail (more so than descent object, and in a way similar to other pages that are very explicit in explaining in detail content that is covered at a high level elsewhere), or else completely removed.
3
Category of descent data is a particular presentation of a 2-categorical limit which amounts to descent object in the classical setup, it is not the same thing. So it is a difference between a universal property and a concrete realization. Behinds, I think(maybe I am wrong) Street introduced words descent object and codescent object to make sense in more general 2-categories not necessarily in Cat. I would certainly not like to merge the pages.
Idea section:
Category of descent data is a particular presentation of a 2-categorical limit in Cat which tries to solve the descent problem. It can be defined in several setups. In a formulation of descent via fibered categories and Grothendieck topologies, as well as in the (co)monadic descent. In the first case, the descent category appears as a presentation of the descent object, while in the (co)monadic descent the descent category is given by the Eilenberg-Moore category of the (co)monad.
It is perfectly fine to provide specific presentations and give references, but this type of material would be much easier to find if it was covered in the main article descent object. As far as I can see, that’s the way the nLab usually covers such topics: abstract (∞,1)-categorical descriptions and their concrete models typically appear in the same article.
(To clarify the distinction is not about -categorical generalization versus 1-categorical, but about considering the descent object within the (general) ambient 2-category or working with concretely defined categories as they are.)
It is hard to understand for a general mathematician if the 2-categorical (or even higher categorical) nonsense on abstract limits is conflated with straightforward definition/presentation in terms of descent data (not yet spelled out completely on this page). Among pure (non-categorical) algebraists, for example, the descent theory is considered a difficult, almost esoteric subject, and having the logic which starts even more abstractly is a no starter for them. Besides there are so many 1-categorical cases there to cover which would obscure the general page. For example, there are categories of relative descent data for a generalized morphism of corings defined by Brzezinski et al. in a very explicit matter (never called descent object) and the 2-categorical picture of those is not at all clear how to do.
I had this trouble so many times in last 14 years: I recommend an Lab page to my students or colleagues (who are not higher category theorists nor homotopy theorists) and they turn to me that it is unreadable and they do not want even to listen when I suggest another page later to them. It alienates so many people. I think there is a clear cut at least in this kind of cases: when there is a classical notion with a classical name and classical conventions, even when it can be covered as a special case of a general thing stripped from classical culture, it deserves a special page, at least when there is somebody willing to write it. There are links which can help go to a general case for those who wish.
I myself also have considerable trouble orienting myself in extremely long pages, I am simply not functioning intellectually well when the material is scattered and lots of scrolling is necessary. This is a reason why I rarely contribute at all to already big pages in the Lab, even when I otherwise would. It is simply hard intellectually for me. (Surely, I don’t like also switching among the plethora of extremely small pages either.)
We have the !include functionality for cases where a block of material works well both as part of a larger entry as well as a stand-alone entry.
In the present case, you could start a page titled
(notice the suffix) whose content should start with a sub-section header
### Category of descent data
followed by the content of the intended section (and nothing else).
This could then be included both at descent object as well as at category of descent data by typing
[[!include category of descent data -- section]]
at that point in the source code where the section should be sitting.
I am doing this all the time. For instance the code for the “Properties”-section at monad currenlty looks, in its entirety, as follows:
## Properties
[[!include relation between adjunctions and monads -- section]]
because the same section appears (included) also at adjoint functor and might well-deserve its own stand-alone entry, too (which by an !include is readily created, but might want to wait until the section is fleshed out a bit more).
So you are suggesting how to have both versions with a single effort. That may be indeed nice when some thought on compatibility of the section in the context is performed. One can also have some part in category of descent data which entirely does not fit into the bigger entry outside of include part. I may do it properly once I submit my next paper which I am now finishing with a coauthor (on some new examples of Hopf algebroids).
1 to 10 of 10