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.
(a) Yes, thanks!
(b) I can't think of any others; if people can, perhaps they should add them to string diagram!
(c) Separating them by commas and periods, although gramatically sensible, looked a bit funky, so I changed those to bunches of spaces. (That is not very proper, but we can work out a good CSS version once people agree, if they do, that it looks nice this way.)
I don't know anything about string diagrams (I should learn!) but it looks great.
(c) Separating them by commas and periods, although gramatically sensible, looked a bit funky, so I changed those to bunches of spaces. (That is not very proper, but we can work out a good CSS version once people agree, if they do, that it looks nice this way.)
Thanks! I agree that this looks better, and personally I prefer it --- visual clarity over strict grammatical correctness. On the other hand, the convention in published maths for dealing with this issue seems to favour grammatical correctness, in my experience, so I was following that originally; but if more established contributors don't mind the n-Lab breaking that convention, that seems good to me.
OK... I have a few more diagrams ready to go; but I have just a few questions for more experienced users before I put them up.
As far as I can see, once files have been uploaded, there's no way to delete, replace or rename them without an admin password --- is that right? So if I upload adjunction-unit.png and then realise it has a typo in, I have to upload the correct version as something adjunction-unit-v2.png, change the link in the article text, and leave the bad version gathering dust? (This is why I'm nervously asking these now, before uploading anything more.)
Also, file naming comventions: there seem to be several different discussions on the forums/lab/cafe about this issue. The most recent I could find was the end of this thread, so I should name an image for the "monad" article something like monad > axioms unlabeled.png --- is that right?
Thanks :-)
Yes, I think this is a genral design idea of the wiki: one never removes individual files, be it entries of whatever, but rather replaces them.
Then, there is one big button somewhere in the admin interface which says CLEAN UP. Hitting that will make the software look for all orphaned files, those that have no links pointing to them. These then it will delete.
So the analog of deleting here is removing all links to something.
As yes, we never cleaned up. (Sort of the way I do it at home...)
Yes, I think this is a genral design idea of the wiki: one never removes individual files, be it entries of whatever, but rather replaces them.
I'm happy with that principle. But with articles, I can replace/edit the content, consigning the old version to a "history" page; I'd like to know if I can do a similar thing with uploaded files (as iirc one can on MediaWiki). I'm not so worried about what happens to the old version of an image, but I'd like to know if I can keep the current version always at adjunction-unit.png, rather than giving a new name for each revision and ending up with adjunction-unit-v7.5a(small).png or something...
As far as I can tell, p l, you are right, both about what really happens, and about what would be nice instead.
As for the title format
monad > axioms unlabeled.png
we never did start doing things that way, despite having a discussion that ended on that note. But perhaps we should; you can show us the way!
I think I saw something somewhere about deleting files … will look in a while …
A quick look at the Instiki Instiki reveals that it is possible for users to delete files. The relevant information is at file uploads. But to save you the clicks, here's the proceedure:
Edit the page to change
myfile.pdf:file
to
myfile.pdf:delete
Click on the resulting link, to delete the existing file.
Re-edit the page, to change it back to
myfile.pdf:file
Click on the resulting link, to upload the new version.
By the way, how are you drawing these diagrams? Can you convert them to SVGs instead of PNGs?
According to those instructions, one still needs the system password to delete (a good thing, probably).
Since files have individual authors, it would be reasonable if, whenever a user uploads a file, they are given the option of putting a password on that file; then that user (or anybody who knows that password) could delete that file. (One could also delete files with the system password, as now.) That solves the problem for users who upload files with typos.
I expect that this would require a good deal of Instiki hacking, however!
Thanks for all the help! Several replies below.
Toby wrote:
As for the title format monad > axioms unlabeled.png we never did start doing things that way, despite having a discussion that ended on that note. But perhaps we should; you can show us the way!
I tried; unfortunately, when I try to save an edit containing the new link [[monad > axioms unlabeled.png:pic]], Instiki chokes, and I just get:
Internal Error
An application error occurred while processing your request.
so for now I'm sticking with using hyphens as separators, and starting each filename with the name of the article it's from. This will lead to slight duplication, eg between "monoid-axioms-unlabeled" and "monad-axioms-unlabeled", but will hopefully keep relationships clear. I hope that's OK for the moment.
Andrew wrote:
A quick look at the Instiki Instiki reveals that it is possible for users to delete files. The relevant information is at file uploads.
Toby wrote:
According to those instructions, one still needs the system password to delete (a good thing, probably).
Yep, those instructions were what I'd tried before, and as Toby said, it asked for an admin password. Manual versioning to replace typos should be fine now, anyway.
Andrew wrote:
By the way, how are you drawing these diagrams? Can you convert them to SVGs instead of PNGs?
I'm drawing them in TikZ... so I know it should be possible to get them out as svg, but I'm currently having trouble with that. I get the same error the first writer describes here --- LaTeX chokes when I try to run it with the pgfsys-tex4ht.def driver.
I'll keep poking around at that, though, and see if I can find anything. I'll also post the TikZ source to my userpage or something at some point.
Anyhow, enough technical worrying for the moment... monad/monoid diagrams coming momentarily!
monad > axioms unlabeled.png:pic
Anything with a space in it gives me a 500 error.
Then again, so does monad>axioms.png:pic; although monad--axioms.png:pic seems to work.
I did my testing at Sandbox (doriath); Andrew might be interested in looking at what else I did there just now.
<div>
<p>By the way, concerning:</p>
<blockquote>
(a) Is this a useful sort of thing to add?
</blockquote>
<p>As Toby already said: Yes! It's great that you are doing this. Thanks!</p>
</div>
Oops! Apologies for missing that password requirement.
One argument for not allowing users to delete files is that it would break rollbacks. If I upload a file and someone else deletes it then the page can't be rolled back to whatever I had it without me uploading the file again. Renaming has similar implications. This is one reason for using SVG over PNG.
We're not particularly squashed for space on the server so having a load of stale files around isn't a huge problem, or even duplicates. Of course, whilst it's best to clean up then I think it reasonable that it be done by a Lab Elf.
So here's a proposal for a system. Put a version number in each of your pictures (sillyPic_v1.png) and increment that each time. Then if we get pushed for space, or just feel like doing a bit of spring cleaning, we can easily see which pictures are replacements for others and simply delete all unneeded old ones (and for backward compatibility, make symlinks of the old to the newest version). If you like, you can let us know here if you think that there are files that could be deleted.
Incidentally, if two diagrams truly are meant to be the same then I would make them the same file even if that violates the naming convention. Then you don't run the risk of updating one and forgetting to update the other.
Looking at the script, the character set for valid filenames is [a-zA-Z0-9\-_\. ]. So spaces should work, but > won't. It's possible that deeper in the code there's something that excludes spaces (a string that wasn't quoted when it should be).
That you use tikz is great. I agree that the tikz->SVG method using tex4ht is lousy. One of my plans for PHPLaTeX is to implement rudimentary tikz support. Send me some samples of your source code, if you would, or put them on your user page and mention it somewhere here.
Added something about the more spherical Secret Blogging Seminar approach to string diagram.
have expanded the list of historical original articles at string diagram, following the current discussion on the CatTheory mailing list.
If you are an expert on this history, please further edit/expand as need be!
Added a reference:
Gray categories with duals and their diagrams
John W. Barrett, Catherine Meusburger, Gregor Schaumann
Thanks! I hope to find a free minute to look at it and talk to Catherine.
(Only just arrived at the workshop. )
have added to the References at string diagram pointers to the higher dimensional “zoom complexes” introduced in
with animated exposition in
Eric Finster, Opetopic Diagrams 1 - Basics (video)
Eric Finster, Opetopic Diagrams 2 - Geometry (video)
Is there a standard/preferable term for string diagrams that evaluate to endomorphisms of the tensor unit?
In Feynman diagram language these would be the “vacuum diagrams”. Maybe TQFT imagery has percolated sufficiently through the monoidal category theory community that one may assume this term to be understood also here?
There’s mention of ‘loops’ but it seems informally, and just as components of diagrams.
I’d probably say a “closed” diagram myself, and wouldn’t know what “vacuum” meant. A “loop” I would understand to be just a single circle rather than a more complicated diagram.
I like “closed diagram” (this also meshes nicely with closed formulas in logic, if we interpret logical formulas in terms of string diagrams).
I believe I’ve heard “islands” used.
Okay, thanks.
1 to 28 of 28