nLab
General Discussion

General Discussion

Below we used to discuss general issues concerning the $n$ Lab. But it seems that we found a consensus that discussion (as opposed to incremental work on entries) is best hosted at the blog, not the wiki. So now you are encouraged to post any messages concerning the $n$ Lab community to:

the blog entry nLab – General Discussion, or
the n-Forum

This probably means that you should not edit this page here any further. If you want to follow up on a discussion that started below, consider summarizing the state of the discussion at the above blog entry and then post your contribution there.

Embedding questions about unclear text via abbreviation tags?

Bruce Bartlett says: Take a look at what I did at integration over supermanifolds. I’m using the hovertext feature to embed a question over the phrase “since odd graded differential 1-forms, being of total even degree, do not have a top exterior power”… if your mouse lingers over this. Maybe this is an idea?

Urs Schreiber says: That’s a great idea! I have replied to your question in that entry now (check it out!) which means that the mouse-over effect is currently no longer visible (it still is present in the source code there, so everybody can check how this works: where did you leanr about this feature??), but let’s consider sticking to that kind of inserting questions.

Slash lab entries?

Bruce Bartlett says: I have the vague idea that mathematical entries (like integration over supermanifolds should have a “/lab” section where “lab” things get done, like a tutorial class. I don’t know what that means.

Urs Schreiber say: I don’t know either! We are likely to have entries of very different nature, some of them just reviewing very standard stuff, some summarizing less well-known stuff, and in some areas we may want to think about new stuff, even. I think as long as every single page makes clear where the information presented there comes from, everything is okay.

Single-Author Areas

Instiki can run multiple Wikis (“Webs” in the Instiki Parlance). Urs, John and David have the password required to create additional Webs.

Webs can be password-protected, so that only those in posession of the password can edit them.
A password-protected Web can be “published” so that others can read, but not edit, the contents. (Or, of course, they can remain unpublished, so that the authors can carry out their super sekrit machinations in private).

These two features provide the possibility for single-author areas, where one person (or persons: whoever has the requisite password) is in authorial control.

Here is John's area.

Importing CSS

I propose that, at least in these early days of the $n$ Lab, that the CSS style sheet be tweakable by everyone. I propose the following mechanism to do this.

Here is a publically editable CSS file: general.css. I want the stuff in here to piggyback onto the existing CSS declarations in instiki.css (as can be found by clicking on “Edit Web” on the main page).

Basically, one just needs to add the following line to the beginning of that file:

@import url('/nlab/files/general.css');

Not a chance. That would be a completely unacceptable security risk.

That way everyone is free to make some tweaks. The point is that Markdown has a nice CSS trick, which Jacques used to create the Theorem environments. The idea is that if one types eg.

+-- {: my_gismo}
Some text here.
=--

then one gets a div element whose class is “my_gismo”. So in the CSS file general.css, we can style this block anyway we want.

If that’s all you want to do, you don’t need access to the site’s CSS file. You can use a combination of Maruku’s metadata format and the style attribute to style your responses. (See the Markdown source of this page, to see how it’s done.) Inline styles are sanitized for your protection.

I see that you’ve already noticed the existence of Maruku’s metatdata format, though your example is slightly incorrect.

For instance, I created a “query” block, which I’m using to ask questions on Urs’s pages (beware I will use it on yours soon dear reader!). See integration over supermanifolds. (The query block will only display as green once that adjustment I suggested is made to the instiki.css file by someone with a password by clicking on Edit Web and then Stylesheet tweaks, to change the instiki.css file)

More generally, for changing the overall look-and-feel, it would be nice to introduce theme-support for Instiki, just as we already have theme support for slide shows within Instiki.

Trying to reupload the general.css file: A site-wide CSS file for the nLab. The CSS declarations here are in addition to the standard CSS arising from the instiki.css file. However, everyone is free to change this file. It can be modified simply by uploading it again.

Darn, I was worried it might not work. Darn, that causes problems. This is a silly thing about Instiki — you can’t replace uploaded files with new ones. Jacques? Any suggestions?

An interface for managing uploaded files is another item on the TODO list.

Yes you’re right — thanks. Bruce Bartlett

Formatting of discussions

Urs Schreiber says: We need to do something about this: it is already becoming hard to recognize, read, let alone follow the flow of discussions.

Let’s agree on some kind of basic formatting rules for how to type personal speech here and, in particular, as comments into the other entries. I like Jacques’ way of formatting his comments above. Maybe everybody should choose his or her color and then always insert comments using this kind of formatting with this kind of color.

Jacques says: I hope you don’t mind, but I darkened the colour of your response. Bright green is hard on the eyes, when it occurs in large blocks of running text. Besides, it’s the colour of hyperlinks on this wiki, which is a little confusing.

Bruce Bartlett says: Ok… that’s a bit of a weird system for discussion, but I’m okay to go along with it… However, I’m quite fond of the green “query” block that I put on integration over supermanifolds, as below:

Question: Okay, but what is the differential $d\theta_1$ of an odd co-ordinate function? How are we to think of it geometrically? Does it measure a rate of change of something? (Bruce Bartlett)

Answer: See superdifferential form. (Urs Schreiber)

I think that a lot of people (for instance Simon) maybe aren’t that keen on writing stuff for the $n$ Lab right at this moment, but certainly have a lot of questions about Urs’s stuff. I see this query feature as a way for them to get involved. Place query blocks all over Urs’s text :-) (sorry Urs!)

I see these query blocks as staying on the page for a while (even after they are answered by Urs or someone else), because it makes people feel better when they see that they are not the only ones who didn’t understand the material. At some point they can be taken down on any given page.

However, I would really like it if some of this CSS code would go directly into instiki.css, instead of us having to reproduce it on each page. That is not a workable solution.

