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.
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.
I’d have to really go hunting for it. I only have a vague memory of it!
Is this what you were thinking of?
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.
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.
@Tim that may have been it. That’s quite a while ago!
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.
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.
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):
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
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
Regarding our > history suffixes:
The Instiki wiki software that the 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 Lab entries, then it’s these floating context-menus that you should go for.
When you spot a silly typo anywhere on the nLab , please fix it.
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.
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 Lab as a public Wiki:
You – and everyone else – is invited to edit the 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:
For non-trivial edits, please briefly describe your changes below. Your comments will be added to the nForum discussion thread for this page, which can also be used for further discussion related to it. For trivial edits, such as correcting typos, please leave the box below empty; feel free to ask for advice at the nForum if you are unsure.
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 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 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.
For similar comments see another thread here.
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.
1 to 22 of 22