Not signed in (Sign In)

Not signed in

Want to take part in these discussions? Sign in if you have an account, or apply for one below

  • Sign in using OpenID

Site Tag Cloud

2-category 2-category-theory abelian-categories adjoint algebra algebraic algebraic-geometry algebraic-topology analysis analytic-geometry arithmetic arithmetic-geometry beauty bundle bundles calculus categorical categories category category-theory chern-weil-theory cohesion cohesive-homotopy-type-theory cohomology colimits combinatorics comma complex-geometry computable-mathematics computer-science constructive cosmology deformation-theory descent diagrams differential differential-cohomology differential-equations differential-geometry digraphs duality elliptic-cohomology enriched etcs fibration foundations functional-analysis functor gauge-theory gebra geometric-quantization geometry graph graphs gravity grothendieck group group-theory harmonic-analysis higher higher-algebra higher-category-theory higher-differential-geometry higher-geometry higher-lie-theory higher-topos-theory homological homological-algebra homotopy homotopy-theory homotopy-type-theory index-theory integration integration-theory k-theory lie lie-theory limits linear linear-algebra locale localization logic manifolds mathematics measure measure-theory modal modal-logic model model-category-theory monads monoidal monoidal-category-theory morphism motives motivic-cohomology nlab noncommutative noncommutative-geometry number-theory of operads operator operator-algebra order-theory pages pasting philosophy physics pro-object probability probability-theory quantization quantum quantum-field quantum-field-theory quantum-mechanics quantum-physics quantum-theory question representation representation-theory riemannian-geometry scheme schemes set set-theory sheaf simplicial space spin-geometry stable-homotopy-theory string string-theory subobject superalgebra supergeometry svg symplectic-geometry synthetic-differential-geometry terminology theory topology topos topos-theory type type-theory universal variational-calculus

Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.

