Forums Instiki

Feature Requests

Subscribe to Feature Requests 38 posts, 4 voices

admin Administator 57 posts

You’ll note that another bug that I fixed, in the same commit, was Maruku’s section numbering (disabled by default; see vendor/plugins/maruku/lib/maruku/defaults.rb). Dunno whether that’s of interest.

Andrew Stacey 118 posts

I was checking this forum to see if you’d posted a notice that you’d fixed the bug, but I didn’t see that you’d edited your previous comment rather than posting a new one - and at the start of the week then I don’t always click through links or check RSS feeds. All of my instiki installations are now up to date. Thanks.

Bernhard Sta... 4 posts

edited almost 2 years ago

Sorry for not answering for so long - but I would still like to discuss the feature I wrote about a few months ago.

Is this a feature that is implemented somewhere? :

Your short description is slightly … underspecified. So looking at an actual implementation would be helpful to me, in deciding whether this is something to implement in Instiki.

That’s true, my description is underspecified - it was just some ideas shooting through my head that I didn’t formulate clearly, and I also didn’t research existing approaches. The problem can be described as follows:

Both mathematical concepts and their presentation are moving targets. Mathematical notation is developed together with mathematical concepts and is permanently being refined afterwards, as one can witness in the discussions on nLab. Notations are the “interface” through which humans interact with mathematical concepts, so elegant, intuitive, consistent notations are important for understanding them. However, it has been a time-consuming job to keep notations consistent and to update existing work to new notations, effectively impeding the improvement of notation and in the end mathematics itself - at least because of time wasted, and IMO also by suboptimal notation leading to suboptimal intuition.

I think that this is a consequence of a deeper problem, namely that authors have to manipulate the presentation of the mathematical concepts they describe. My opinion is that in collaborative mathematics platforms, article authors should rather manipulate the mathematical concepts themselves. TeX-derived typesetting systems are very good at typesetting mathematical notation and should be used for presentation, but when describing mathematical concepts, you shouldn’t be bothered with such details. Rather than using TeX, I’d suggest using syntax customized for the respective field of mathematics.

What I wanted to point out is that software for collaborative mathematics platforms like nLab may offer the chance to solve that problem and maybe even endorse improvement of mathematical notation by making a clear distinction between mathematical notation on the one hand, and mathematical presentation on the other hand. Mathematical concepts would be stored using a schema/ontology spanning all fields of mathematics. Mathematical notation (=wiki syntax) defined for each respective field of mathematics could then be used to write about these concepts. The presentation would be implemented using transformation from the schema/ontology to MathML or TeX or whatever.

Once there is a mechanism for representing ontologies/schemata of mathematical concepts, it becomes possible for authors to choose any notation offered, or define their own. When the notation is changed to a newer version, automatic migration schemes may enable easier switching to new notation. And as for the presentation, the reader could then himself decide whether he prefers the comma category written using a downwards arrow or a slash.

I actually found a project that might have similar aims, namely SWiM. But what I see in the related article doesn’t really look like what I’d expect from a wiki - the source code in the screenshot on page 4 looks worse than LISP, in my eyes. I think that this problem is caused by forcing authors to use some one-size-fits-all notation of OpenMath or similar, so my suggestion should make such a wiki usable.

Andrew Stacey 118 posts

Not sure if this is a bug or a feature request …

Google searches now include author information which it tries to glean from the page. It would appear that it uses the “Revised by XYZ” information to do this. It’s been suggested that this is because that is in a div with class name byline. I’m going to try changing this to see if it stops Google from assuming that to be the author. I don’t yet know how to override Google’s ad hoc method (which really does seem ad hoc if it uses a CSS class name as evidence).

I’ll report back on whether or not it works. If it does, consider this a feature request for changing byline to something like revisedby.

distler Moderator 77 posts

It’s been suggested that this is because that is in a div with class name byline.

That seems a pretty thin reed on which to base a request for changing the class names we use.

Google is pretty cagey about what algorithms they use. I’m kinda dubious about this one.

Andrew Stacey 118 posts

Okay, so that was a pretty dubious feature request!

How about this one: if a page exists (meaning, really exists - not just a redirect) then a request to <web>/new/page should redirect either to <web>/edit/page or to <web>/show/page. If the page does exist then the effect of going to <web>/new/page and submitting stuff is the same as submitting an edit except that you don’t get the previous edit in the text box so there’s nothing to show that you’re replacing something already there. The argument for <web>/show/page being that if a page exists and you didn’t know it then you should probably have a good look at what’s already there before writing something new.

(This came up most recently because a Google search for a page led to the /new/ link even though the page exists - Google had clearly found the link somewhere and added it to its list, it does this even if a robots.txt file exists since the link exists on a page that it can read.)

distler Moderator 77 posts

Great idea.

Andrew Stacey 118 posts


Forums Instiki