Thus I propose the following: if anyone has some CSS code that they would like to promote, email it to someone with a password (Urs, John, David, Jacques) and ask them to put it in via the “Edit Web” button.

Jacques said: I agree. Once people have settled on a particular styling convention for content, it should go in the “Stylesheet Quirks” section of the “Edit Web” page, where it will automatically be reproduced on every page of this Web. Technically, that’s not the instiki.css file. The latter is common to all instiki installations.

My point was that experimentation on this front does not require access to the site-wide stylesheet, since Instiki provides a convenient way to specify inline styles on a per-page, or per-element basis (as demonstrated here).

Please settle on something that everyone likes and the (and only then) add it to the Site-wide “Stylesheet Tweaks”.

I’m quite fond of messing around with colours, etc. and without this feature I feel a bit deflated :-)

For instance, I think it would be great to use CSS so as to style downloadable documents correctly, as explained here. The idea is that every pdf link will have a tiny pdf icon next to it, and more importantly every n-category cafe link will have a tiny n-category cafe logo next to it; the same for arXiv links, etc.

Another thing I’d like to try in CSS is to set Georga (a serif font) as the main text (and math) font for the $n$ Lab. Try it for a few days and see.

Urs says: Bruce, I like the look of those query boxes. Graphical sophistication like that greatly improves the look-and-feel of the wiki.

You should explain at some promint point of the wiki, probably at the HowTo page what people need to do to insert such gadgets.

Concerning contributions by others: let’s see how it develops. I’d really enjoy having several people contributing here, eventually. But on the other hand it is also maybe good if we as the hosts have a bit of time to produce some context here first.

I am hoping that eventually I will produce enough nonsense here that others can’t stand it anymore and jump in to help out ;-)

Seriously, if it turns out that a few of us produce most of the content but many others contribute many little improvements, like correcting small mistakes, adding references, asking for clarifications or voicing other requests, establishing cross-links, etc., I’d already be happy.

Toby Bartels is currently doing this already, which is great.

Bruce says: Okay. Yes I agree with you about the content; for a while the site will be dominated by you putting up your stuff on $L_\infty$ integration, etc. But that’s great, that serves a very valuable purpose. It creates a central repository of expository stuff (note expository… it musn’t be written in an encyclopeadic way… that’s important I think). Then when you make a post at the n-category cafe, you can refer to this stuff.

Urs says: I am not sure about that thing about me “dominating” the site. I’ll expect that as soon as John posts his first marvelous exposition things will change rapidly. So far I mainly invested energy to provide pages for all the keywords I just used in this blog post.

For me that’s one of the points of having this wiki here: that we establish a stable resource where we can refer to in entries without having to rehash all old disacussions in every new entry.

And in any case, one point about the wiki as opposed to the blog is also that there is no “title page” which can be dominated, but every reader is free to follow whichever way he prefers through the site, and ignore the content he or she is not interested in.

Concerning expository versus encyclopedic: I want both. In the best of all worlds each page is structured roughly similarly, with a section “basic idea” at the beginning, an expository part in the middle, and a concise and comprehensive list of the main definitions and facts at the end. Or the like.

But, you know. This requires work. And time. We’ll get there.

Bruce says: Ok I’ve uploaded the new stylesheet tweaks. Now if you link to an arXiv, n-category cafe, pdf, or a page inside a pdf file, a little icon will appear, like this:

arXiv link, n-category café link, pdf file, page in pdf file.

If you don’t want that icon to appear (I can imagine a number of reasons why not), there is a temporary workaround: capitalize one of the important letters:

For pdf and page-in-pdf files, capitalize something in “pdf”.
For n-category cafe files, capitalize something in “http://golem.ph.utexas.edu/category”.
For arXiv links, capitalize something in “http://arxiv.org/”.

Also, the query box is now in the stylesheet. If you want to make a query box, just type

+-- {: .query}

_Question_: Why did the chicken cross the road?

=--

in the text and you’ll get out:

Question: Why did the chicken cross the road?

Naming conventions