Welcome to nForum
If you want to take part in these discussions either sign in now (if you have an account), apply for one now (if you don't).
    • CommentRowNumber1.
    • CommentAuthorAndrew Stacey
    • CommentTimeAug 28th 2009

    It strikes me that the "database of categories" really would be better as a database. I'm minded to try implementing it as such. It would have to be technically outside the nLab, though not far outside. As a learning experience, I thought of doing it in ruby. So my questions are:

    1. Is this a good idea?
    2. If so, what features would it be useful to have? Obviously, linked to entries on the nLab, and also filters to, say, display only complete categories, and to sort by columns, and the like. Anything else?
    • CommentRowNumber2.
    • CommentAuthorTobyBartels
    • CommentTimeAug 28th 2009

    Entries should have more options than Yes and No, including Depends, Unknown, and Blank (unknown by us so far, but not verified as unkown in the literature). Really, it should be open to any text, although we'll have to establish some conventions.

    • CommentRowNumber3.
    • CommentAuthorTobyBartels
    • CommentTimeAug 28th 2009

    (I linked your request for input from database of categories and latest changes.)

    • CommentRowNumber4.
    • CommentAuthorMike Shulman
    • CommentTimeAug 28th 2009

    Maybe what we really want is to make the nLab a semantic wiki? (-:

    I notice that there is a project to make a MathML-enabled semantic wiki software: SWiM. I haven't looked at it beyond noticing that fact, though.

    • CommentRowNumber5.
    • CommentAuthorzskoda
    • CommentTimeAug 29th 2009
    I personally think that having one descriptive page per category plus a general descriptive list of categories (top page) as a part of nlab is much better than a database. Databases make sense for very long lists, or when the entries have many features which are parallel and when it makes sense to search according to other parameters. So, for example, searching for finitely closed categories would make a list of such provided somebody writes for every category such a datum. But as I say, it is not so, as some features are known for some categories, not known or even not making sense for another. Take into account that some examples are 2-categories, enriched, additive and so on, and then many new properties make sense which are senseless for categories which are not such, or are automatic (e.g. ever abelian is additive, if the reader of entry on R-mod does not know that then clicking on abelian within the nlab is more instructive than to find in the table that this abelian category happens to be additive). Moreover, the use of listing which among our list of 30 examples are say finitely complete is much smaller than other way around to know if a given category is such; the listing is useful only if we look for an arbitrary example of something. But then it is better to list on usual nlab page for finitely complete categories list of examples. This means if I learn that category X has feature to be finitely complete, I would add it in the list of examples on the page finitely complete category and I would also add to the list of features of the category X finite completeness. This work within nlab descriptove pages will remind me of the various other features of the same and make me think better when I do that than if I woudl be entering some "fields" in a database. In all, the present wiki format is better than classical database model (it would also keep the community working in the same medium, rather than splitting the effort).
    • CommentRowNumber6.
    • CommentAuthorMike Shulman
    • CommentTimeAug 30th 2009

    Yeah, I'm not a huge fan of splitting content between the nlab and somewhere else. I don't think the gain in having an "actual" database of categories outweighs the value of having everything in the same place and easily editable by everyone. As Zoran says (I think), it's much more frequent that I want to know about properties of X category (in which case I can just look on page X) than that I need a list of lots of finitely complete categories.

    • CommentRowNumber7.
    • CommentAuthorAndrew Stacey
    • CommentTimeAug 31st 2009

    There's several points to answer here.

    The "database" is already under construction as a page on the n-lab. As it already exists, and is being rapidly added to, there's clearly someone who wants it (and, as some of you know, it began in response to a comment on the categories mailing list). Given that, one can discuss what is the best implementation. That's the discussion I was trying to start when I asked "Is it a good idea?": not "is a list of lots of categories and their basic properties a good idea?" but "would it be better as an honest database?". So I don't really want to get into whether a "database" is useful or not because if some think it useful, then it's useful. It may be "much more frequent" to want to know about a particular category but, as was also pointed out on the categories mailing list, a "counterexamples in category theory" would be quite useful and a "database" like this would provide a useful indexing for such.

    So let me ask my question again:

    1. Given that it already exists, and some people seem to like the idea, would it be better as a proper database?

    Actually, even that's not quite right. Here's the real question:

    1. Given that it already exists, and some people seem to like the idea, and I would like a project to learn some ruby on rails so that I can be a bit more useful in helping out on the n-lab, would it be better as a proper database?

    Now, on to the other points that have been raised but which are not quite relevant to this discussion, yet are still very interesting.

    Yeah, I'm not a huge fan of splitting content between the nlab and somewhere else.

    I shall resist the temptation to point out the irony of putting this on the n-Forum! I do not understand this point of view at all. The n-lab is a wiki and it may come as a surprise to some but wikis are really bad at some things (if you read my comment on the cafe about them you might think that I regard them as bad at all things). My main example of how bad wikis are is the "latest changes" page. It's horrendous! But it's the best that can be done in a wiki. How much better would it be to have that as part of a forum than a wiki? And we've discussed bibliographies elsewhere, but why force references into the wiki-format? Surely it's better to have them in a proper reference database.

    The key is, of course, to make everything work together. This doesn't need overgrown, overbloated software that can do everything, just that the different pieces know how to talk to each other. Figuring that out is one reason why I want to learn a little ruby on rails so that I can help figure out how to get Instiki and, say, this forum or RefBase to know about each other in a way that's easy for users to use.

    But for that, I need a little project that is small and self-contained so that I can learn the basics ...

    • CommentRowNumber8.
    • CommentAuthorUrs
    • CommentTimeAug 31st 2009

    Didn't we say that we wanted to make more use of the "categeories"-feature of instiki to implement semantic information. We should seriously start doing that.

    • CommentRowNumber9.
    • CommentAuthorMike Shulman
    • CommentTimeAug 31st 2009

    You're right that since the database is being created and some people want it, the question of how useful it would be is not relevant. I agree it would have some use.

    On a personal note, however, I prefer not to have to check lots of different sites in order to see everything that's going on. It's already a pain for me to check "latest changes" and the n-Forum and the n-Cafe, and it means I come late to some discussions or miss them entirely because I get lazy (or busy) and don't always look everywhere. I also don't want users to have to learn lots of different web interfaces in order to contribute.

    That said, I do agree that the current format is pretty bad, for a database. At present it doesn't really even deserve the term "database." However, a wiki has several advantages that it seems to me it would be hard to replicate in, say, an RDBMS. A wiki is a single easy-to-use interface, that invites contributions from everyone, with as low a bar to entry as possible. It automatically tracks changes and diffs by author, and the "database" can easily make links to whatever other pages on the nLab are relevant.

    Now I realize that all of that could be replicated; you could code a nice interface to the database of categories, design the database so that it tracks changes, and implement a crosslinking feature between the nLab and the database -- all of which would require custom coding. However, suppose you've done that, and now someone comes along and wants to make a database of something else. For instance, wouldn't it be nice if Counterexamples in Topology itself were in an online searchable database? Surely there are many other things in mathematics that might benefit from more structured data. So while a specially-designed database of categories separate from the nLab would be better than what there is now, I'd rather have a system where ordinary users can create new "databases" with whatever design they want, without requiring coding RoR to be integrated with the existing system.

    This is one reason I like the semantic wiki concept so much. It can store all sorts of structured information (specifically, an RDF data store, which is like an RDBMS in some ways, but more extensible) in the same place, making crosslinking and referencing easy -- and with a wiki-like backend and interface, tracking changes and making it easy to view and edit.

    • CommentRowNumber10.
    • CommentAuthorAndrew Stacey
    • CommentTimeAug 31st 2009

    I agree about the pain of checking lots of different sites, but that's why RSS and feed readers were invented. It'd be nice if "latest changes" could be converted to RSS (but actually I think it'd be better if "latest changes" were done differently, but as I said elsewhere that's a battle for another day).

    However, it may be possible to mitigate against that anyway (if I have the expression right). I've been learning that it is possible to "include" one rails app in another, so if the database were a rails app then the Instiki page could just silently include it. Then anyone wanting to edit the database could do so, whilst those who just wanted to see it need never know that it was a different app.

    I'm quite keen to see the nLab as a "model" of how to do mathematics interactively on the web. So I'm keen to try out lots of different ideas, and see what works and what doesn't. Yes, everything should interact perfectly, but back in the real world it's an iterative process - those bits that work are the ones that get developed and vice versa. I'd like the hypothetical topologist to be able to say: "I'd like this bit, that bit, and the other from what you guys have at the nLab." and have a working system with no fiddling about.

    I had a quick look at the semantic stuff you linked to but didn't really get grabbed by it. Maybe I need to read more to see the point properly. But I freely admit that I haven't had the time to properly consider it.

    • CommentRowNumber11.
    • CommentAuthorMike Shulman
    • CommentTimeSep 1st 2009

    Maybe if I have some spare time (hah!) I'll try hacking some more semantics into instiki. I fully agree with iterative processes!

    Also, let's start a thread on how to fix "latest changes"!

    • CommentRowNumber12.
    • CommentAuthorMike Shulman
    • CommentTimeSep 2nd 2009

    FWIW, mediawiki appears to have a well-developed semantics extension: Semantic Mediawiki.

    • CommentRowNumber13.
    • CommentAuthorJonAwbrey
    • CommentTimeOct 30th 2009
    • (edited Oct 30th 2009)

    There's a MathWeb Org and a MathWeb Wiki where some people were developing and discussing projects along these lines, but I haven't been back there in a while.

    • CommentRowNumber14.
    • CommentAuthorUrs
    • CommentTimeMar 11th 2010

    concening a recent comment at database of categories:

    I am not sure I see the point of that page. The nLab is the database. What else do we need? We have pages for categories that list or should eventually list the properties of these categories. These pages are labeled with the "category: categories"-tag, that allows to see all of them listed here

    I would say energy invested in the "database" page is more efficiently and usefully invested into the entries that describe single categories.

    • CommentRowNumber15.
    • CommentAuthorTobyBartels
    • CommentTimeMar 12th 2010

    Well, I don't think very much energy is being invested in it, so no harm done.

    A database as Andrew has suggested above, where we could do searches for categories with desired properties, would be useful and worth the effort, if Andrew wants to make that effort (and the rest of us, to fill in the data).

  1. Hello
    I am new to the nForum but would like to contribute by including a link at
    my nLab user page to a 'Table of [Quasi, Meta]Categories' that I am compiling.
    Does anyone think this could be helpful? I do agree that ultimately a database of categories would be far more flexible as the table that I am compiling simply lists the category followed by its objects and the arrows between the objects in that category.
  2. A link to a table of categories I have compiled follows:
    • CommentRowNumber18.
    • CommentAuthorEric
    • CommentTimeJul 5th 2010

    Hi Stephen,

    No comment on your table, but just providing a working link:

    Table of Categories

    You can click the “Source” link in the top right corner to see the syntax.

    • CommentRowNumber19.
    • CommentAuthorUrs
    • CommentTimeJul 5th 2010

    What’s a “metacategory”?

    • CommentRowNumber20.
    • CommentAuthorTodd_Trimble
    • CommentTimeJul 5th 2010
    • (edited Jul 5th 2010)

    I recall that Mac Lane in CWM uses the word ’metacategory’ for large categories like CatCat or superlarge categories like CATCAT. The word ’category’ means a model of the first-order category axioms within a background set theory. I think he eventually settles on sets with one strongly inaccessible cardinal UU as a “good enough” foundation for what he wants to do in his book, so that CatCat is modeled in his set theory (but not CATCAT). Sets of cardinality less than UU he calls ’small’.

    I can take educated guesses as to some of the Baz’s in the table, but of course it all depends what you want to do.

    (Ban,O)(Ban, O): Linear contractions (linear maps of bound no greater than 1).

    (Ban,U)(Ban, U): All bounded linear maps.

    CompComp: continuous functions.

    HausVectHausVect: continuous linear functions.

    OrdOrd: instances of \leq (initial segment inclusions) is usual, but it depends. Also could use full subcategory of PosPos.

    PsTopPsTop: continuous functions (see Lab page pseudotopological space).

    Reg 1Reg_1: continuous functions.

    Set 2Set^2: natural transformations.

    TConvTConv: affine linear maps. (Is that what they’re called? Anyway, it’s a category of algebras for a Lawvere theory, so the notion of morphism is clear.)

    Not sure what is meant by ω\omega-Set, but I suspect this is an example of a functor category (so natural transformations as morphisms).

    I do not know what is meant by LSpaceLSpace, nor by ’Limit’.

    I don’t mean to give offense, but this is a peculiar or random-looking list of categories IMO. A lot of the entries seem to be full subcategories of other well-known categories. Can I ask the author how he finds this list helpful?

    • CommentRowNumber21.
    • CommentAuthorEric
    • CommentTimeJul 5th 2010

    Stephen, I will defer to others, but my opinion is that you should only create an nLab page if you have a need for that page.

    Creating a bunch of pages that just describe a bunch of categories is not the best use of the nLab.

    • CommentRowNumber22.
    • CommentAuthorUrs
    • CommentTimeJul 5th 2010

    I agree that the list of categories is beginning to be a bit random-looking.

    But I also see that this is a problem already seeded by the discussion of a “database of categories” itself. I think that idea in itself carries this problem. To see whatt I mean, try thinking of the term “database of sets”, which may ring the same alarm-bells more quickly.

    Here is what I think we should do:

    there is not too much point of having an entry named Ban, given that this is a pretty arbitrary abbreviation that might easily collide with lots of other names for categories that people may want to use.

    Instead what we should to is this:

    • the entry Banach space itself should of course describe Banach spaces and kinds of morphisms between them

    • if the properties of the category of Banach spaces are interesting enough to warrant their separate discussion, then we should create an entry titled category of Banach spaces.

    (compare for instance our entry category of sheaves).

    Some categories have pretty globally accepted canonical names, such as Set and Top (and even these are not universally adopted). For these we should have entries with these names as titles. But doing this for every random category seems to be not so useful.

    • CommentRowNumber23.
    • CommentAuthorIan_Durham
    • CommentTimeJul 5th 2010
    • (edited Jul 5th 2010)
    From CWM, p.7:

    "A metacategory is a metagraph with two additional operations: Identity, ...; Composition,... These operations in a metacategory are subject to the two following axioms: Associativity,... Unit law..."

    where the ellipsis (what's the plural of 'ellipsis?') are the definitions of the italicized items.
    • CommentRowNumber24.
    • CommentAuthorTodd_Trimble
    • CommentTimeJul 5th 2010

    Ellipses. :-)

    The important thing to take away from this is Mac Lane’s opening, “First, we describe categories directly by means of axioms, without using any set theory…” Then, on page 10, he writes, “A category (as distinguished from a metacategory) will mean any interpretation of the category axioms within set theory.”

    Then, on page 12, under Large Categories, he writes, “In addition to the metacategory of all sets – which is not a set – we want an actual category SetSet, the category of all small sets. We shall assume that there is a big enough set UU, the “universe”, then describe a set as “small” if it is a member of the universe, and take SetSet to be the category whose set UU of objects is the set of all small sets, with arrows all functions from one small set to another.” He then goes on to describe other large categories.

    Thus, close textual reading is required to see what Mac Lane is up to here.

    • CommentRowNumber25.
    • CommentAuthorHarry Gindi
    • CommentTimeJul 5th 2010

    Thus, close textual reading is required to see what Mac Lane is up to here.

    I “lolled”.

    • CommentRowNumber26.
    • CommentAuthorMike Shulman
    • CommentTimeJul 5th 2010

    Would it be helpful, do you think, for us to have a page called metacategory to help unconfuse people? Basically no one uses that word (or the similar meaning of “quasicategory”) any more, but it seems that a lot of people who learn about category theory from CWM or from Joy of Cats get the impression that those are standard terms. I added a note about this to quasicategory already.

    • CommentRowNumber27.
    • CommentAuthorTodd_Trimble
    • CommentTimeJul 5th 2010

    That’s a good idea, Mike.

    • CommentRowNumber28.
    • CommentAuthorMike Shulman
    • CommentTimeJul 5th 2010

    Okay, I created metacategory.

    • CommentRowNumber29.
    • CommentAuthorTodd_Trimble
    • CommentTimeJul 5th 2010

    Thanks, Mike – that looks really good!

    • CommentRowNumber30.
    • CommentAuthorStephen Britton
    • CommentTimeJul 7th 2010
    • (edited Jul 7th 2010)

    Todd: I find the list of categories helpful to me for organizing some known categories. Yes, a lot of the entries on "Table of [Quasi, Meta]Categories" are subcategories of other well known categories. The table is probably not terribly helpful to many researchers in category theory but I mostly created the table as a personal reference and as an afterthought gave the link so that if anyone wanted to look at it they could.

    Eric: You are probably right. "Creating a bunch of pages that just describe a bunch of categories is not the best use of the nLab."

    Mike: Thank you, thank you Mike for fixing some of the mess I've made by creating metacategory and linking it from CAT. That truly shows initiative.