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 book bundles calculus categorical categories category category-theory chern-weil-theory cohesion cohesive-homotopy-type-theory cohomology colimits combinatorics comma complex complex-geometry computable-mathematics computer-science constructive cosmology deformation-theory descent diagrams differential differential-cohomology differential-equations differential-geometry digraphs duality elliptic-cohomology enriched fibration finite foundation 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-theory limits linear linear-algebra locale localization logic mathematics measure-theory modal modal-logic model model-category-theory monad 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 stack string string-theory superalgebra supergeometry svg symplectic-geometry synthetic-differential-geometry terminology theory topology topos topos-theory tqft 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 20th 2009

    Copied over from 'latest changes':

    I'm hesitant to weigh in on this as I'm as guilty as everyone else, but merely flagging something here is not really enough. We should all think about how to organise the material here to make it easily findable. Of course, linking from related page to related page is good, but there should also be some hierarchical organisation. For example, there should be a philosophy index page and foundations and philosophy should be on it. Perhaps, appropriately enough, we should make more use of the category features in Instiki. At the moment, we have the following categories: biography, category, delete, drafts, foundational axiom, lexicon, meta, people, place, redirect, reference, spam.

    Here's a proposal. We should use categories as a way of doing automatic indexing. When you create a page, think where in the index it should appear (which may be in more than one place). Then assign the page the parental categor(y|ies).

    As an example, Frolicher spaces are a form of generalised smooth space. So in Frolicher spaces I assign the category 'generalised smooth space'. I do this in the 'hidden' way:

    :category generalised smooth space
    

    It's also relevant to differential topology, but I don't assign it that category because the 'generalised smooth space' page is already assigned the category 'differential topology'.

    Then at the bottom of 'generalised smooth space' we assign it to its own category in the 'unhidden' way, thus generating a list of all things in that category (it may be that this list is not formatted in a pretty way, but we can modify that). This list is automatic so we don't have to keep going up the tree to add new stuff.

    It's important to only assign the lowermost categories, so that the pages appear in their correct places and not at every stage up the tree.

    How does this sound?

    • CommentRowNumber2.
    • CommentAuthorUrs
    • CommentTimeAug 20th 2009
    This comment is invalid XML; displaying source. <p>I had thought about that, too. We should have done this (assign lots of categories to organize the material) from the beginning.</p> <p>Here is a question: what's that thing about the "hidden way" and the ordinary way. I don't know about that.</p> <p>Here is a remark, concerning</p> <p><blocvkquote></p> <p>It's important to only assign the lowermost categories, so that the pages appear in their correct places and not at every stage up the tree.</p> <p></blockquote></p> <p>That hierarchical bit sounds difficult to me. We need a system that is robust and easy to handle. We don't want to have to give newbies a course on how to assign categories on the nLab. It's already difficult enough to teach people to log their changes. Just imagine the effort needed to teach them how to adhere to some categorization system.</p> <p>So I'd think we should just add to each entry a list of category names that includes all the topics and sub-topics that this entry.</p> <p>Or maybe not. Maybe the hidden vs unhidden thing is meant to deal with this kind of problem?</p>
    • CommentRowNumber3.
    • CommentAuthorAndrew Stacey
    • CommentTimeAug 20th 2009

    Hidden, unhidden just controls whether a list of the things in that category appears on that page. So if I put category: idiots on my page then I register as an idiot and I get a list of all the other idiots at that point on my page. If I put :category: idiots then I register as an idiot but I don't generate the list of all the others.

    My point about the hierarchical bit is that I propose to use these as a 'table of contents' rather than an 'index'. For the kind of use that I'm envisaging then this is the more useful model. In a 'table of contents' then I have chapters, sections, subsections, and so forth. So I can easily step through the tree to find what I want, even if I don't quite know what I want already. Each level is not polluted by all the junk from the levels below. We already have a manual version of this starting with the 'contents' sidebar. What I'm proposing is a way to make this more automatic.

    I suspect that we do need to give newbies a course on how to assign categories on the nLab since no-one currently does it. I don't think that one system is inherently easier than the other. Either I have to think of the best categories (and it may be plural) to put a page in or I have to think of all of them. Neither is automatic, both take thought, and thus both fail the "keep it so simple a mathematician could do it" principle. But on the other hand, a system whereby people assign whatever categories they like has neither virtue and will lead to a useless system.

    I understand your reluctance to add more rules and regulations and I broadly agree with it. But I don't think that this should prevent us having best practices that we encourage (mainly by doing it ourselves). I think that clarity is the main thing to aim for in encouraging people to join in rather than absolute simplicity.

    And of course, any system is going to involve cleaning up work for the Lab Elves as inevitably things will not work out quite right. But that's a given, I'm afraid.

    (Incidentally, do I use emphasised text too much?)

    • CommentRowNumber4.
    • CommentAuthorUrs
    • CommentTimeAug 20th 2009

    Right, that makes sense. So then we should create a page, for reference purpose, that lists the existing categories in their hierachical structure, and into which any newly created categories are inserted.

    So then, when I create a new page, I will go to that page and see where my content fits. If it doesn't, I'll create a new category and insert it into the list.

    We may still have to beware that sometimes math is circular. There is not always a single hierarchy. From some points of view some subjects are subcases of other subjects, from another point its the other way round.

    That's particularly an issue close to the root of all being. I had this trouble when I created the side bar: what is now more fundamental: foundations? or category theory? or topos theory?

    • CommentRowNumber5.
    • CommentAuthorAndrew Stacey
    • CommentTimeAug 20th 2009

    Right, that makes sense. So then we should create a page, for reference purpose, that lists the existing categories in their hierachical structure, and into which any newly created categories are inserted.

    That's just about it. By using the categories carefully then this actually gets done fairly automatically. What we do is that for each category we create a main page for that category which contains the list for all that is in that category, and which could contain other information as well, and which is itself assigned the categor(y|ies) one level up. Then all the linking and hierarchy is done automatically.

    So then, when I create a new page, I will go to that page and see where my content fits. If it doesn't, I'll create a new category and insert it into the list.

    Yes, and if you create a new category then someone - you or a Lab Elf - should create the main page for that category.

    We may still have to beware that sometimes math is circular. There is not always a single hierarchy. From some points of view some subjects are subcases of other subjects, from another point its the other way round.

    I think that this will be okay. After all, there's no reason why the directed graph of categories has to be a tree.

    Part of the point is the focus. The point of these categories should be to make navigation easier rather than to try to perfectly classify the mathematical content. Since the latter is actually impossible, having that as part of the goal will just create unresolvable conflicts. If the primary and overriding goal is to make it easier for people to find stuff, then I think it will work.

    • CommentRowNumber6.
    • CommentAuthorUrs
    • CommentTimeAug 20th 2009

    Sounds good.

    • CommentRowNumber7.
    • CommentAuthorTobyBartels
    • CommentTimeAug 20th 2009

    I don't believe in the hierarchical classification of knowledge; fortunately, that seems to be gone by comment (5) above.

    Right now, we've got a lot of pages whose purpose is, at least in part, to list articles pertaining to some topic. For some of these pages, the ones with contents of books, these are pretty coherent lists that make sense as they are and don't need to be coordinated with the rest of the Lab as it grows. But for other pages, like category theory, geometry, and the list that I started at constructive mathematics, these rapidly get out of date as the Lab grows and ultimately become useless. I see this suggestion as a potential solution to that problem; when you need to add a page to the geometry list, you simply put category: geometry at the bottom, rather than going over geometry to add it there.

    I don't think that we should hide the categories. If we're going to do this, then it's best to make it visible, and the categories won't be distracting down at the bottom. Of course, we should make the link to the category: geometry link more prominent on geometry itself, but that's easy to do.

    I've also been thinking lately that we need to consolidate some of the present categories, which will only help if we start having more contentful categories. I think that the distinction between category: biography and category: people (whether the person is a contributor or not) is unimportant; and in the end, we'd like everybody to contribute, so why enforce the distinction? (We have Contributors and the author list if we want them.) I would also get rid of the distinction between category: redirect and category: delete (which is whether there is content in the history or not), and indeed get rid of the categories themselves, since they are now identified by -- history in the page title.

    At the very least, we could start adding category: physics and category: philosophy to pages now; those are very straightforward to do and also useful.

    • CommentRowNumber8.
    • CommentAuthorAndrew Stacey
    • CommentTimeAug 21st 2009

    I don't believe in the hierarchical classification of knowledge; fortunately, that seems to be gone by comment (5) above.

    It was never intended to be there.

    I don't think that we should hide the categories. If we're going to do this, then it's best to make it visible, and the categories won't be distracting down at the bottom. Of course, we should make the link to the category: geometry link more prominent on geometry itself, but that's easy to do.

    I should experiment before I say anything, but I think that the difference between hidden and unhidden is not whether the category name is visible or not but whether all the other pages in that category are visible or not. I think that having all the links on every page in the category clutters up the view and only saves one click (click on the category name, then click on the page rather than directly on the page).

    Actually, let me go and experiment now ...

    Ah, no, I misunderstood. You're right.

    Hmm. That actually puts paid to one idea I had which was that the index page for a category could have some actual content itself. So you'd have a "basic idea" section and then a nicely formatted list of pages. Though I guess that would not be in a sensible order. It's probably not possible to "include" the category list from an ordinary page.

    Looking at, for example (http://ncatlab.org/nlab/list/meta) I can see some other changes I'd want. I wouldn't want the list of "wanted pages" - that's not useful for navigation.

    I still think it's a piece of the structure that we're not using to its full potential.

    • CommentRowNumber9.
    • CommentAuthorTobyBartels
    • CommentTimeAug 21st 2009

    The wanted pages business is buggy too; it includes links to other webs, including to pages that exist on those other webs!

    • CommentRowNumber10.
    • CommentAuthorAndrew Stacey
    • CommentTimeAug 24th 2009

    Having seen what's going on at "Topology", I suspect that the best use of these categories is to make it easier to do "main pages" by hand, rather than a fully automated system as I was proposing. I think that the "Topology" page is much better than a simple alphabetical list could be.

    So I revise my original proposal as follows. Add any suitable categories you can think of to your page. And then those who are interested in developing the structure of the site can use that information as a shortcut to figuring out what should be on those index pages without having to go through the whole database. Of course, we shouldn't just like categories at random, we should try to choose appropriate ones, and those doing the index pages should be smart: "topology" may take links from "differential topology" as well so if I list a page in "differential topology" then I don't need to cross-list in "topology" as well.

    We need to think a bit about design and layout to make it useful for those interested in using the content, rather than putting content in. This feeds back into a few of the other discussions that we've had which haven't fully been resolved.

    • CommentRowNumber11.
    • CommentAuthorUrs
    • CommentTimeSep 1st 2009

    That sounds good. Does this revised suggestion now have a majority among, er, the three of us?

    If so, I think I will start adding lists of "categories" labels to entries that I edit.

    I would sugest among us (those that follow such things) we should stick to this practice for a while, and once we have some experience and see that it makes sense and is working, we should create a page that explains the proceudure and the conventions and asks people to follow.