# Start a new discussion

## Not signed in

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

## Discussion Tag Cloud

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

• CommentRowNumber1.
• CommentTimeOct 8th 2020
Dear all,
I would like to suggest that the page of page-categories of the nLab https://ncatlab.org/nlab/page_categories should have a more strict structure.

I wanted to propose something along the lines of, each page_category should be either:
1. a mathematical object (all the theorems, definitions and constructions go there)
2. a person or people (some 3163 pages--this is mostly ok already),
3. books and papers, (have 3 overlapping pages, it seems: https://ncatlab.org/nlab/all_pages/Paper%20References, https://ncatlab.org/nlab/all_pages/reference and https://ncatlab.org/nlab/all_pages/references) - some 200 pages, perhaps?
4. fields of mathematics (Wikipedia has 72 of these) AND
5. MISC, for whatever else people wanted to have, like jokes, or things difficult to classify.

This would help when relating the nLab to WikiData using the property https://www.wikidata.org/wiki/Property:P4215

Does this sound sensible to you? There are only 60 page_categories, so these we could do by hand very easily, if you think this is a good idea.
Maybe this has been discussed in the nForum before, maybe it was discarded because of traditional rules that I don't know about. If so, I would like to know the rationale. Thanks!
• CommentRowNumber2.
• CommentAuthorDavidRoberts
• CommentTimeOct 8th 2020

I vaguely recall we had a big discussion about this years ago. I’m not opposed, just getting it done (and then maintaining it) needs some thought.

• CommentRowNumber3.
• CommentTimeOct 15th 2020
Do you have a link to the old discussion David?

it seems to me that once the 60 categories are in place, new pages should be easier to categorize.
• CommentRowNumber4.
• CommentAuthorDavidRoberts
• CommentTimeOct 15th 2020

I’d have to really go hunting for it. I only have a vague memory of it!

• CommentRowNumber5.
• CommentAuthorTim_Porter
• CommentTimeOct 16th 2020

Is this what you were thinking of?

• CommentRowNumber6.
• CommentAuthorRichard Williamson
• CommentTimeOct 16th 2020
• (edited Oct 16th 2020)

Hi Valeria, I would suggest to go ahead with this if you feel motivated; I cannot imagine anybody objecting, as it only adds some structure and achieves some tidying up, it should not interfere with anything. If anybody has any input on something, they can always chip in. By going through pages, we may be able to do some further tidying along the way (there are some old/little linked to pages which could do with a makeover). I may be able to help with some generic changes if you tell me specifically what you want: e.g. it will probably be easier for me to handle item 3. behind the scenes to merge the relevant categories, once it is decided what exactly the end result should be.

In short, I suggest to just go ahead if you are motivated to do so, announcing here what you are doing and if you wish to do anything which needs to be scripted/done generically.

• CommentRowNumber7.
• CommentAuthorRichard Williamson
• CommentTimeOct 16th 2020
• (edited Oct 16th 2020)

Once it is done, we could also consider enforcing use of categories in future in the software, or at least making a prominent request to categorise. I tend to think that as long as it does not add significant time to page creation or have other significant side-effects, any structure is good structure; people can always ignore it! We could also/alternatively add category information to the nForum posts made when editing/creating a page, so that it is easier to see where/when there are opportunities to categorise.

• CommentRowNumber8.
• CommentAuthorDavidRoberts
• CommentTimeOct 16th 2020

@Tim that may have been it. That’s quite a while ago!

• CommentRowNumber9.
• CommentAuthorGuest
• CommentTimeOct 17th 2020
Thanks everyone!

@Richard, how structured is the categories system as currently implemented? My understand is that it's rather flat: a category X to a page, we simply include "category: X" in the source. How would one go about assigning each existing category to one of the five 'meta-categories' that Valeria proposes? Is it possible with the current software?

More generally, would it eventually be feasible to implement a preorder structure on nLab categories? As Valeria mentions, we're currently exploring various ways to strengthen the link between the nLab and Wikidata (https://www.wikidata.org/wiki/Property_talk:P4215) or other semantic web tools, with the end goal of finding a way to create and maintain a research level category theory ontology. It would potentially be very useful if the nLab somehow encoded information such as eg. Set is an example of a category, which is an example of a mathematical object.

Brendan Fong
1. Hi Brendan, I was thinking just to do this manually: there are not that many existing categories on the nLab, so if someone goes through and describes how to assign each to a meta-category, as well as indicates which can be merged/tidied up, I can use a script behind the scenes to go through all the pages to make this assignment.

As for the syntax/structure, feel free to suggest what you would like. Currently it is as you describe. But it should be fairly easy to add structure and extend the syntax. Let me know what you suggest regarding syntax.

• CommentRowNumber11.
• CommentAuthorRichard Williamson
• CommentTimeOct 17th 2020
• (edited Oct 17th 2020)

By the way, over the next two weeks I will probably have a little more time than usual; I am planning to try to get my rewrite of the nForum up and running, but if we settle quickly enough on what we wish to do with the categories here, I can try to make time for this as well.

• CommentRowNumber12.
• CommentTimeOct 21st 2020
Hi @Tim! long time, no see! Thanks for finding the old conversation! I hope all's well in your neck of the woods!

MANY Thanks @RichardWilliamson!!! for offering to help and real apologies for my delay in replying -- I was trying to make a deadline, but should've checked the nForum!

We (that's me, Brendan, Evan and Antonin) were worried that the categories might not be nestable into meta-categories and we really wanted to be very conservative with touching people's work. so happy to hear that this is not a problem!

Brendan explained our big plan, and yes, I also think that it would be nicer if later on people creating pages could tell us what kind of page they created.
But as I said just organizing the categories we already have into these meta-categories I think would be useful. so I'm sorry we just missed some days when you could've helped.
• CommentRowNumber13.
• CommentAuthorGuest
• CommentTimeOct 23rd 2020

Hi Richard,

Thanks so much for offering some time to work on this. If it’s not too late, something along the following lines would be helpful for us (and hopefully the whole community):

1. Add an additional interface in the nLab somewhere to assign page-categories to meta-categories.
2. Change the page_categories page to be organised by meta-category, with an additional “unassigned” section for page-categories that have not been assigned to a meta-category.
3. Create the five meta-categories Theory, Mathematical Object, Reference, Person, and Miscellaneous, and assign/merge/rename/delete existing page-categories to these according to this spreadsheet.

Would this be possible? We’re flexible about the details, so please let us know if you have any suggestions or concerns. Please also let us know how we can help.

The main goal, from the point of view of using the nLab as a source for generating a formal ontology and doing text analysis, is to have tags that separate the pages that concern mathematics directly (eg. mathematical objects), those that concern cultural aspects of category theory (eg. people), and those that concern the functioning of the nLab itself (eg. meta, empty, or drafts)

Valeria can perhaps provide more detail, but as I understand it the suggested five meta-categories are motivated by simple examination of the ways the page-categories have been used. One perhaps undesirable property is that the “person” and “reference” meta-categories function like page-categories: it would make sense to assign pages directly to them. (Eg. the only page-category assigned to the “person” meta-category is itself called “person”, and it has more than 3000 entries.) On the other hand, the “theory” meta-category has about 25 constituent page-categories, each with ~5 to 50 entries.

Brendan Fong

• CommentRowNumber14.
• CommentAuthorGuest
• CommentTimeOct 23rd 2020

Also, it seems there are 435 pages with “> history” at the end of their title, and having checked a few they largely seem to be blank pages last edited in 2009. For example,

Is there a particular role that they play?

Brendan Fong

• CommentRowNumber15.
• CommentAuthorUrs
• CommentTimeOct 23rd 2020

Regarding our > history suffixes:

The Instiki wiki software that the $n$Lab is running on does not offer a mechanism to users to delete pages. The closest there is to deleting a page is to clear its content and remove all links pointing to it. But sometimes a page needs to be removed that (and because) it has a duplicate, or there may be some other reason that we must still retain links to a page with that same title, just not that particular page. In this case the quasi-deletion of the page must go along with its title being changed to something else. We adopted the habit of adding that > history suffix (or at least some of us do. Maybe it was Toby’s original idea and then I followed it.)

Regarding the categories-functionality:

Myself, I have been using the categories-functionality in precisely two cases only: for category: people and category: reference. Others here have experimented with other uses, which is what you probably see, but none of that has become established usage, as far as I am aware and concerned.

Instead, the would-be role of the categories-tag is played by the more sophisticated floating context menus, that I am putting in the top right of most entries (see the top-right of most any entry for an example, e.g. topos). If you want to do some kind of data-banking with “categories” of $n$Lab entries, then it’s these floating context-menus that you should go for.

• CommentRowNumber16.
• CommentTimeOct 23rd 2020
Thanks for the explanation of the "context" tags, Urs! we had discussed amongst ourselves that these looked more like categories than the ones in the pages themselves, but I thought we would tackle their kinds after "cleaning" up a little.

Dealing with the empty/semi-deleted pages (484 of these semi-deleted is not a tiny number) seems an easy and sensible thing to do.

Having categories :people and :references also seems very reasonable.

But having categories: reference(https://ncatlab.org/nlab/all_pages/reference),
references (https://ncatlab.org/nlab/all_pages/references) and https://ncatlab.org/nlab/all_pages/Paper%20References seems silly. or rather an oversight.

On the other hand making a difference between "mathematical theories" and "mathematical objects" is one that's a bit more consequential. It helps to disambiguate between Topology (Capitalized, as the name of the theory) and any old topology on a set or a space. (of course proof theorists might want to say that mathematical theories are mathematical objects too, but the oversimplification that they are not seems worth doing).
• CommentRowNumber17.
• CommentAuthorUrs
• CommentTimeOct 24th 2020

When you spot a silly typo anywhere on the nLab , please fix it.

• CommentRowNumber18.
• CommentTimeNov 6th 2020
• (edited Nov 6th 2020)
Thanks for the "carte blanche", Urs! Typos I can deal with, the 'brainos' are more complicated.

I have two questions:
1. There are only two pages on the category "noncommutative algebraic geometry".
these are: Hopf-Galois extension and noncommutative localization
Could these two pages be moved to the category "noncommutative geometry" simply?

2. Similarly, could all pages classified as "model theory" (only 4 with this category at the moment) be moved to "logic"?

thanks, Valeria
• CommentRowNumber19.
• CommentAuthorDavidRoberts
• CommentTimeNov 6th 2020

I would lean towards moving the first two into algebraic geometry, assuming there is such a category, not NC geometry. Certainly the people I know who work on that stuff fall more into the AG camp than the NCG camp.

I agree with the model theory move.

• CommentRowNumber20.
• CommentTimeNov 6th 2020
Thanks David!
• CommentRowNumber21.
• CommentAuthorUrs
• CommentTimeNov 7th 2020

Regarding #18, just to clarify: In saying in #17 that you are invited to fix trivial typos, I didn’t hand out a “carte blanche”, instead I just recalled a basic feature of the $n$Lab as a public Wiki:

You – and everyone else – is invited to edit the $n$Lab. You are even invited to make substantial edits. The difference between fixing trivial typos and making more interesting edits is only that the latter should please be announced here. That’ what it says below each entry’s edit pane:

Now regarding the nature of more substantial edits that would be worthwhile, I feel we are still not on the same page.

My impression is that you are energetic about polishing up the $n$Lab’s system of organizing entries by their topic context.

There is, as you noticed, a built-in functionality for this, provided by our Instiki software. However, that functionality (like so many features and non-features of Instiki) was found, in the early days of the $n$Lab, to be unsuited for our purposes:

The Instiki functionality is simply that all the entries that are labeled category: X are shown to the user as one single huge string of entry names. When the list becomes long, this is hard to read, and lacking any information on how the entries are organized among each other.

For that reason we introduced instead those “floating context menus” which you see on the top right of most entries (and coded in the top part of their source code). These are much like the topic cluster boxes that are also used on many entries on Wikipedia. They provide the means to nicely format and organize the list of entries that is to be grouped together.

Now these “floating context menus” have been used systematically. Most entries do carry such a context mentu, and many are organized within them (though by far not all).

The use of the category-functionality has been more experimental and remains more incomplete.

If anyone is energetic about polishing this up, then just removing some of the more obviously failed experiments at adding category-labels doesn’t quite scratch the surface of the issue, to my mind. Instead, there are these three sensible possibilities I can think of:

Either we make official the abandoning of the category-system and remove all these labels. This would serve to avoid the user getting the wrong impression from this incomplete system that, for instance, we have just one entry on category theory, because only one entry ever got labeled by that category (while most entries on category theory do carry their proper floating context menu).

Or we say we do care about the category-system, in which case there should be an effort not to remove these labels, but to add them abundantly, namely to all entries which should be included under a given category.

Thirdly: Best would be if somebody with some coding skill would figure out a way to combine both systems: Optimally we could add a simple line in an entry’s code to determine it’s topic-categories and then the software would automatically grab the corresponding well-formatted floating context menus and add them to the entry.

• CommentRowNumber22.
• CommentAuthorRichard Williamson
• CommentTimeNov 7th 2020
• (edited Nov 7th 2020)

My apologies for not replying to #13 yet, in the time I have available for working on the nLab, I have been focusing on other things. I will get back to it as soon as I can. I will just say for now that I have a slightly different point of view from Urs; I do see benefits of a greater degree of categorisation of nLab pages, and I am also not really a fan of the context menus, which I essentially always ignore.

On the other hand, I do agree with many of Urs’s points, for instance that we need code changes to significantly improve the functionality, and that we need to properly go in for use of categories if we choose to use them at all.

Let me come back to #13 when I have time. I am willing to make code changes as required, as time permits of course; of course others could make an attempt at this as well. In the meantime, it would be good to resolve upon how exactly we’d like categorisation to function in an ideal world, and then we can see how far we can come in practise to achieve that.