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.
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:
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.
(I linked your request for input from database of categories and latest changes.)
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.
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.
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:
Actually, even that's not quite right. Here's the real question:
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 ...
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.
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.
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.
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"!
FWIW, mediawiki appears to have a well-developed semantics extension: Semantic Mediawiki.
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.
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.
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).
Hi Stephen,
No comment on your table, but just providing a working link:
You can click the “Source” link in the top right corner to see the syntax.
What’s a “metacategory”?
I recall that Mac Lane in CWM uses the word ’metacategory’ for large categories like or superlarge categories like . 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 as a “good enough” foundation for what he wants to do in his book, so that is modeled in his set theory (but not ). Sets of cardinality less than 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.
: Linear contractions (linear maps of bound no greater than 1).
: All bounded linear maps.
: continuous functions.
: continuous linear functions.
: instances of (initial segment inclusions) is usual, but it depends. Also could use full subcategory of .
: continuous functions (see Lab page pseudotopological space).
: continuous functions.
: natural transformations.
: 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 -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 , 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?
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.
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.
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 , the category of all small sets. We shall assume that there is a big enough set , the “universe”, then describe a set as “small” if it is a member of the universe, and take to be the category whose set 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.
Thus, close textual reading is required to see what Mac Lane is up to here.
I “lolled”.
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.
That’s a good idea, Mike.
Okay, I created metacategory.
Thanks, Mike – that looks really good!
1 to 30 of 30