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.
Hello Everyone,
After looking at the orginal discussion about the database of categories and the database of categories nLab page here I would like to know the current status of the database of categories. Is anyone on the steering committee currently officially responsible and working on the database? If not, I would like to contribute by having the task of creating the database of categories, completely for free, for my senior project. I am a Computer Science major and I am required to develop a solution to a real world problem of reasonable complexity. As a regular user and contributor to the nLab, I am highly interested in making a contribution to the nLab community as sign of appreciation for its existence and high quality. I would like to be given the opportunity to be the sole developer and maintainer of the database of categories during the duration of my senior project. I wish to develop a database of categories of high quality and that is truly useful to everyone here. Please let me know the current status of the database of categories and if I can be of some assistance. You can find my nLab page here.
Is anyone on the steering committee currently officially responsible and working on the database?
No. The project is very dormant.
I would like to contribute by having the task of creating the database of categories, completely for free, for my senior project.
Sounds interesting. it might serve a real good purpose. For instance, incidentally, I just spent a few hours scanning various model categories of algebras on whether they are left proper. It would be cool if eventually could just open some computer program and, in this example, enter a model category and ask if it is left proper, or conversely, ask the computer to list for me all left proper model categories of algebras.
But, thinking about this, it could be quite a hard task of coding this. There are no universally accepted names of categories, so the program would need some sophistication in trying to figure out which category I might have in mind. Then there may be plenty of technical qualifiers (e.g. categories of all objects, of finitely generated objects, of finitely presented objects, etc. may all go by the same name, with the fine print tacitly understood in certain contexts and communities) that may sensitively affect the properties of the category.
So I am thinking a working database of categories could be quite useful, but also that making it get to the point of being usefully working may be quite non-trivial. We should keep feeding you with real-world queries to a would-be database while you code it, to make sure that the end result is really useful.
Can I now have your approval to call you and the rest of the steering committee my sponsors (not financially, but as someone who vouches for me as professionals in the real world) during this period of selecting a senior project for approval by my professor?
Not sure what this means. But what I can promise you is to testify to anyone who wonders that a good working database of categories and their properties could be a useful thing to have, useful for researchers in those parts of mathematics that rely a lot on applying category theory, such as algebraic topology, homology, homotopy theory and many others.
You should maybe note that the steering committee (nlabmeta) is not intended to be a body concerned with issues such as yours. This is a body concerned with boring and annoying issues of organizing a joint wiki on the internet.
What you really want is, I think, a handful of researchers in categeory theory and related topics that would “vouch” for you , and these you should find here on the nForum. They may or may not be steering committee members at the same time, but that has no more relevance than if they are or are not members of their local football team.
Are they asking you for a list of people that would “vouch” for you? I should say that I can not much vouch for anyone before I have seen some work by that somebody. But, as I said at the beginning, if anyone is questioning the basic idea of a database of categories, I am willing to speak up and voice the opinion that it could be a good thing.
I have yet to decide on all of the technical details, but I think using [Haskell] as a rapid prototyping language …
I would be a big fan of a database of categories and have had many thoughts about of how to integrate it into the nLab. My current thinking is:
1) It should exist as a page or pages in nLab and would be best if defined and integrated into normal nLab pages.
2) Database items should be JavaScript objects, which all browsers know about.
3) A DB item on a nLab page should be represented in XML. Currently the nLab parser has an escape for including XML SVG images in a page. The parser would need another escape for a XML DB item.
3a) An escaped XML DB item is parsed into a JavaScript object.
3b) The JavaScript object is then translated into a LaTex format which is appended to its position on the page.
4) If the nLab parser has an escape for DB items which lets them live in the source of a nLab page but are essentially unhandled then most of the development needed to handle them can take place in the writing of an external Greasemonkey script.
Basic facts that I would like to see in a DB of categories include which universal properties they have or don’t have. For example one partial DB entry might be:
{name: "Set",
product: "[[cartesian product]]",
coproduct: "[[disjoint union]]",}
In the past I have written Greasemonkey scripts that provide structured editing of JavaScript objects. If you want, I can work up a version for this application. The way it would work would be that clicking a script added button on a nLab edit page would pop up the JSO editor, and then after changes are made the XML JSO representation and the LaTexified rendention of the item is inserted into the page. Ultimately one would want the nLab parser to recognize some escaped XML such as
<DBitem> <jso> ... </jso> <latex> ... </latex> </DBitem>
and use the generated <latex> delimited part for rendition.
Finally after the external Greasemonkey script is well developed and there are numerous DB items in nLab pagess one can consider integrating its functionality into nLab and having nLab do such things as collecting them all and presenting them in various fashions.
It should exist as a page or pages in nLab and would be best if defined and integrated into normal nLab pages.
That sounds like a very good idea, indeed.
{name: Set, product: [[cartesian product]], coproduct: [[disjoint union]],}
When designing this, one should be really careful that the end result is actually useful. For instance I think a field “description” is necessary, that allows to search for a list of words that might describe a category. The case of is quite misleading: the vast number of categories out there has no standardized names.
And then the system should be able to deal with hierarchies of properties. If a category happens to have some property X, then only in this case may it make sense to ask for further properties. For instance: if the category does carry the structure of a model category (and typicaly it carries many different ones) then we want to know: is that extra stucture left proper or right proper (to pick up my precvious examples). But this is a question we can only ask if there is a model structure in the first place.
Urs, you are talking about ontological issues and ultimately a good precise ontology needs to be developed. However for initial purposes a crude scheme in which terminal property values are just text strings can go a long way. A partial entry like
{name: "PointedSet",
aka: ["Set_*", "PSet", "1/Set", "pt↓Set"]
coproduct: "a [[disjoint union]] with the points glued together",}
is better than nothing.
The “name” property should not be considered definitive in any way. It is just necessary internal to the DB. I see two basic types of DB entries - category definitions and relations between categories (e.g. “subcategoryOf” cannot be a property of a category since this relation is not unique). Internal category names are needed for stating relations between categories but they don’t have to be the “true” names.
A further ontological refinement would be to note that a category does have a property but it is inherited instead of being emergent within the category, but the first step is to just list the properties which will still remain true after this refinement.
A system that can represent nonsense like giving PointedSet a “rightAdjoint” property is adequate. Determining whether the DB makes mathematical sense is a whole nother project which depends on having a DB in the first place.
I think that the overall idea of the database is good, but I also find the goal “to be truly useful to researchers” really, really ambitious, because a lot of properties which would enter into field descriptions, and the categories they attach to, would be extremely well-known to researchers until you got into relatively arcane data such as “left proper model category”.
One (of many) methods for structuring the list of properties to be considered is to consider the strength of the logic which is internalizable: finite products theory, finite limits theory, regular theory, coherent theory, etc. etc. etc. So for the category of commutative coalgebras over a field, we have extensive (check), locally finitely presentable (check), cartesian closed (check), regular (no), or something like that.
I’m just spitballing here (what I know of programming you can wad up and stick in my eye), but it would be cool if it were set up in such a way that every time someone creates a new page which has a category on it and lists properties of the category, that data could be automatically sent to the database.
Todd - one of the nice things about using a JavaScript Object like representation is that (as opposed to more conventional programming language and relational database datastructures) you don’t have to define the properties in advance. Thus with no prior setup one can define something like:
{name: "Todd",
extensive: true,
locally_finitely_presentable: true,
cartesian_closed: true,
regular: false,
Toddness: 3,}
The downside of this approach is that someone has to examine the whole database to make sure that the properties (and values if taken from a small set) are being used consistently and the same conceptual property is not spelled in different ways. E.g. one person might use Toddness while another spells this property as Toddity.
This issue might be somewhat alleviated with a smart DB entry editor that presents a list of known properties to choose from or issues a warning is the user types an unknown new property name.
One way to kick off this project after nLab can accept XML DB entries would be to create one nLab page, say DB tests, where various people encode example categories and relations the way they think is right. This would allow various naming issues and other unforeseen issues to be worked out. Since all the categories are on just one page, local JavaScript code could implement various DB searching functions and maybe some types of consistency tests. Only after people are mostly happy with this gamma implementation could we start clamoring for nLab to automatically send DB entries to a central repository.
Hello,
Thanks for the feedback. Urs wrote:
Are they asking you for a list of people that would "vouch" for you?
I don't think a list of people is necessary, just an organization (like the nLab) with a specific problem whose solution is programmatic.
But what I can promise you is to testify to anyone who wonders that a good working database of categories and their properties could be a useful thing to have, useful for researchers in those parts of mathematics that rely a lot on applying category theory, such as algebraic topology, homology, homotopy theory and many others.
What you provide above is sufficient to warrant serious consideration for approval as a senior computer science project.
Thanks Rod for the technical feedback about JavaScript and XML. What you wrote is highly helpful. I shall present this issue (the database of categories) to my professor for approval.
Okay. My professor approved me taking on the creation of the database. I still need to identify a real person (individual with a name) as a sponsor. It was suggested that I contact whoever ’owns’ the nLab site. Should I ask Andrew Stacey if he will be my sponsor?
Also, Rod you said:
In the past I have written Greasemonkey scripts that provide structured editing of JavaScript objects. If you want, I can work up a version for this application.
Does your offer still stand?
Okay. I just read here that Urs owns the nLab domain name. If I could get the sponsorship of Urs or Andrew Stacey or someone directly connected to the nLab, that would be great.
Being my sponsor simply means providing your name, your relation with the nLab, and why you would want/need a database of categories. Again, it has nothing to do with financial backing or some commercial venture. This project is solely for academic credit. Should you choose to be my sponsor, there would be two general possibilities. Either I am successful with the project and you and the rest of the nLab community would reap the benefits of having a working database for further growth or I am unsuccessful and do not provide the database that the nLab desired. In the event that I am unsuccessful, I know of two other people on the nLab who already stated interests in the database and I’m guessing that they would be more than willing to finish were I left off or starting over with something that did work. The conclusion that I am aiming towards is that the only person who ’loses’ in this undertaking would be myself. On the other hand, should someone decide to be my sponsor and I am successful, everyone wins!
I don’t plan to waste to much more bandwidth on this issue and I have no intention of getting in the way of anyone here at the nLab, so hopefully this is my last plea at the nForum for someone to be my sponsor. If no one decides to be my sponsor I will not be able to do the database and I’ll have to find another project. So please, if you think having a detailed database of categories, giving instant access to fundamental properties of a category (concretizability, functoriality, monoidality, size, dimension, etc. etc.) would be useful, then consider being my sponsor. Also, should you take on the title of my sponsor, I’ll need your assistance with filling in the details of specific categories and their properties. A database would be an entire community effort, were everyone sends properties of a category to some page for compilation of wanted properties. As Urs stated, nLabers could provide example queries to a prototype database.
I just read here that Urs owns the nLab domain name.
I forget how these things worked out. Possibly the domain we are using now is owned by Andrew? I really forget. But I certainly don’t “own the nLab” and I have a huge and increasing dept with Andrew, because since he started taking care of server and everything, I haven’t paid him a cent yet for his expenses (Andrew, we need to sort out the transfer mechanism finally…).
If I could get the sponsorship of Urs or Andrew Stacey or someone directly connected to the nLab, that would be great.
I am not quite used to this formality level of commitment. After all I don’t know you at all (yet) apart from a handful of forum messages. Not that I have reason to doubt you at all (yet :-), but all I know is that you are somebody with a plan of doing something that I think has a chance of being useful. That’s not something that would make me “sponsor” you in the familiar sense of the word. Why is it called “sponsoring”?? Sounds like the wrong word to me in any case. Isn’t that usually related to transfer of money?
But if this is a just formality that you need to go through, I won’t stand in your way and if it helps open doors, go ahead and say that I am supporting the idea of the database-project and possibly therefore qualify as a “sponsor” in your sense.
But I am not going to sign anything or the like.
Stephen, I think that at this point it would be a good idea if your professor got in touch with me and Urs to make clear exactly what the word “sponsor” means. As Urs says, we don’t actually know you very well; but then, I’ve only met Urs once (I think) so I wouldn’t like that to be a hindrance in what you’re doing. Certainly from what you’ve said then there shouldn’t be any difficulty, but having your professor confirm the details would be reassuring.
On ownership: technically, Urs is listed as the owner (or whatever the correct word is) of the domain “ncatlab.org”, I’m listed as the owner of “mathforge.org”. The nlab is hosted at mathforge.org and ncatlab.org merely points to it. So in the strictest legal sense, I own the nLab. But only a few people would ever actually take any notice of that.
Also, Rod you said:
In the past I have written Greasemonkey scripts that provide structured editing of JavaScript objects. If you want, I can work up a version for this application.
Does your offer still stand?
Sure, once you get officially started - I will have to dig up some old stuff.
Also, previously I said that nLab would have to be modified so that it could accept and store XML Category database entries on its pages. Mabe with XML looking like:
<xe json="jso definition" tex="generated tex presentation"/>
After a little experimentation it seems no changes are needed in nLab because the XML functionality can be kludged with how existing DIV are handled - the following can be presently stored on a nLab page.
<div class="XE"
markdown="1"
json="jso definition here">
markdown generated from the jso here
</div>
I’ll try to further verify this and if so write a tiny Greasemonkey script that can 1) automatically inserts such a div in a nLab source page, and 2) generate from whatever is in the json attribute its presentation in markdown to replace the Div’s content.
Urs, Andrew:
I completely understand. If I were in your position, it is highly HIGHLY unlikely that I would put my name with anything that I was not as fully informed on as I should be. I am just a complete stranger, so I understand. I emailed my professor about leaving a comment here at the forum directed toward one of you; now its his move. (This comment originally contained links to information about my professor but I removed it in deference to his privacy).
Thanks everyone for your time and thoughts,
Stephen
My professor would like to contact you, Andrew Stacey. Could you email me your email to email him? Apparently he does not want to create an account and wants to communicate with you privately. Could he communicate directly with you in some other way privately?
Stephen, my intention was that further discussion on this should be off the forum. My contact details are linked from my webpage, or here’s a direct link.
Here is my suggestion for what a specificaton of requirements for a first implementation of a database of categories would include:
it should store its categories in a way that understands different shades of definitions
For instance if asked for “category of modules” the database should know that there is first of all a classical such notion, the category of modules over a ring. Even that splits into at least two subcases with different properties, that over commutative and that over non-commutative rings. On top of that, the database should be able to know that there are notions of modules for various other gadgets, notably lots of other notions of monoids, such as monads.
So maybe at least the database should be able to search not just for fixed names of categories but for keywords within names, so that it recognizes the word “module” both in “Category of modules over a ring” and “Category of modules over a monoid in a monoidal category” and the like.
Part of this is that a single category may be thought of as being equipped with different structure. The properties of a category underlying a monoidal category may be different from that of the category regarded as a monoidal category. And it may have different structures of a monoidal category, each with different properties. And it may have an enriched category structure, or more of them. And it may have a model category structure, or more of them. And then the model structure may or may not be compatible with the enriched structure and or the monoidal structure. (And this will envolve model structures on the enriching categories, in turn!)
The analogous requirement holds for properties of categories: if asked for “has limits” the database should be able to see that some categories may have all small limits, or all -limits or all finite limits, or maybe just products and somehow reflect that knowledge.
The database should be able to search both for properties of a category and for categories with given properties.
As a real-world example for which a database would be really useful, I already mentioned this one: it should be possible that I ask the database to list “all categories of models of algebraic theories that have model category structures which are left proper”.
So this may be a bit hard. I doubt that in the time frame available for the initial project a fully satisfactory solution can be found, but I gather from RodMcGuire’s comments above that there should be ways to code this such that even a tentative beginning has the chance of eventually being expanded to an implementation that can handle all this. Accordingly, this might be another requirement: try to design the software with the perspective in mind that this will have to be generalized eventually. Don’t make the architecture too strict, whatever that may mean.
@ Andrew Stacey:
My professor emailed you on September 2nd and resent the email on yesterday September 9th. Did you receive the email?
I understand now that this projected has to be accompanied by a huge amount of bureaucracy, but I am hoping while this is being dealt with you are already busy with thinking about and working on your project?
What do you think of the specification proposal above? Or do we need consent from Andrew about it now? ;-)
I got the original one (but not the resend) and have just replied. I echo Urs’ question: what do you (and your professor) think of the proposal above?
@ Urs, Andrew Stacey:
In terms of providing basic properties about monoidal and enriched categories, I think this can be done. On the other hand, I know practically nothing about homotopy theory, so I can’t promise anything in the way of useful properties about model categories of algebras. I do think that a working prototype of a database with information about basic universal properties that one would want to know about a category is feasible. I like what John Baez suggested at the database of categories page about basic properties.
John Baez: I don’t see any use of listing categories here unless one includes information about their basic categorical properties: for starters, which sorts of limits and/or colimits they have:
- binary products
- binary coproducts
- terminal object
- initial object
- pullbacks
- pushouts
- equalizers
- coequalizers
- finite limits
- finite colimits
- small limits
- small colimits
whether they admit interesting monoidal structures, whether they are cartesian (or monoidal) closed, and whether they are topoi, quasitopoi or allegories. In short: the basic properties one instantly wants to know about any category one meets.
Also, Urs, everyone who is interested in providing input about the database is welcomed. ;-)
@ Rod McGuire:
Do you know of any links to good introductory material on JSON, XML, and databases? Will you please list them if you do? You stated in a previous comment that all browsers recognize JavaScript. Why is conversion between JavaScript and XML necessary? The answer may be obvious, but I have never used JavaScript and may need more details.
@ Everyone: What software do most of you all use for commutative diagrams? LaTeX? Does anyone use GraphViz? I asked because I would like to use a software package for commutative diagrams that doesn’t require that I learn another computer language.
PS: If some of the above sentences make no sense, it may be because I do not feel well. And Urs, I am thinking about the project. I have not gotten word back from my professor, but I know he approves of it as long as I have an official sponsor (I know this may not be the right term for what is required of that individual but I think that it is the termed used in the course description).
@ Urs, Andrew Stacey:
Sorry about not directly addressing the question about the adequacy of the specifications provided in the previous post. I will try to provide a more thorough, thoughtful response when I’m feeling better.
I know practically nothing about homotopy theory
And likely this will be the case for many other properties of categories that we will want to add!
So it would be good if you could program the thing in such a way that if some expert here shows up and declares that
has
if it is equipped with
that then there is a straightforward way to add this information to the database.
And Urs, I am thinking about the project.
Good! I mean, I can’t force you of course to work on it, but I was just thinking that if you are energetic and eager to work on this project, don’t let bureaucracy stop you from doing so! I think it is an ambitious project, so you should start to get your hands dirty with it as soon as possible, because this may require a little fiddling with.
I have not gotten word back from my professor, but I know he approves of it as long as I have an official sponsor (I know this may not be the right term for what is required of that individual but I think that it is the termed used in the course description).
From what I understand, i am willing to be your “sponsor” in this sense!
I have a working first pass GreaseMonkey script that runs on nLab /edit/ pages. It takes Types as defined by JavaScript Objects (JSOs) and uses them to generate XHTML tables which then are displayed in the /show/ pages. I’ve been using my person page, Rod McGuire, to test out various things in its development. Outsiders might be able to comprehend this example from (currently) last section: “Types with Recursive Structure”.
(nForum does not like my attempt to insert an XHTML table, so see my page for the example)
The Type as JSO is encoded and stored as the ID attribute of a Table which means it accessible to a script running on a /show/ page.
Does anybody know how to add CSS styling info to a nLab page? My test of just putting in a <style> block did not work.
My next development step is to implement a JSO editor that runs on a nLab /show/ page. The idea is that the user
1) Clicks a table to edit a JSO or clicks something to make a new table.
2) Makes changes.
3) Clicking ’save changes’ has GreaseMonkey open the /edit/ page where the table is defined, make the indicated changes and save them, and then somehow communicate their XHTML back to the /show/ page that is being JSO edited.
One can conceive of a “Master list of DB entries” which is just an nLab page that ’include’s individual pages defining DB entries. This way some set of DB entries can be accessed and edited from just one /show/ page.
Can the Lab Elves set me up with both public and a private sub accounts? If I’m going to start automatically mucking around with nLab pages they better not be the real ones because developmental errors in my scripts may cause them to eat or badly corrupts things.
Rod, some CSS styling can be added to pages using the Maruku meta-data syntax: description and example. As CSS is sanitised when going through the instiki formatter, what you can add is somewhat limited (for a full list you should take a look at the code). Ditto with XHTML (which may be why you get the odd red block on your page).
More extensive CSS can be added by adding rules to the CSS that appears on each page. The “click down” menus are an example of this. However, this requires admin privileges (which, at the moment, means me or Toby or Urs (when he can remember the password)).
If by “public and [a] private sub accounts” you mean personal webs, then that is something that the steering committee of the nLab needs to decide about. If, though, you just want a testing ground for your scripts where it’s not important if you clobber something then you should consider doriath: HomePage (doriath). It’s basically a Sandbox on a larger scale. Even if you had your own web, you couldn’t change the stylesheet stuff yourself so working on doriath would be just as easy (or as difficult) as on a personal web. Would that suit?
Rod,
looks interesting. But i am not sure yet I understand where this is headed: so what’s the relation between all these tables on your page, and the would-be database?
Whatever the answer is, I think for the database project it would be very useful if we could see some tiny toy examples of what the thing might be like. For I am getting the impression we are all thinking of very different things when saying “database of categories”. I am getting the impression that you are imagining a bunch of nested tables. Is that right? What would these be like?
Urs
looks interesting. But i am not sure yet I understand where this is headed: so what’s the relation between all these tables on your page, and the would-be database?
Each table shows a data base entry.
A very simple database for CategoryTheory would be just a list of entries of type “category”.
A better database might also have entries of type “homomorphism”, “functor”, “set”, “adjunction”, “monad”, etc., and ways to stitch these together with those of type “category”.
The point of view I have is that the Type field in such entries is not just another property that says what type the entries have, but instead that the entry itself is a type, and the Type field says where it is positioned in the type lattice. This approach is similar to clams that “Logic Programming Languages” such a Prolog, should really be called “Type Programming Languages” because the items they manipulate are not logical formulas but types. Prolog can handle recursive structure like some of my type examples but is rather hard to use such because Prolog uses positional argument notation, while my scheme uses named argument notation.
A simple way to tell what fields are internal to a type or external is to look at inheritance. All type internal properties should be inherited by subtypes, while type external properties (say Type and Notes) don’t want to be inherited.
Of course my notation for entries can be used where Type is just another property like Age, Sex, Size, etc.
I don’t know how much “type inference” is needed in the DB or if it is needed at all - it all depends upon how sophisticated it becomes. I don’t think its design should start by specifying inference methods because they may become a solution in search of a problem. Instead as the DB becomes populated we should collect examples where inference might be useful, but not rush to implement schemes.
Btw, the table display format I implemented is known in Functional Grammar Linguistics as Attribute Value Matrices. See the examples under HPSG, though in that theory the entries are not Types but instead just have a type.
[ed. fixed bad link - thanks Toby]
@ Rod
Your link to [Attribute Value Matrices] has an empty target.
@ Andrew Stacey, Urs, Rod McGuire:
The nLab homepage says that you all use Ruby on Rails. Rod McGuire says he can do a prototype of a database with JavaScript and XML. I am familiar with Java and may be able to do a database with Java and MySQL. I know neither Ruby nor JavaScript/XML. I am trying to decide whether I should try to learn Ruby so that the database can be more easily integrated into the framework of the nLab. If Rod McGuire can do a quick prototype of a database with JavaScript/XML, perhaps I should use JavaScript/XML. I want to get started with a prototype as quickly as possible to guide the design process. What do you all think? Do you think I should use Ruby? JavaScript/XML? Java/MySQL? I am especially interested in Andrew Stacey’s opinion as he developed the website. Do you all know anything about the LAMP software framework?
@Stephen
I am interested in incorporating a DB entry scheme into nLab for my own craven desires. I think JavaScript Objects (JSOs) are a neutral representation and that ultimately a super complex version of a DB can be eventually implemented inside the nLab software - which is why I started by claiming the DB entries should be represented as JSOs.
From my perspective I am interested in the “mathematical structures as Types in a bounded lattice” question because JSOs form a bounded lattice. However, I have been writing my GreaseMonkey patches to nLab to handle entries in a very neutral manner. If one only wants to use flat rows such as:
{name: "John Smith", age: 35, occupation: "doctor"}
then that is the simplest case, and one doesn’t have to use the ability to structure such an entry with subparts, shared parts, and recursion.
I am writing my GreaseMonkey patches to nLab so that you have to know hardly anything about the underlying nLab software when you use them to create your NEEDED database of categories. It is trivial to export the JSO entries (either really simple or really complex) so you should consider that a given, and if not already existing then some trivial feature that I will write.
So you, if you want an external software approach, should concentrate on how to stitch together whatever JSO entries types you decide upon into a database and what functionality it should have. This is the same issue you would have if you tried to do this as a Javascript patch to the nLab except that you will be rather removed and not have to unhack all the bugs in the nLab software.
I am making good progress on a GreaseMonkey JSO editor that runs on nLab /show/ pages, but it is not usable yet. Maybe it will be in a week from now.
Stephen - If you have access to a server machine you might look into GreaseMonkey’s GM_xmlhttpRequest. This function could enable you to exchange DB entries (rows), or even whole tables of them between your server and nLab pages.
One reason you might want to store entries on a server you control is that it might be easier for you to do whole scale refactoring of a DB in a language you know well. Such massaging of a whole DB could be done in GreaseMonkey but such scripts can be obnoxious to develop because GM really doesn’t yet have a good development environment.
If this approach appeals to you, you could try writing a simple GM script to interact with your server using some hand coded DB examples.
1 to 35 of 35