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.
    • CommentAuthorMike Shulman
    • CommentTimeJan 9th 2011

    A friend pointed out that it would be nice, when an nJournal “paper” consists of more than one wiki page, if links “within” the paper were colored differently to links “leaving” the paper. I agree that this would be nice, but the only way I can think of to implement it with current technology would be for each published paper to be on its own instiki web.

    On reflection, such a system would have other advantages, such as no worries about conflicts of page names between different papers or a need to impose naming conventions. And then when an author is revising a paper based on referee reports, they could simply be given the password to the web of their paper to do the revisions themselves, and then the password be changed when the final version is decided on. It might seem a little silly to have a bunch of webs that only have a few pages in them, but I don’t see why it would be a problem, as long as Instiki would scale okay with lots of webs (eventually, perhaps, hundreds — do we know anything about that?).

    Just a thought; any reactions?

    • CommentRowNumber2.
    • CommentAuthorTobyBartels
    • CommentTimeJan 11th 2011

    I’m inclined to agree. It would make the list of all webs a bit less useful, but most people don’t use that anyway. (We have directory of personal webs (nlabmeta) for that.) The annals web that Urs made would still be used, with general information and tables of contents.

    So assuming that multiple webs will scale (check with Jacques for an opinion?), let’s do this.

    • CommentRowNumber3.
    • CommentAuthorUrs
    • CommentTimeJan 11th 2011

    Maybe we can make it optional: a separate web for genuine stand-alone articles, but a place on the main nnJournal web for contributions that work as genuine nnLab entries. We said we want to allow submission for peer review of single small nnLab entries (such as geometric realization of simplicial topological spaces) and we hardly want to create a separate web for such an entry.

    I see that the name “Journal” is gradually pushing the project idea away from my original idea. I really think the best form of knowledge base is a wiki and just wanted to add peer-review to that: mark some versions of some pages as stable and peer-reviewed. I am thinking of each page as still being part of the main web. I think the more interconnected things are, the more useful they are.

    I would even think that if we have a submission whose page names are going to overlap with existing page names then there is some rationale in making the author think about how to merge the material into the existing web, instead of just creating a new parallel web and put the new material there. If that’s unavoidable, then we should certainly allow for it, but more enjoyable I’d find the idea that instead of having many parallel webs each on the same topic we try to have one authorative article on the topic which gradually approaches perfection.

    • CommentRowNumber4.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 11th 2011

    I’m not too keen on having such a proliferation of webs. I feel that it would separate the articles too much; I’m with Urs on this in that I would like to be able to “promote” pages from the nLab, even just theorems, to the nJournal and I think it does destroy the cohesion to put each in a separate web. In particular, where in the past one might have said, “We recall from X the theorem …”, now we’d like to just link to it.

    Regarding the styling of links, that is possible. What isn’t straightforward is to make it completely automatic, but again that could be something that is part of the package, so to speak. An easy way to do it is to write ones internal links like this: *[[Introduction]]*{: .local}. Then we have a CSS class, local, which changes the CSS appropriately.

    I wonder if it is possible to change the CSS depending on the category of the page. It probably isn’t right now, but it might be a reasonable feature request to ask that the categories that a page belongs to be put into the CSS. It wouldn’t add anything to the load, and wouldn’t change things retrospectively, then we could make each article (or whatever) its own category and use CSS somehow with that.

    • CommentRowNumber5.
    • CommentAuthorMike Shulman
    • CommentTimeJan 11th 2011

    we try to have one authorative article on the topic which gradually approaches perfection.

    The problem I have with this is that “perfection” is not uniquely defined. Peer-reviewing nLab articles is great, but I thought we were now explicitly talking about something that could also be more journal-like— and that we meant to do that, rather than being pushed into it unawares by the name “Journal” as you seem to imply. Interconnectedness is great, and wikis are great, but many people (myself included) also like to write articles where we completely control the content and exposition—but it would be great if such articles could also be interlinked with other articles and with wiki pages. Tom expressed something of this feeling regarding his article as well. I think there is room for many different “perfect” expositions of a given concept.

    • CommentRowNumber6.
    • CommentAuthorzskoda
    • CommentTimeJan 11th 2011
    • (edited Jan 11th 2011)

    Where is the initial idea of voluntarily and self-initiating approving and labeling by software certain theorems and alike as partly certified lost ? This is I think about the best review mode for the most of the regular lab pages. And this is lots of work, hundreds of items. Massive and perpetual. Just adding one more function and related software to the current mode of nLab. Remotely similar to wikipedia system marking of quality level. One should not expect external editors to help in such low level issues, which I consider separate function from the nJournal idea. nJournal I suppose is expected to have certified-by-the-editors/appointed reviewers. That is why one needs editors. On the other hand, the work on nLab and on self-initiated review of that kind should rely and welcome comments on quality from anyone (unless some spammer and alike outlaws).

    • CommentRowNumber7.
    • CommentAuthorUrs
    • CommentTimeJan 12th 2011
    • (edited Jan 12th 2011)

    Mike,

    I agree, that of course some articles are best developed by a single author. But that seems to be more an argument for a personal web for that author than for a separate web for the article in the nnJournal: because nobody is allowed to edit any material that is part of the nnJournal (except ediitorial board and staff) anyway.

    But I am not dogmatic about it, if there is consensus that some article needs a separate web, then so be it. Maybe this is mostly a problem of our restricted software functionality: ideally we’d have more flexible ways to group wiki articles.

    Generally, I think we may be running into some problems with the nnJournal running on somewhat shaky software. For instance with any submission of usual article length, we will run into the problem that there is this huge delay in saving and displaying the pages. I am fighting with this on all nnLab pages where I am trying to author article-style material. Now the entry on cohesive \infty-toposes seems to have crossed some magical length boudary and editing it becomes a bit painful.

    Back to the general idea of wiki’s versus articles: let me give some examples, so that you can see what I am after:

    suppose somebody got the idea (which might be a very good idea) to submit The Stacks Project to the nnJournal at some point. Practicality of transporting the code aside, there seem to be two options: a) create a separete web for it and put all the content there or b) take each suitable subsection of the big Stacks-Project pdf and merge it into the corresponding nLab entry. Say merge the section on algebraic stacks into algebraic stack etc. Then submit each of the resulting small entries seperately.

    I think clearly the second option would yield a result that would be considerably more worthwhile than the first. I would like to encourage this attitude “we all build together on the one edifice of math” more than encourage authors to archive their articles in just the traditional style.

    • CommentRowNumber8.
    • CommentAuthorTobyBartels
    • CommentTimeJan 12th 2011

    I agree with the beginning of Urs #3: sometimes we’ll have articles that are complete expositions of material, ideally linking to stuff in the nnLab (and maybe to other articles of this sort in the nnJournal), but still separate unto itself (and possibly broken into several pages whose names naturally repeat names of pages from the Lab). But sometimes we’ll promote an nnLab article (especially one with a new definition, theorem, or proof). In the former case, a separate web (unless somehow we can do it all with categories) would be useful; in the latter case, it would be pointless. (Sometimes it may be hard to decide which is which, but usually it should be clear if we have a complete submission from one author or an existing page with several authors that is brought to the editors’ attention.)

    • CommentRowNumber9.
    • CommentAuthorUrs
    • CommentTimeJan 12th 2011

    There was also the idea that submissions are at least encourged (if not enforced) to be put on the nnLab proper. Whatever we do about sepafrate webs, we have to dealwith naming conventions anyway.

    I had decided to title the pag that is going to contain Tom’s article “Leinster2010” and not “Introduction to topos theory” in order to keep the name spaces clear. I’d think we could do this systematically for all submissions.

    • CommentRowNumber10.
    • CommentAuthorTobyBartels
    • CommentTimeJan 12th 2011

    But do we really want the entire article on one page? It’s a slow page already, and that’s with most of the article still unconverted to wiki markup (so with few links and CSS environments and less MathML). Many articles will be much longer. That’s the reason for breaking things up into several pages, which would make a separate web handy.

    • CommentRowNumber11.
    • CommentAuthorUrs
    • CommentTimeJan 12th 2011

    Right, it need not and probably should not be all on one page. We should try to get going with processing Tom’s article so that we have a chance to experiment precisely with these questions.

    Many things will probably work. In that sense, the most important question probably still is the one Mike alluded to: does the wiki-software scale well with a multitude of separate webs?

    (I am afraid, though, the answer will be: nobody knows and nobody has checked before).

    • CommentRowNumber12.
    • CommentAuthorTom Leinster
    • CommentTimeJan 12th 2011

    Almost all papers are divided into sections, so the default position could be to have one lab page per section. In my case that would be 4–8 standard Latex pages per lab page.

    On the downside, the more an article is split up, the more laborious printing becomes. (I know, it's meant to be designed primarily as a website; but if an article's good then some readers will inevitably want a printout.)

    • CommentRowNumber13.
    • CommentAuthorAndrew Stacey
    • CommentTimeJan 12th 2011

    Actually, we can have a page that includes all the subpages as sections for printing. So for normal use, one uses the “divided” pages, but then to print one goes to the “all in one” page.

    • CommentRowNumber14.
    • CommentAuthorTom Leinster
    • CommentTimeJan 12th 2011

    Great: best of both worlds.

    • CommentRowNumber15.
    • CommentAuthorMike Shulman
    • CommentTimeJan 12th 2011

    Great. I agree that refereed “single pages” from the nLab make sense to have all on one web. But personal webs (re #7) don’t quite answer the same question, since they are not refereed.

    I presume you’re not suggesting that Tom’s article should be merged into the existing pages topos theory etc., even though it does exist on the main nLab? It’s true that naming conventions will still be an issue; any thoughts about how to name such pages when they are split up into sections? [[Leinster2010 - section 1]]?

    • CommentRowNumber16.
    • CommentAuthorUrs
    • CommentTimeJan 12th 2011

    I presume you’re not suggesting that Tom’s article should be merged

    Not the reviewed version on the nnJournal. But I keep hoping that parts of it will find their way into the expositional parts of nnLab entries on topos theory.