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.
1 to 41 of 41
The nlab could greatly profit from including more junior researchers, for instance from the HoTT community. I’ve explained to some of them how the nlab works (nlab,nforum,ncafe), and what a great resource it is.
Are there things we can do better, or should we just explain these things in person to people?
We’ve been wondering for years how we can get more people involved in the nLab. I don’t think we’ve ever come up with any workable ideas. Have you got any?
One workable idea would be to make nLab understand some standard LaTeX commands, which everybody knows already. The current Instiki syntax is highly discouraging. For instance, it would be nice if \section{…} \subsection{…} \ref{…} \cite{…} \bibitem{…} \label{…} worked as expected.
Interesting! I don’t think I’ve ever heard that feedback before. Instiki’s Markdown syntax is, of course, supposed to be easy to write (and I find it so — certainly much easier than Wikipedia syntax, and Wikipedia manages to get lots of people to contribute). But I suppose it makes sense that mathematicians who are already used to LaTeX would find it an extra hurdle to get used to. (You are, I presume, basing this on actual data of mathematician(s) — you or others — who found it a hurdle?)
\ref does, I believe, already work, as does \label for equations. I would hope it ought to be easy to make \label{Name} an alias for the current {#Name} that works for theorems and list items, and to make \cite{Name} an alias for the current [Name](#Name) (though the latter would require making sure that the label names coincide with the desired reference names).
I’m not familiar with the syntax of \bibitem, what would you want it to correspond to? Would you want \begin{itemize} and \item to work instead of bulleted lists *, and similarly for enumerated ones?
For sections, I guess \section should be an alias to ##, since that’s our standard practice for headers, and similarly \subsection should be ### and so on down. Should something alias to #, like \title? (That would be a bit of a departure from LaTeX, since \title is a preamble command that doesn’t actually produce the title, but maybe people could deal with that.) While we’re at it, we could make \tableofcontents an alias for the current rather baroque syntax for tables of contents, and similarly \begin{theorem} and so on could alias to the current theorem syntax (which even I sometimes have trouble remembering!).
I am a little worried about having two different syntaxes coexisting, especially (as will inevitably happen) on the same page. Not sure if there is a good solution to that.
I’ve explained to some of them how the nlab works (nlab,nforum,ncafe), and what a great resource it is.
I think there are indeed many people who appreciate it. We could try to collect citations to it. I recently for instance saw the nLab cited in some notes of Sophie Morel, here.
We’ve been wondering for years how we can get more people involved in the nLab. I don’t think we’ve ever come up with any workable ideas. Have you got any?
One way may simply be to encourage contributions from those around one. For example, if one has students, one can ask them to write up details of something on the nLab.
We could also try to reach out into the community to ask for help with certain pages. In the end, this may lead to involvement, at least on the nForum. I am currently making some effort to do this with the Initial Θ-data page, and with my knot theory post here.
I am not convinced that the technological deficiencies of the nLab are a primary reason for people’s lack of involvement, I suspect more that they do not see an entry point (e.g. they may not realise that they can contribute material that does not have an explicitly higher categorical perspective), or do not have the time, or do not see any benefit in it for them. But of course it is good to improve the technological aspects as well.
How about the idea of removing the general necessity to create an account for participation in nForum discussion?
I imagine there must be loads of people who had the whim to drop a qick comment here, and thus possibly get involved, but who then didn’t feel it worth the trouble to formally sign up with the nForum software..
In Augsburg, all the Master students of the relevant subjects know and love the nLab, and they are encouraged to incorporate their observations and results in the nLab. I think spreading the word and encouraging students in this way is one of the most effective methods we can employ!
Urs #6, that might be! It’s already very good that one can change the nLab without creating an account. I hold this fact in very high regard; nobody would correct typos or small mistakes if they’d have to create an account first.
they are encouraged to incorporate their observations and results in the nLab.
Does this encouragement result in their actually doing so? (-:
If I had graduate students, I’d definitely encourage them to edit on the nLab. I might even make it an assignment. But I don’t…
How about the idea of removing the general necessity to create an account for participation in nForum discussion?
I’d be fine with that, although it would be nice if they could enter their name somewhere on the posting page so that the comment doesn’t just show up as “Guest”, the same way edits on the nLab itself are “signed” without creating an account.
You are, I presume, basing this on actual data of mathematician(s) — you or others — who found it a hurdle?
Yes, including myself.
Consider the current syntax for numbered definitions:
+-- {: .num_defn}
###### Definition
How one could possibly remember this?
Compare this with LaTeX or Plain TeX:
\begin{definition} …
or
\proclaim Definition. …
Consider the current syntax for numbered definitions:
+-- {: .num_defn}
###### DefinitionHow one could possibly remember this?
That’s absolutely right. I always copy-and-paste that from somewhere, never type it by hand.
I agree that the syntax for these things here is really bad. All the more as it flies in the face of the very idea, even the definition, of a wiki, which is supposed to have simple markup language.
It would take some work, though, to change this now, wouldn’t it. But maybe you or somebody could lend Richard a hand?
I think it will be quite easy to modify the existing Instiki parser to output whatever new syntax we agree upon, then transition the entire nLab to the new syntax. I can certainly do this part.
The other question is what parser we should use for the new syntax, i.e., try to modify the existing Instiki parser, or just use something entirely different.
Might it be possible to keep the existing syntax, for compatibility, and simply add “synonyms”. I.e have it such that typing both
\tableofcontents
as well as
#Contents#
* table of contents
{:toc}
have precisely the same effect?
Re #10: Are there people who actually code their bibliographies manually instead of using bibtex? (-:
Re: #11, the standard nLab convention is that # is the page title (nicely formatted, sometime pluralized — or sometimes just the word “Contents”) and only occurs once at the top of the page. So I don’t think it should correspond to \chapter, since that would suggest that it could occur more than once.
I would like to keep the existing syntax as well, if we can. Most of it I do find simple and easy to type and remember, e.g. *italics*, numbered and unnumbered lists, [[links]], etc., especially since Markdown is a sort of a standard for wikis and blogs elsewhere on the internet. For me, it’s only the extensions to the standard Markdown wiki syntax, like theorems, drop-down sidebars, and tables of contents, that are baroque and hard to remember. Is that also the case for you?
resolve many of our problems with renaming and merging pages
What problems are you referring to, and how would this solve them? I think our current system of redirects works pretty well.
Re #10: Are there people who actually code their bibliographies manually instead of using bibtex? (-:
Is BibTeX available on the nLab? I don’t think so. BibTeX, to be honest, is a pain to work with: you cannot change the bibliographic labels inside […], for example.
This leaves us with the second most common option: \bibitem.
The current nLab references, in fact, a formatted like \bibitem, not like BibTeX.
Re: #11, the standard nLab convention is that # is the page title (nicely formatted, sometime pluralized — or sometimes just the word “Contents”) and only occurs once at the top of the page. So I don’t think it should correspond to \chapter, since that would suggest that it could occur more than once.
I see. I was actually referring to the title that one sees in the URL bar. I guess these two titles can be different.
I would like to keep the existing syntax as well, if we can. Most of it I do find simple and easy to type and remember, e.g. italics, numbered and unnumbered lists, links, etc., especially since Markdown is a sort of a standard for wikis and blogs elsewhere on the internet. For me, it’s only the extensions to the standard Markdown wiki syntax, like theorems, drop-down sidebars, and tables of contents, that are baroque and hard to remember. Is that also the case for you?
Yes, it is the Instiki extensions to Markdown that are truly terrible. I have no objections to the current syntax for italics, lists, and links.
What problems are you referring to, and how would this solve them? I think our current system of redirects works pretty well.
For instance, there are many pages with ’> history’ in the title, which I believe result from an inability to properly merge pages.
Re #22: I don’t even know what it would mean to “merge” pages. Would the history list become a branching tree? No version control system that I know of has a way to “merge two files” other than by simply copying content from one of them into the other one and then deleting the first, which is basically what we are doing (the “> history” pages could be actually deleted, but we don’t usually get around to it; functionally they are as good as deleted since they are not linked from anywhere else). In any case, I don’t see any relation between such a thing and whether the page title is recorded in the text or in the instiki database; in either case there are two distinct “pages” (however they are identified) that are getting combined somehow.
The current nLab references, in fact, a formatted like \bibitem, not like BibTeX.
Yes… and that’s annoying. (-:
BibTeX (by which I mean to include variants like biblatex/biber/natbib/etc.) deals automatically with including all the information in the “correct” citation order and format, and if you switch formats it automatically adapts. You can choose different citation styles like plain, alpha, or in-text, or even write your own if you care a lot. Moreover, the data in a BibTeX file (unlike a \bibitem or nLab reference list) is stored semantically, so that a computer can parse it and then, say, filter for all papers written by John Q. Mathematician or all papers published in the Journal of Histrionics. If nLab references were similarly semantic, then we could connect citations to the same paper across multiple pages; something like this was discussed here and put on the todo list.
This is turning into a fruitful discussion.
I’ll be spending three weeks in Bonn which includes a HoTT conference. I’ll see whether I can give some guidance to people there.
This is turning into a fruitful discussion.
It also very quickly deviated from your actual question!
While “Instiki” is indeed awkward, I’d think this is a problem fully seen only by established users, but is not the reason that prevents newcomers from making their first edits.
I suspect among the real factor is something as mundane as sociological recognition. It is not for nothing that StackExchange treats its users as if they were children on a birthday party, by flooding their egos with imaginary badges for their accomplishments. We see that the sober erudide mathematician on MO is not in fact appalled by being approached on the tacit assumption that this is what will motivate him, no, he will indulge in it and proudly post his imaginary reputation point record on his webpage. After this boost to his limbic system, the editing of an Lab entry, which generates at best a nod from one of the half-dozen regulars active here, just feels like cold turkey.
While “Instiki” is indeed awkward, I’d think this is a problem fully seen only by established users, but is not the reason that prevents newcomers from making their first edits.
Yes, this is my point of view too (see last paragraph of #5).
I suspect among the real factor is something as mundane as sociological recognition.
I do think that being involved in a discussion, having people engage with what one is doing, is very important. Thus I think that the nForum is very important. Unfortunately, the sociology of mathematics (and of course most other fields of research) is such that people are not really very open; it is very difficult to find a place to just post some ideas and get feedback on them, it is not in the culture. People are very judgemental, and often take an ’all or nothing’ way of evaluating a piece of mathematics; it’s either correct or its not. Part of the problem is that it does take time and energy to properly engage with and try to understand a piece of mathematics, especially if it is a bit unfamiliar. We are lucky that within the core focus of the nLab, around category theory and higher category theory, we have people willing to engage with one another. But I struggle when I wish to get feedback on something in knot theory, for instance. If there were someone here who was really into knot theory, I think I would work with 20 times the energy level on such pages.
I suspect most mathematicians, especially senior ones, do not see how editing a wiki (maybe they also are not aware that they can get into a discussion about it at the nForum) helps them in their career. A major addition may feel like it is too much of investment for no return, whereas a minor edit may feel beneath them.
Whereas at MathOverflow (I do not post there myself) there is the obvious possibility of receiving positive feedback from others, and of having questions of one’s own answered.
In addition, as I mentioned in #5, I think some people may struggle to find an entry point; they do not see where they can contribute.
Re #22: I don’t even know what it would mean to “merge” pages. Would the history list become a branching tree?
Yes.
No version control system that I know of has a way to “merge two files” other than by simply copying content from one of them into the other one and then deleting the first, which is basically what we are doing (the “> history” pages could be actually deleted, but we don’t usually get around to it; functionally they are as good as deleted since they are not linked from anywhere else).
git can merge two files while preserving both of their histories. git can also split files while preserving their history.
In any case, I don’t see any relation between such a thing and whether the page title is recorded in the text or in the instiki database; in either case there are two distinct “pages” (however they are identified) that are getting combined somehow.
Currently the title (as seen in the URL) is not recorded anywhere in the file. When two pages are merged, it’s difficult to see what was the URL title of the other page before it was merged.
BibTeX (by which I mean to include variants like biblatex/biber/natbib/etc.)
I see, so you mean the BibTeX file format, not BibTeX.
deals automatically with including all the information in the “correct” citation order and format, and if you switch formats it automatically adapts. You can choose different citation styles like plain, alpha, or in-text, or even write your own if you care a lot. Moreover, the data in a BibTeX file (unlike a \bibitem or nLab reference list) is stored semantically, so that a computer can parse it and then, say, filter for all papers written by John Q. Mathematician or all papers published in the Journal of Histrionics. If nLab references were similarly semantic, then we could connect citations to the same paper across multiple pages; something like this was discussed here and put on the todo list.
BibTeX file format is a pain to use for anything that was not published formally, e.g., arXiv, or just PDF files on the web.
I think a better path would be to create (possibly automatically) nLab pages (maybe with a special prefix) for bibliographic references.
Currently we already create such pages for books, but they could be created for any references. Such a page could contain a journal reference, a link to the journal PDF file, an arXiv link if present, MathSciNet / zbMATH links, etc.
In my papers (such as https://arxiv.org/abs/1602.01515) such links are created automatically: I have scripts (addbib / fetchbib at https://dmitripavlov.org/scripts/) that accept title / author as an input and automatically query all the relevant databases (arXiv, doi, MathSciNet, zbMATH) to produce a merged BibTeX entry with all necessary links.
git can merge two files while preserving both of their histories. git can also split files while preserving their history.
Can you point me to some documentation and explanation of this? Thinking about how git maintains history, I don’t see how it would record this information: each git commit is a snapshot of the entire repository, and the difference between two commits is a diff on all individual files. Of course the history of any file that got deleted and merged into another file will be there in the repository, but I don’t see how you would be able to tell, short of looking at the diffs or commit messages, that the lines added to file A were simultaneously deleted from file B.
When two pages are merged, it’s difficult to see what was the URL title of the other page before it was merged.
I don’t see how maintaining title information in the text of the page would help with that. Are you thinking that there would be text that says in addition to “the title of this page is ___” additional text that says “the title of this page used to be ___” or “this page had page ____ merged into it”? That could also be done in the database, and I think that if we did want to maintain that information, it would probably be better done in the database, since in the text of a page such information could be accidentally (or maliciously) deleted or added by a user rather than necessarily corresponding to the actual history.
I think a better path would be to create (possibly automatically) nLab pages (maybe with a special prefix) for bibliographic references.
Yes, this is indeed what was being suggested at the discussion I linked to. I don’t have any particular attachment to BibTeX format as such, it certainly has its infelicities. But I think some kind of semantic format that can be understood by a computer would be preferable to simple text written by a person as in a bare \bibitem; the former should then be parsed by some program to automatically produce the latter.
While “Instiki” is indeed awkward, I’d think this is a problem fully seen only by established users, but is not the reason that prevents newcomers from making their first edits.
You guys may be missing the fact that we have an actual person here giving us actual data: see #9:
You are, I presume, basing this on actual data of mathematician(s) — you or others — who found it a hurdle?
Yes, including myself.
So however much we might like to think that the awkwardness of syntax is not the problem for newcomers (and I was also surprised to hear this), we have an existential proof here that for at least some newcomers it is a problem. So why not fix it and see whether it helps the situation?
Can you point me to some documentation and explanation of this? Thinking about how git maintains history, I don’t see how it would record this information: each git commit is a snapshot of the entire repository, and the difference between two commits is a diff on all individual files. Of course the history of any file that got deleted and merged into another file will be there in the repository, but I don’t see how you would be able to tell, short of looking at the diffs or commit messages, that the lines added to file A were simultaneously deleted from file B.
This involves a special type of commit, a merge commit (see the git merge manual page), which involves three, not two, snapshots of the entire repository: the two things being merged and whatever they were merged into. git allows you to follow either branch in the history of a merge commit.
So to merge two files A and B while preserving both histories, you can create a new branch, move B to A in this branch, while in the main branch concatenate A and B, then merge the new branch into the main branch, resolving the resulting merge conflict by choosing the concatenated version.
Likewise, to split a file A while preserving its history, create two new branches, move A to B in the first branch, move A to C in the second branch, then merge the two branches into the main branch, resolving the resulting merge conflict by keeping both B and C.
Concerning the Instiki / iTeX syntax, I have expository passages in my papers that I would happily transplant onto the nLab if I didn’t have to rewrite all formatting commands, in particular, resolve the numerous differences between iTeX and TeX.
So however much we might like to think that the awkwardness of syntax is not the problem for newcomers (and I was also surprised to hear this), we have an existential proof here that for at least some newcomers it is a problem. So why not fix it and see whether it helps the situation?
Absolutely, I’m all for improving the technology. Just not convinced that it is a fundamental reason that it is difficult to get others involved, even if it might put off some. But who knows!
Concerning the other reasons for (non)involvement: we could replicate the MathOverflow model, since it’s so successful: introduce reputation and badges, upvotes and downvotes on individual edits, etc.
we could replicate the MathOverflow model, since it’s so successful: introduce reputation and badges, upvotes and downvotes on individual edits, etc.
I’m not sure whether that was a serious suggestion, but just in case it was: I don’t think that would be possible nor a good idea.
I have expository passages in my papers that I would happily transplant onto the nLab if I didn’t have to rewrite all formatting commands, in particular, resolve the numerous differences between iTeX and TeX.
FWIW, Andrew Stacey once wrote a script that essentially “compiles LaTeX to iTeX” (with numerous caveats); though I haven’t tried it myself. The source is here.
I don’t think there are many differences between iTeX and TeX in terms of actual formatting of math; the main ones are that iTeX requires spaces between distinct identifiers, and doesn’t support some of the more exotic symbols. The bigger problem for me in terms of copying text from TeX papers to the nLab is that iTeX doesn’t permit local macro definitions.
The bigger problem for me in terms of copying text from TeX papers to the nLab is that iTeX doesn’t permit local macro definitions.
I would have thought that Tex would have the ability to ’unroll’ the macros, i.e. one could produce a tex file with all the macros expanded. If that is the case, we could simply have tex running on the server and carry out this unrolling.
Alternatively, simple macro functionality would not be too difficult to add. I agree though that improving the syntax for theorem environments is a must first. It should indeed be quite easy to add a new syntax; but I agree with Urs that we should keep both for a while, and just gradually move the old functionality over to the new. it is too risky in my opinion to try to convert everything (see the issues we have had with unicode when this has been done).
There’s a well-known python script (de-macro) for doing this, see here.
One useful chore might be to write a pandoc filter for conversion into Instiki-flavored Markdown.
The nlab could greatly profit from including more junior researchers, for instance from the HoTT community. I’ve explained to some of them how the nlab works (nlab,nforum,ncafe), and what a great resource it is.
Lots of people know of Lab and use Lab on daily basis, but do not find attractive to write there for time reasons, for publicity perfectionism pressure or for learning curve for markup. So one should address the latter point (why to be more than just a user).
I myself do not consider ncafe part of the system anymore, it is just a separate site which historically had influence on birth of Lab and where some Labers still have interesting posts.
1 to 41 of 41