I talked with Urs about naming conventions here. To be complete, here are the naming conventions that I propose (and which I have, for now, imposed on every page currently in the wiki): * Page titles should be nouns. If you want an adjective that normally modifies the same noun, then use the entire noun phrase. If you want an adjective that applies to many different contexts, then try adding ‘-ness’ to make a noun. If you want a verb, then try adding ‘-ing’ or ‘-ation’ to make a noun (example: categorification. * Page titles should be uncapitalised, except for word words that are always capitalised. (Examples: light mill, but Lie algebra.) * Page titles should be singular, unless the phrase usually occurs in the plural (so effectively a mass noun or a collective noun, rarely if ever referring to individuals). Examples: Lie groupoid, but Lie's three theorems. * Titles should follow standard American English spelling conventions. Examples: internalization (with ‘z’), omega-category (with hyphen as in $\omega$ -category) but BRST complex, Chevalley–Eilenberg algebra (with endash since they are two people) but Burali-Forti paradox (with hyphen since he is one person).

—Toby (who prefers British spelling, but Urs and John use American)

Yes sir! —Bruce

I trust you’re joking, Bruce, but I hope that nobody gets hard-nosed about these conventions, at least not yet. They are just suggestion, good ones I hope, but it’s not too late to change or reject them, and the whole community should be involved in that.

Also, thanks for the comment style. I see now how they’re made!

—Toby

Sorry, I haven’t been keeping up, lots of other stuff on, but just stuck my nose through the door to see how the decorating is going. With regard to these naming conventions I tried to rename the Math page Mathematics to get round the US/UK thing, I now see it has been renamed. Keep up the good work. —Simon

Thanks, Toby, for your efforts! I appreciate it. These naming convention suggestions are good. If and when I do not adhere to them, it is because of me not paying enough attention to what my fingers are doing, which happens. – Urs

Then I guess that I'll correct you whenever you violate the conventions. But as Jacques would point out, the wiki will be less cluttered if the actual creation of new pages always follows the conventions; that's the most important part. —Toby

Another possible naming convention: only ASCII characters. It's possible to put non-ASCII characters in a name (but not ones generated by iTeX or &…; character entities), but this may be difficult, depending on the user. We're already applying this in cases like omega-category (rather than ω-category), but this idea would go further: to overrule the one about following standard spelling when that uses non-ASCII characters (principally dashes). In particular, while the rules above favour Chevalley–Eilenberg algebra (with endash), this proposed change would favour Chevalley-Eilenberg algebra (with hyphen) instead. Personally, I prefer the endash, but I can see that this may just expect too much of the writer.

A very fundamental little issue: should we usually write n-category or $n$ -category? -John

I would say ‘ $n$ -category’. However, that doesn't work in links: ‘$n$-category’, ‘$n$-category’. So for that I write ‘ $n$ -category’. In any case, we should be happy to accept contributions from people that say ‘n-category’; somebody that cares more can always pretty it up afterwards. —Toby

Stylesheet update: removing icons in links

I disabled the icons that used to appear next to pdf files, n-category cafe links, etc., by commenting out that code in the CSS for the nLab under “Edit Web” on the main page.

It’s just a test. I was starting to feel that the little images were a distraction on the page, sort of like the feeling you get when there are too many advertisements on a page. How do people feel, or you in favour of them or not? They can be enabled again by just un-commenting them in the stylesheet tweaks by someone with a password. – Bruce

I liked them. -Urs

Basic Math Entries, Diagrams

I’m glad people are tackling all sorts of fundamental issues in this discussion. I’ve been keeping quiet mainly because I’m really busy, and prefer to spend my little time here creating new entries.

I am very proud to be the first to create the entries for basic words like object, morphism, category, adjunction and so on - it’s like being God and coming up with the first star, the first rock and so on. Other people may think it silly to have entries for such basic ideas, but I’m hoping this website will eventually grow into a complete introduction to $n$ -category theory. If and when I ever start writing my books on higher-dimensional algebra, I’ll do it here, and include lots of link to pages where basic terms are defined. So, I imagine we’re planting seeds that will eventually grow into something quite large.

For this reason, I hope that Todd Trimble joins this project, as he once said he wanted to. I also hope Tom Leinster and Eugenia Cheng and Simon Willerton and Robin Houston and many other folks contribute entries.

I need to figure out a way to lure such people into adding new entries - and improving ones that already exist. I may try some $n$ -Cafe posts that basically say: “Hey, I just wrote a little entry on monoidal categories! Can you help improve it?”

How easy is it to just grab a Wikipedia entry, fix it up a bit, and stick it in here? What are our legal and/or moral obligations if we do that?

See what Wikipedia has to say. —Toby

Here’s another serious issue: how easy or impossible is it to draw diagrams in this environment? Without diagrams, we’re crippled.

-John

Ya mean like this one (from the page on orientals):

\array{\arrayopts{\rowalign{center}} O(\Delta^0) = & \{ 0\} \\ O(\Delta^1) = & \left\{ 0 \to 1\right\} \\ O(\Delta^2) = & \left\{ \array{\begin{svg} <svg xmlns="http://www.w3.org/2000/svg" width="6em" height="4em" viewBox="0 0 60 40"> <defs> <marker id="svg295arrowhead" viewBox="0 0 10 10" refX="0" refY="5" markerUnits="strokeWidth" markerWidth="8" markerHeight="5" orient="auto"> <path fill="#930" d="M 0 0 L 10 5 L 0 10 z"/> </marker> <marker id="svg296arrowhead" viewBox="0 0 10 10" refX="0" refY="5" markerUnits="strokeWidth" markerWidth="4" markerHeight="2.5" orient="auto"> <path fill="#930" d="M 0 0 L 10 5 L 0 10 z"/> </marker> </defs> <g font-size="10"> <foreignObject x="25" y="-2" width="12" height="14"><math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mi>1</mi></math></foreignObject> <foreignObject x="0" y="27" width="12" height="14"><math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mi>0</mi></math></foreignObject> <foreignObject x="50" y="27" width="12" height="14"><math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mi>2</mi></math></foreignObject> </g> <g fill="none" stroke="#930"> <g marker-end="url(#svg295arrowhead)"> <path d="M10,30 23, 15"/> <path d="M35,12 48, 27"/> <path d="M15,37 45, 37"/> </g> <g> <path stroke-width="3" d="M30,15 30,27" marker-end="url(#svg296arrowhead)"/> <path stroke="#FFF" d="M30,15 30,27"/> </g> </g> </svg> \end{svg}} \right\}\\ O(\Delta^3) = & \left\{ \array{\begin{svg} <svg xmlns="http://www.w3.org/2000/svg" width="13em" height="5em" viewBox="0 0 130 50"> <defs> <g id="myRect256"> <g font-size="10"> <foreignObject x="0" y="-3" width="12" height="14"><math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mi>1</mi></math></foreignObject> <foreignObject x="0" y="37" width="12" height="14"><math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mi>0</mi></math></foreignObject> <foreignObject x="40" y="-3" width="12" height="14"><math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mi>2</mi></math></foreignObject> <foreignObject x="40" y="37" width="12" height="14"><math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mi>3</mi></math></foreignObject> </g> <g fill="none" stroke="#930"> <g marker-end="url(#svg295arrowhead)"> <path d="M10,7 37, 7"/> <path d="M6,42 6, 17"/> <path d="M10,47 37, 47"/> <path d="M46,12 46, 37"/> </g> </g> </g> </defs> <use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#myRect256" x="0" y="0"/> <g fill="none" stroke="#930"> <path d="M11,43 38, 15" marker-end="url(#svg295arrowhead)"/> <g stroke-width="3" marker-end="url(#svg296arrowhead)"> <path d="M12,12 20,20"/> <path d="M40,18 27,40"/> </g> <g stroke="#FFF"> <path d="M12,12 20,20"/> <path d="M40,18 27,40"/> </g> </g> <g fill="none" stroke="#930"> <path stroke-width="5" d="M55,25 72,25"/> <path stroke-width="3" stroke="#FFF" d="M55,25 72,25" marker-end="url(#svg296arrowhead)"/> <path stroke-width="1" d="M55,25 72,25"/> </g> <use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#myRect256" x="80" y="0"/> <g fill="none" stroke="#930"> <path d="M92,12 118, 39" marker-end="url(#svg295arrowhead)"/> <g> <g stroke-width="3" marker-end="url(#svg296arrowhead)"> <path d="M92,20 100,38"/> <path d="M120,12 113,19"/> </g> <g stroke="#FFF"> <path d="M92,20 100,38"/> <path d="M120,12 113,19"/> </g> </g> </g> </svg> \end{svg}}\right\}\\ O(\Delta^4) = & \left\{ \array{\begin{svg} <svg xmlns="http://www.w3.org/2000/svg" width="28em" height="23em" viewBox="-35 0 245 230"> <defs> <g id="myPent256"> <g font-size="10"> <foreignObject x="25" y="-2" width="12" height="14"><math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mi>2</mi></math></foreignObject> <foreignObject x="0" y="27" width="12" height="14"><math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mi>1</mi></math></foreignObject> <foreignObject x="50" y="27" width="12" height="14"><math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mi>3</mi></math></foreignObject> <foreignObject x="13" y="57" width="12" height="14"><math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mi>0</mi></math></foreignObject> <foreignObject x="38" y="57" width="12" height="14"><math xmlns="http://www.w3.org/1998/Math/MathML" display="inline"><mi>4</mi></math></foreignObject> </g> <g fill="none" stroke="#930" marker-end="url(#svg295arrowhead)"> <path d="M8,32 25,13"/> <path d="M35,10 52,28"/> <path d="M54,41 48,57"/> <path d="M24,67 36,67"/> <path d="M16,62 8,45"/> </g> </g> </defs> <use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#myPent256" x="0" y="0"/> <g fill="none" stroke="#930"> <g marker-end="url(#svg295arrowhead)"> <path d="M10,36 45,36"/> <path d="M22,60 47,41"/> </g> <g> <g stroke-width="3" marker-end="url(#svg296arrowhead)"> <path d="M31,12 31,26"/> <path d="M12,38 25,48"/> <path d="M45,48 35,60"/> </g> <g stroke="#FFF"> <path d="M31,12 31,26"/> <path d="M12,38 25,48"/> <path d="M45,48 35,60"/> </g> </g> </g> <use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#myPent256" x="110" y="0"/> <g fill="none" stroke="#930"> <g marker-end="url(#svg295arrowhead)"> <path d="M120,36 155,36"/> <path d="M122,41 147,60"/> </g> <g> <g stroke-width="3" marker-end="url(#svg296arrowhead)"> <path d="M141,12 141,26"/> <path d="M125,47 135,58"/> <path d="M162,38 145,48"/> </g> <g stroke="#FFF"> <path d="M141,12 141,26"/> <path d="M125,47 135,58"/> <path d="M162,38 145,48"/> </g> </g> </g> <use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#myPent256" x="160" y="80"/> <g fill="none" stroke="#930"> <g marker-end="url(#svg295arrowhead)"> <path d="M172,119 195,140"/> <path d="M194,98 201,138"/> </g> <g> <g stroke-width="3" marker-end="url(#svg296arrowhead)"> <path d="M175,127 185,138"/> <path d="M212,116 206,116"/> <path d="M189,98 184,121"/> </g> <g stroke="#FFF"> <path d="M175,127 185,138"/> <path d="M212,116 206,116"/> <path d="M189,98 184,121"/> </g> </g> </g> <use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#myPent256" x="55" y="160"/> <g fill="none" stroke="#930"> <g marker-end="url(#svg295arrowhead)"> <path d="M74,220 83,180"/> <path d="M87,178 96,218"/> </g> <g> <g stroke-width="3" marker-end="url(#svg296arrowhead)"> <path d="M86,187 86,216"/> <path d="M63,196 71,196"/> <path d="M107,196 99,196"/> </g> <g stroke="#FFF"> <path d="M86,187 86,216"/> <path d="M63,196 71,196"/> <path d="M107,196 99,196"/> </g> </g> </g> <use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#myPent256" x="-50" y="80"/> <g fill="none" stroke="#930"> <g marker-end="url(#svg295arrowhead)"> <path d="M-31,140 -22,100"/> <path d="M-29,143 -3,120"/> </g> <g> <g stroke-width="3" marker-end="url(#svg296arrowhead)"> <path d="M-40,116 -35,116"/> <path d="M-17,97 -17,123"/> <path d="M-5,128 -15,140"/> </g> <g stroke="#FFF"> <path d="M-40,116 -35,116"/> <path d="M-17,97 -17,123"/> <path d="M-5,128 -15,140"/> </g> </g> </g> <g fill="none" stroke="#930"> <g stroke-width="5"> <path d="M60,35 100,35"/> <path d="M158,75 168,90"/> <path d="M118,190 168,155"/> <path d="M3,150 43,185"/> <path d="M-3,95 11,79"/> </g> <g stroke-width="3" stroke="#FFF" marker-end="url(#svg296arrowhead)"> <path d="M158,75 168,90"/> <path d="M60,35 100,35"/> <path d="M118,190 168,155"/> <path d="M3,150 43,185"/> <path d="M-3,95 11,79"/> </g> <g stroke-width="1"> <path d="M60,35 100,35"/> <path d="M158,75 168,90"/> <path d="M118,190 168,155"/> <path d="M3,150 43,185"/> <path d="M-3,95 11,79"/> </g> </g> <g fill="none" stroke="#930"> <path stroke-width="7" d="M85,43 85,140"/> <path stroke-width="5" stroke="#FFF" d="M85,43 85,140" marker-end="url(#svg296arrowhead)"/> <path stroke-width="3" d="M85,43 85,140"/> <path stroke-width="1" stroke="#FFF" d="M85,43 85,140"/> </g> </svg> \end{svg}} \right\} }

— Jacques

John says: Since all my papers in LaTeX use LaTeX macro package like xypic to draw diagrams, it’s quite sad that we need to use something like SVG here. It means I can’t take material from my expository papers and put it on the $n$ Lab without redrawing all the diagrams. And, it means I can’t use this environment to write papers without redrawing all the diagrams. Sigh.

Backups

I think it was mentioned before, but I missed it: is there a quick web-interface way to upload files to the server that an entry wants to link to?

Another thing: the more work we invest in this the more I become worried that we have some data loss. Is there any way too have an automated mirror image of the site created every now and then? Jacques said the whole wiki itself sits in one big file. What about pictures etc on the server that it links to?

-Urs

Urs writes: “The more work we invest in this the more I become worried that we have some data loss” - yes, I’m worried about that too. I’d imagined you had already solved that problem by now! I think I won’t do any more work on this wiki until we solve this problem. I hate losing work, and I back up all my work to 2 or 3 sites.

“Jacques said the whole wiki itself sits in one big file.” Is there at least a way for you or I to manually copy this file to another site? Of course an automatic backup procedure is better - until it stops working for some reason; one still needs to check it regularly.

-John

Well, you’ll have to ask your webhosts why

 scp -v /usr/local/instiki/db/production.db.sqlite3 [email protected]:Desktop/

produces the following error (lots of other junk, but this is the important line):

 debug1: read_passphrase: can't open /dev/tty: No such device or address

which is a little strange, since

  ls -l /dev/tty

yields

  crw------- 1 root root 5, 0 Dec 14 06:32 /dev/tty

One should also be able to initiate a scp operation from the remote machine. That doesn’t work either, presumably for the same reason.

Can one make use of the Atom feeds (see ‘Feeds’ at top)? I don't really know anything about feeds, but I probably should learn.

You can export the entire wiki. That’s not the point. You should also be able to mirror the database file and any attendant files

scp -r /usr/local/instiki/public/nlab/files [email protected]:Desktop/

to some remote location (your laptop, even). That’s not possible because the setup here seems not to assign a tty to the shell one obtains when one sshs into the VPS. This makes it impossible to use scp (or rsync -e ssh or whatever).

To John: So there is no reason to be worried about loss of the content of the entries. Please don’t make this stop anyone work on the wiki!! As Jacques points out, using export gives a zip-file with all the typed content. I am keeping regular backup copies of that.

But I was wondering what happens when we start uploading lots of auxiliary files, such as .gifs, to the server. Apparently that requires more thoughts/work…

To Toby: subscribing to the feed is a convenient way to keep track of which entries were changed in which way.

-- Urs

So if we want to back up the current wiki, then we export it. If we want to back up the wiki and its history, then we (once only) go through the history of each page and back it up by hand, then use the feed to track all further changes. If we want to back up uploaded files too, will these show up in the feed or the export? (Do we have any yet for a test?)

That’s a silly way to do things. Just cp the database file into the /usr/local/instiki/public/nlab/files/ directory, download the copy with your web browser, and then delete the copy.

Heh, maybe I should say that's how I could do it (^_^). I don't want to make assumptions about what can be done in the shell, which apparently has some bad behaviour. In any case, I don't have access to the shell, but I am capable of the (otherwise much sillier) method above. (Not that I expect to do that either … although I did export the wiki last night and might do so again in a week or so.)

I understand. I presumed that Urs would be the one doing the off-site backups. In any case, I want to emphasize that placing a copy of the database file in the downloadable files directory is a security risk. So it should not be named something obvious, like “production.db.sqlite3”, and it should not be left there any longer than absolutely necessary.

If Urs is reading this, then he will probably do that (until scp is fixed), and that will settle it. But by the way, what is the security risk in the database? (Backups are more secure if widely spread, and without your warning, Urs might even have invited others to download it, although doubtless he, John, and David would be more than sufficient.) Does it contain my unencrypted password or something? (Of course, feel free to link to a general Instiki page if you've already explained this elsewhere.)

Unencrypted passwords (including the Instiki password needed on the “Edit Web” page) and all the purportedly password-protected data.

As far as avoiding the danger of lost effort, I think that the problem is solved. But backing up will be much easier and smoother if the tty problem is solved too.

One operation instead of three.

Uploading resources

I was going to upload some pictures, but I am experiencing problems sft-ing into the server. Not sure why.

Generally, it would be nice if everybody could upload resources together with the entries he or she submits. Maybe with a password protection. I am not sure how to proceed on this matter…

-- Urs

Jacque says that one shouldn't allow uploads without password protection, I guess to prevent spam. Perhaps uploads should be restricted to a separate web (for uploads only), which this web can link to. (I gather that allowing uploads and requiring passwords is done web by web within the Instiki installation.)

Uploaded files can also overwhelm the memory limits (even without spam). That's one reason to make images SVG whenever possible.

If you keep a reasonable upper limit on the allowed size of uploaded files and if someone is willing to check periodically that miscreants are not abusing the site by using it as a file drop-box, then I suppose the risk is relatively low. Nowadays, with the popularity of P2P filesharing systems, the temptation of using some random unsecured website as a drop-box is somewhat diminished.

Another category, another naming convention

I've gone through all the names of categories (like $\Set$ , the category of sets) and tagged the pages category: category. Also, I've imposed a naming convention on categories, that they should be singular and abbreviated if long. I'm not sure that I agree with these, but they seemed to be more common already than the alternatives, and I think that it will be good to have a convention. If anybody doesn't like this convention, then please say so! (It's not too late to change things back.) —Toby

Algebroids

Eric says:

I was thinking about the categorical definition of algebras as a monoid in Vect. Then I was trying to think of how you would similarly define a graded algebra. A thought that came to mind, which seems to make sense, is that a graded algebra could be thought of as a “category in Vect”. Or something like that.

Come to think of it, could you say that given a monoid $M$ , an algebra is a functor $A:M\to Vect$ ?

Could you say that given a category $C$ , an algebroid is a functor $A:C\to Vect$ ?

Then a graded algebra is a special kind of algebroid. It sounds kind of poetic. Is there any truth to it?

Does that make any sense?

After some doodling, I think that a graded algebra should be a monoid in the category of graded vector spaces. Is that better?

If a graded algebra is a monoid in graded vector spaces, what is a clean “categorical” way to probe the degree of the element?

What is a clean categorical way to define graded vector spaces?

Urs says: If you want you can say that a $G$ -graded vector space is a functor $G \to Vect$ . Notice: NOT a functor $\mathbf{B}G \to Vect$ from the group $G$ , regarded as a one-object groupoid, but just a functor from the underlying set of $G$ .

Toby says: Given an abelian group $G$ , the functor category of functors from $|G|$ to $\Vect$ (where $|G|$ , the order of the group $G$ , is a set) is the category of $G$ -graded vector spaces with homogeneous linear maps as morphisms. To make this a monoidal category, let $(V \otimes W)_g$ (where $V = (V_g)_{(g:G)}$ is a functor) be

\bigoplus_{h:G} V_h \otimes W_{g-h} = \bigoplus_{h,k:G, \atop h+k=g} V_h \otimes W_k

(a kind of convolution product). Then a $G$ -graded algebra should be a monoid in this monoidal category. (To some extent, this should still work even if $G$ is just a non-abelian monoid. What we really need is to describe that convolution product arrow-theoretically.)

See also: https://secure.wikimedia.org/wikipedia/en/wiki/Super_vector_space#The_category_of_super_vector_spaces. But it looks like $G$ must be a ring (or at least rig) to define the braiding.

John says: Eric wrote:

I was thinking about the categorical definition of algebras as a monoid in Vect. Then I was trying to think of how you would similarly define a graded algebra.

It’s a monoid in GradedVect, the monoidal category of graded vector spaces.

A thought that came to mind, which seems to make sense, is that a graded algebra could be thought of as a “category in Vect”. Or something like that.

No, a category in Vect is precisely a ‘Baez-Crans 2-vector space’: it has a vector space of objects, a vector space of morphisms, and all the category operations are linear.

Come to think of it, could you say that given a monoid $M$ , an algebra is a functor $A:M\to Vect$ ?

You could say it, but that wouldn’t make it true.

In fact, a functor $A: M \to Vect$ is none other than a representation of the monoid $M$ .

Could you say that given a category $C$ , an algebroid is a functor $A:C\to Vect$ ?

You could say it, but that wouldn’t make it true.

In fact, a functor $A: C \to Vect$ is a representation of your category $C$ , which is very different than an algebroid. An algebroid is a category enriched in $Vect$ .

Then a graded algebra is a special kind of algebroid. It sounds kind of poetic. Is there any truth to it?

Yes, there’s some truth to this guess, despite the errors that led up to it. Jim Dolan and I have been working on ideas related to this, and (more interestingly) their applications to algebraic geometry. But we prefer to shock the world with these ideas at a later time.

What is a clean categorical way to define graded vector spaces?

Toby already answered this, but let me note that one can and should define $S$-graded vector spaces for any set $S$ ; these then acquire special properties when $S$ is a monoid (like the natural numbers) or a group (like the integers). An $S$ -graded vector space is a functor $F: S \to Vect$ , where we think of the set $S$ as a discrete category.

Please don’t take my slapdowns the wrong way! I’m very glad you’re trying to understand lots of math from a categorical viewpoint. But, in my ‘Wizard’ persona it’s my duty to crush errors — with a certain crazed glee, and utter disregard for the sensitive feelings of the victim.

Eric says: Thanks! Fortunately (I think), I am comfortable admitting I don’t understand something and one way I learn is to state things as I see them hoping to be corrected. Slap away!

Eric says: If a group is a groupoid with one object, is an algebra an algebroid with one object? I’ve never seen a definition of algebroid, which is why I guessed an algebroid would be something like a category in $Vect$ as opposed to a monoid in $Vect$ . I drew some doodle diagrams which seemed to make sense. Is a ‘Baez-Crans 2-vector space’ another word for algebroid, i.e. is a ‘Baez-Crans 2-vector space’ with one object an algebra? It seems to be as far as I can tell.

Mathieu says: I don’t think so, because a category in Vect with one object is a monoid in Vect for the monoidal structure given by the cartesian product, whereas an algebra is a monoid for the monoidal structure given by the tensor product. In fact, on each vector space there is a unique monoid structure for the cartesian product, given by the codiagonal, so a Baez-Crans 2-vector space with one object is just a vector space.

Discussion Pages

On some pages, e.g. quiver, some discussion is forming. Rather than polluting the page and rather than just deleting the discussion after it has been settled, what if we create special “Discussion” pages that relate to specific pages? For example, [[Discussion: quiver]] and link to this page from [[quiver]].

If we decide to do this, we may want to settle now on a proper page title format.

That's a possibility. However, I don’t think that ongoing discussions are pollution, certainly not when they're in their query blocks, easy to separate from the rest of the page.

A lot of discussion will have no value worth saving (and it's in the edit history if really needed). A lot of useful discussion can be refactored (when finished) into the normal page text. Until we get into back-and-forth arguments and haggled compromises like on Wikipedia, I'm not sure what would be left to move to a dedicated discussion page.

John says:

Right now I like the idea of putting the discussion in the same page, at the end, in a section labelled Discussion.

I think that people can learn a lot from these discussions, where you see the interplay of ideas better than in the formal portion of the text. This is, after all, not an encyclopedia but a “Lab” - a place where people come to work and think. We haven’t quite discovered what that means yet. But, it could involve a lot of discussion.

Yeah, I also like these Discussion sections at the bottom.

Definitions — Boldface or Italics

John says:

I’ve been putting definitions in italics. Someone else is putting them in boldface. We should settle on a convention. Meet me at dawn in the town square — bring your pistol.

If you used the Theorem Environment to mark then up, then this decision could be made globally, by adjusting the CSS. But, since I’ve pointed this out 6 or 8 times, now, maybe I should just let you have recourse to your pistols.

Eric says: I’m still learning and wasn’t aware of the Theorem Environment. We should definititely encourage its use, however, I think John is referring to the first use of the word within a definition. I’ve noticed that too. I’ve been using bold, but could switch to italic if that is what you want.

John says: In this case I’m more interested in consistency than enforcing my will upon the world, despite my joke about pistols at dawn. Bold jumps out you more than italics, I think. A theorem environment would let us make (and change) this decision globally, but we won’t want all our definitions to be stated as part of a formal Definition environment — sometimes it’s nice to make a definition as part of a paragraph of ordinary text, and in my own papers I always put the defined term in boldface, to 1) make the definitions easy to spot, and 2) make it clear that I’m defining something instead of stating a fact about something (I hate it when someone says “Prüfer rings are hereditary and Noetherian” and I can’t tell if this is supposed to be the definition, or merely a cute fact about Prüfer rings).

I also prefer boldface. I've been doing that unless a page already uses italics. —Toby

Eric says: Lots of new pages are cropping up with italics instead of bold. I’ve been changing them when I see them. From now, the first time a word being defined is used within the definition, let’s make it bold.

John says: whoops! I’ve been continuing to use italics. I’ll switch to bold.

Eric says: No worries. It’s great to see all the new content :) I was just beginning to wonder if I SHOULD be changing them to bold. Reviewing this discussion, though, I think we settled on bold. To keep things consistent, I’ll continue to switch things as I come across them. Things are really starting to take shape! I’m learning just by editing stuff.

John says: Thanks for all the great work! I see you improved my picture of a span. That inspired me to improve the entry on spans, and add one on pullback - my first tiny stab at explaining limits on the $n$ Lab.

Linking to Wikipædia

Eric says: How would I link to an external address that itself contains parentheses, e.g.

http://en.wikipedia.org/wiki/Field_(mathematics)

Attempting

[Field](http://en.wikipedia.org/wiki/Field_(mathematics))

picks up the first closing parentheses and tries to link to

http://en.wikipedia.org/wiki/Field_(mathematics

[Field](http://en.wikipedia.org/wiki/Field_%28mathematics%29) produces Field.

John says: I ran into this problem too, but not remembering the good solution described above, I adopted a crude hack: I left out the parentheses around, say, “(mathematics)”. It worked, but only because Wikipedia forgave my sin. I need to go back and fix my mistakes someday.

Deleting Pages

I created a page on accident (typo) and didn’t realize until I modified it. Is there a way to delete it?

Yes.

Eric must be talking about [[action group]] (don't link it!). I just put it in category\: delete, so anybody with the password to the wiki can delete it by deleting all orphaned pages in that category. On the other hand, you could leave it there (blanked), since it doesn't seem to do any harm.

Jacques just added several more pages to the delete category, some of which were not created as either mistakes or as redirect pages, although all of them were created extremely short. It seems like a waste of time, and a slippery slope to start deleting authorship information for short items (most of which will now be attributed to me, actually), but nobody will be seriously confused.

I added orphan pages from the redirect category which never (going back all the way through their history) contained any actual content, except for a redirect link to another page.

In fact, there were a couple of similar pages that (at some point in the past) contained a link to two pages. Those I left unmolested, as I did all of the pages in the redirect category that, at one point, contained actual content that has subsequently moved elsewhere. Those are, at the very least, of antiquarian interest.

Anyone who feels that any of the aforementioned pages lie on the wrong end of the slippery slope is encouraged to revert them.

OK, I reverted all of the ones that don't seem to me to fit the criterion that you mentioned. That is, I reverted all of the ones that originally contained a link to a resource on another website, or that contained an outline of a broad topic that happened to consisted of no more than one item at the time. Equivalently —although this was not the standard that I used—, I reverted all those that contained material that David or Urs wrote and which Urs or I copied to a renamed page.

The phrase ‘slippery slope’ is probably not the best. My point is it can be difficult to determine which information is worth keeping and which is not, which is why it's often best to keep all of it. Sometimes this takes extra effort, and then you might not bother; sometimes there are reasons why it can't all be kept, such as space constraints. Here, it is easy and feasible to keep it.

Eric's page is a little different, since he (in effect) created in blank and wants to delete it himself; if he could have deleted it just as he erased the content that was presumably there on his first save, then nobody would ever have noticed except him. But perhaps it was I who started on the slippery slope, and you who followed ….

Anyway, if anybody deletes anything, it will probably be Urs; I'll accept whatever he does, even if I happen to think that it was a poor decision. I'm not the boss.

Eric says: I like the idea of regularly deleting pages marked category: delete. This would also give us a mechanism to delete pages we create by accident. I guess there would be a danger of malicious deleting if it was automated?

Linking to External Papers

Eric says: When a paper becomes freely available on some web page, I’m pretty sure it is “public” and there would be no harm in us providing our own copy. Is that right? If so, I had the thought that it might be better to upload a commonly referenced PDF rather than link to an external link. The reason being that the external link may become broken and the paper would no longer be available. If we had our own copy of popularly referenced papers here, the links would never become broken. Just an idea…

As a matter of copyright law, it's not true that freely available papers are in the public domain. Providing our own copy is probably still legal (at least if the server is in the U.S.), since we'd provide it for educational purposes and there's no money involved on either end. That said, if there's any chance that someone might request that we remove it, we should have somebody designated to act on such requests.

However, there are other problems. PDF files are much larger than plain text, and we may have space problems if we try to copy a lot. Also, we'll miss any new version that appear, especially common on the arXiv. As for dead links, while they are the curse of the Web, one can guard against those by keeping a copy of what one might like to read again on one's own personal computer. Then if a link here dies, you can decide case by case whether it's wise to upload it here.

We have 16GB free space on the server. Let’s upload things which we find important enough to be uploaded.

Wow! I think that I was remembering the RAM limits discussed on the Café. 16GB ought to be enough for everything (^_^).

Why globular identities?

I’m “secretly” (as if it weren’t totally obvious) trying to learn enough of the material here at the nLab to be able to frame some of the stuff Urs and I worked on into the context of space and quantity, but where both space and quantity are “discrete”. So far I’ve learned some cool ways (but totally obvious to anyone here) to define directed graphs and I attempted to generalize it to directed n-graphs hoping to make a connection to higher categories somehow. However, one barrier for me has been the globular identities because the shapes they produce are “globs” or “bigons” which are not what I want for geometrical modeling. I’ve recently learned about double categories and they (and their higher dimensional generalizations) seem to be closer to what I’m looking for. In the process of learning about double categories, I’ve also stumbled onto bicategories as being enriched over Cat, but Urs corrected my Example by specifying that what is really enriched over $Cat$ are strict 2-categories. He then added another example, i.e. a strict $n$ -category as being enriched over strict $(n-1)$ -categories and stated that as $n\to\infty$ you get $\omega$ -categories. This latter example gives some hint as to why the globular identities are there. Is that essentially why $\omega$ -categories are defined with globular identities so that you can iterate the construction via enrichment? Any words of wisdom/clarification on the subject or even pointers to further references for geometrical definitions of higher categories other than those based on simplices (maybe cubes?) would be appreciated. - Eric

Eric says: By the way, Urs has created a page that begins and mostly ends an answer to the question about shapes here: geometric shapes for higher structures

Organizing the Pages

John says: In email, David Corfield asked: “I wonder how we can encourage different levels of explanation. A few slick comments gets a concept across to an expert, while more is needed for the non-expert. Might there be parallel pages for the same entry?

Urs replied: “At least on some entries we already tried to offer different level of explanations. A couple of entries start with a section ‘Idea’ that offers some heuristic ways to tink about the concept. Then comes the formal ‘Definition’ and then after that some helpful ‘Remarks’ etc. I’d think this kind of approach can be used to provide information of use for a wide range of readers.”

I replied: “Multiple pages are a bit awkward… Wikipedia does fairly well at this with just one page, and we can do even better, just by starting with easy stuff and working our way up to harder stuff.

Urs has described how some pages, and eventually all, will have several sections. However, Urs seems to like focusing on high-level folks, while I focus on low-level folks. So, ultimately, it won’t be enough to have just one section called “The Idea”. What “the idea” is depends on how much you know. So, ultimately, the page should start with a very low-level description of the idea, and later move on to more and more sophisticated versions.

This will take a while to develop. I haven’t really begun to invest any serious energy in the $n$ Lab, since I’ve been busy finishing papers.

So, for example, my entry on rings beginning with “a ring is a monoid in Ab” was just a cold splash of water meant to wake up people who aren’t used to category theory. A more sane entry would remind people of the usual definition and then explain how it can be compressed this way. But this would take longer to write.

I’m even imagining a fiendish plan where I force my grad students to write $n$ Lab articles on topics they’re learning about. Not sure that’s a good idea.

I’m gonna post this on the nLab general discussion page - that’s where this conversation should really be occuring.“

By the way, this General Discussion page needs a table of contents, with links, for people to find information on different topics. It’s sprawling out of control. It’s also possible we should use other pages for talking about specific math topics like Algebroids or Globular Identities. Maybe we need a Math Discussion page and a Physics Discussion page?

Urs says: I was going to address this, too: this discussion page here does not work well. It is hard to see where the last contribution is.

But there is an obvious answer: we want discussion on the blog, don’t we? The blog is designed to allow discussion, the wiki to allow incremental collaborative work. We should have our “general discussion” on the $n$ Lab over at the $n$ Cafe. The additional advantage would be that everybody reading the blog will always be alerted of the discussion which we are having here.

Eric says: Oh oh! I like the idea of moving the “General Discussion” to the nCafe. That makes a lot of sense. “There to chat, here to work.” If something in the General Discussion becomes elevated to actual content, we can always add that content to the nLab, where it will be indexed, etc.

As far as the level of discussion, my opinion is that we should avoid duplicating “standard” definitions as much as possible (especially material that is already on wikipedia) and take this opportunity to present everything arrow theoretically. I almost think of it as a challenge to define every item via diagrams with as few words as possible.

Now that I think of it, there already is an nLab article on the nCafe which is suitable as a General Discussion and some questions I asked here should have probably been asked there. Sorry about that. This page could serve as a summary of anything there worth keeping.

This very discussion is now at the Café!

John says: Okay, good: move most of the General Discussion to the $n$ Café!

This General Discussion page has, embedded in the general discussion, a number of important how-to tips and useful conventions (like how to spell $n$ -category). This stuff deserves a page or two here at the $n$ Lab. Maybe some energetic young person can create that. HowTo

category: meta

Revised on February 28, 2016 09:14:36 by Todd Trimble (67.81.95.215)

nLab General Discussion