Glossary Graph Viewer

[kohlhase]

We need a graph viewer for the SMGloM (see https://mathhub.info/mh/glossary). The situation is that this is based on the SMGloM theory graph (see https://mmt.mathhub.info/graphs/tgview.html?type=archivegraph&graphdata=smglom or https://mmt.mathhub.info/graphs/tgview.html?type=archivegraph&graphdata=smglom/primes for a subgraph).

But SMGloM has a special structure. We have n+1 theories for every "module", one is the signature and the other n are language bindings for English, German, Chinese (sometimes), ....
So these should be clustered into modules. And the modules should be cross-linked to the respective part of the glossary at https://mathhub.info/mh/glossary.

On the other hand, we already have links in the glossary to graphs (the "concept graph" links; here neighborhood graphs of the current module). These links are currently dangling, and they should point to TGView. Maybe we do not want concept graphs after all, but "archive graphs" of the current archive (maybe with the current module highlighted in a special color; see #25).

All in all this should be relatively easy to do (once we understand all the issues). And it would be nice to have them soon, since I am negotiating with Springer to turn the Vieweg Mathematik Lexikon (see http://www.springer.com/de/book/9783528063085) into SMGloM and then they publish it as an eBook or web application based on our technology. They are very very interested in the graphs part of this (this is the single most exciting part for them).

[Jazzpirate]

@kohlhase are the includes in some way annotated as signature/language bindings? Or can that be inferred from the URI?
@Shadow992 is it possible to put clusterings into the json? Or isn't clustering rather something that should happen in the frontend?

[kohlhase]

@Jazzpirate I think that we should probably have a "multilingual module graph" MMT extension, which makes one node per module (i.e. signature (that has all the includes) and language bindings).
Then @Shadow992 does not have to do anything.

[Shadow992]

@Jazzpirate I am looking forward to annotated nodes with "cluster-information", because then I am able to improve algorithms based on this extra information. I would also be able to offer some kind of "Checkbox-Menu" where you can select which nodes you want to be clustered (e.g. cluster all nodes together belonging to SMGloM-German, ...).

So the more Meta-Information you provide the more intelligent algorithms I am able to produce. :D

Feel free to add any kind of information you want to nodes/edges. If I am officially not supporting some special attribute XYZ, then this will simply get ignored. Therefore there are no limits for adding attributes.

[kohlhase]

@kohlhase are the includes in some way annotated as signature/language bindings? Or can that be inferred from the URI?

No, they are not (at least I think). But all material in the smglom name space i.e. under MathHub/smglom is of that form.
Any file/theory with name xxx.omdoc is a signature and any file/theory with name xxx.ll.omdoc where ll is a ISO-639 language specifier (de or en mostly) is a language binding.

I know this is an evil hack, and we should have type information on the theories, but that will only become possible when @tkw1536 takes over the smglom MMT generation pipeline.

[kohlhase]

@Shadow992 is it possible to put clusterings into the json? Or isn't clustering rather something that should happen in the frontend?

I am not sure clustering is the right metaphor here. I think the module graph should really only have nodes for each SMGloM module (i.e. a signature and its language bindings) in the graph.
The current situation is

this should be collapsed into one node, and only the links of the signature here theory witherror should be put into the graph.
Maybe we can (later?) add an interaction that tells us about (or gives us access to) the respective theories in the module.

[Shadow992]

I will implement this in frontend (except highlighting current SMGloM module). I implement this by auto-detecting SMGloM-Modules in frontend. So we do not need any manual checkboxes and or inputs/checkboxes.

[Shadow992]

This looks like a special case of #15
Therefore I will close this. If we need this feature fast, a option would be to add a new class/stylee for the language bindings in MMT and show/hide all nodes of the specified class.

Later on a lazy loading of language bindings (therefore a collapsed view of the graph) may be the way to go.

[kohlhase]

I agree that this issue may very well be technically related with #15, but I would not want this one closed, because even though it may reqiere the same base functionality the user interaction is different. Reopening, close when both are fixed.

[kohlhase]

I guess that this is mainly a back-end problem for @Jazzpirate to solve. You need the information what the modules are. I think we should probably generate special JSON here, even though you could read off the information from the theory names. Hmmm, I am torn.

[Shadow992]

I thought about infering modules and types by analyzing node names. So that every node matching "*.*" will become a language binding. However I highly appreciate to not use this regular expression as there is currently no way to differentiate between smglom and other graphs. This means the rule would also be applied to any other graph. Not a great ideaa, I guess. Especially not when having an eye on "manually adding/editing nodes" as someone may want to add node names similar to this pattern.

So I really would like to see this implemented in backend. As already mentioned I would go for a two fold solution:

1. Give language bindings the "correct class" (e.g. "languagebinding"). On this way we are able to show/hide them dynamically in the frontend and it should be easy to implement it in backend, too (except potentiall parsing/regex problems, which may occur anyway)
2. Later give the possibility to lazy load language bindings.