add label graph editor

[bbernhard]

At the moment, label graph maintainers need to download the ImageMonkey docker image in order to write their own label graph representation. We should make that easier by providing a browser based label graph editor.

Here's a small demo how I would imagine it to look like:

[dobkeratops]

Does the choice of the off-the-shelf graphviz dot file format lend itself to existing tools for editing?

I must admit I've always been after something like that, but i'm unaware of a stable/general purpose solution at just the right complexity level.

[dobkeratops]

general question: would you include the parts (X -has-> Y) as well as ```X -is-> Y```` in the graph,

I see that the format does support 'edge labels' (https://stackoverflow.com/questions/1806870/how-to-add-edge-labels-in-graphviz) so it seems it could represent just about anything

[bbernhard]

general question: would you include the parts ("X has Y") as well as X is Y in the graph,

At the moment it doesn't work, but it's already on my Todo list. :) Ideally I want to get to a point where we support most of the graphviz grammar.

If we get to that point, then it's really up to the label graph maintainer how he wants to structure his graph and what features of the graphviz language he wants to use.

I hope that I can push the first version to production today. If there is a first version to play with, it's probably easier to find all the hidden bugs (I am still a d3.js novice, so there are for sure plenty of them in there) and to track down the most important graphviz grammar elements that are still missing.

Does the choice of the off-the-shelf graphviz dot file format lend itself to existing tools for editing?

So far, I am pretty happy with the decision of using graphviz - there seems to be quite a few editors out there that have built-in syntax highlighting. For the online graph edtior I am using ace.js (https://ace.c9.io/) which is a really powerful editor written in Javascript. It supports autocompletion, syntax highlighting (for over 100 languages, even for graphviz) has a bunch of themes, supports cut/copy/paste and is highly customizable. The only thing that's missing (and would be quite helpful) is a live syntax checker for graphviz - at the moment that's only available for JavaScript/CoffeeScript/CSS/XQuery. But there is an API for that, so one could write it's own live syntax checker :)

[dobkeratops]

ah thinking back to other discussions.. maybe you could just include graph nodes head/dog -> head, head/dog -> dog and maybe head->part wheel/bicycle -> wheel wheel/car->wheel wheel->part etc. Then you can trace back and see head/dog is a part, which would clarify when seeing head/dog->dog that it doesn't mean it's a type of dog . (would that still work for 'wheel' .. e.g. seeing seperated wheels as individual objects)

[bbernhard]

ah thinking back to other discussions.. maybe you could just include graph nodes head/dog -> head, head/dog -> dog and maybe head->part wheel/bicycle -> wheel wheel/car->wheel wheel->part etc.

good idea!

btw: the first version of the label graph editor is online: It's available here: https://imagemonkey.io/graph?editor=true

If you copy the current label graph definition (https://raw.githubusercontent.com/bbernhard/imagemonkey-core/develop/wordlists/en/graphdefinitions/graph.dot) into the texteditor and press the update button, you should see the current label graph.

some things I am working on at the moment:

• pan/zoom
• edge labels
• better error handling: if the graphdot representation contains a syntax error, you only see a toolbox popping up, which tells you to check the syntax. But there is no indication at which line the syntax error is.
• possibility to save changes: at the moment, all changes are gone if you close your browsers tab

[dobkeratops]

ok just tried it out, it is indeed interesting having a graphical representation to check

would it be possible to generate a label for unlabelled nodes automatically, e.g. foo->bar would create nodes foo[label="foo"] bar[label="bar"] if they haven't been defined, that would streamline adding a lot of subtypes (whilst still having the flexibility to highlight the major nodes with the full dot file syntax) What seems to happen is the dot language will indeed create nodes for each new symbol encountered, it's just it will leave it unlabelled (i'm guessing the symbols will require underscores instead of spaces)\ Alternatively, perhaps it could warn you about unlabelled nodes, then you can go and fill those in

I guess the actual label definition gives a place to define synonyms and translations?( which would be great)

[bbernhard]

would it be possible to generate a label for unlabelled nodes automatically, e.g. foo->bar would create nodes foo[label="foo"] bar[label="bar"] if they haven't been defined, that would streamline adding a lot of subtypes

interesting idea!

One thing I am a bit worried about however, is the ordering of those entries. I could imagine that (especially when the label graph gets bigger), one wants to group labels together (by separating the labels with spaces).

e.q:

food[label="food"]
banana[label="banana"]
apple[label="apple"]

car[label="car"]
bmw[label="BMW"]

If we are adding those entries automatically, they would appear at a random place inside the dot file. I could imagine that it could be quite hard to keep the overview when the label definition gets bigger?

But I definitely see your point here...the current solution is a bit suboptimal.

I guess the actual label definition opens the door to storing synonyms and translations, which would be great

totally agreed :)

Regarding the translations: Not sure yet, but maybe it makes sense to introduce translation files. In that case label graph maintainers design the label graph in some language (preferable english) and other people can can write translation (*.tr) files to make the graph available in other languages. That way the hard work of designing and maintaining a label graph needs to be done only once and not n-times (for every language).

[dobkeratops]

ok what i had in mind was making it add the labels after parsing parsing, however I can see having the definition actually listed in the dot file keeps it friendly for interaction with other tools

[dobkeratops]

(i suppose you could consider representing the graph another way, and just rendering that to dot-format for further visualization.. but I can see the appeal of storing a graph in a graph format from the outset)

[bbernhard]

(i suppose you could consider representing the graph another way, and just rendering that to dot-format for further visualization.. but I can see the appeal of storing a graph in a graph format from the outset)

also thought about that. But I can't think of any format, that would be better suited for the task. To me the dot format is almost perfect...but I have to admit that specifying the node is cumbersome.

I mean we can add missing node entries automatically in the backend after parsing, but the disadvantage is that we won't have a standard compliant dot file anymore. So if anyone wants to load this file with a dot file editor, it probably won't work.

Another possibility would be to add the missing node entries also to the dot file - but in that case the entry would be inserted at a random place inside the file (we could try to guess the best position, but it's error prone).

Would it help, if we define a shortcut for creating a new node? e.q if you press n on your keyboard, a dialog would pop up where you enter a name. The name would then be used to create a new node entry.

[dobkeratops]

yet another option... what about considering an un-labelled dot file as valid - and it just goes through a preprocessor before visualising (with the implication for other tools that they should follow suit). Then it's still a valid dot-file at all stages. regarding external tools .. I wonder how many other people would guess 'an unlabelled node should just use the node symbol as a label' (it seems an intuitive choice, and you can always allow an explicit label to over-ride)

[bbernhard]

I think you are right.

Not sure if the implementation at http://www.webgraphviz.com/ is standard compliant, but it looks like as they don't need a explicit node specification either. I'll have a look to see if I can make that work in a similar way :)

[bbernhard]

Ok, found the error. It was totally my fault...silly me messed something up ^^

I'll push the changes to production today (somewhere between 8pm and 9pm vienna time). :)

[dobkeratops]

ah awesome, I didn't realise it would allow quoted strings.. that makes it even easier. (e.g. we can infact create nodes like "head/dog" quickly too)

[bbernhard]

that makes it even easier. (e.g. we can infact create nodes like "head/dog" quickly too)

btw: the changes that i'll push later to production also contains support for edge labels. So it would also be possible to reduce head/dog to head and e.q add a has edge label.

I think both options are fine...so I guess it's just a matter of taste :)

[bbernhard]

The Label Graph Editor should be updated:

Changes:

• zoom/pan functionality
• support for edge labels
• directed edges are now represented with an arrow *
• with the len property it's possibly to specify the link distance between two nodes

*the arrows are sometimes not aligned correctly...still have to look into it why this happens

There are probably quite a few layouting bugs in there, but I think we should be able to catch them and fix them over time. The goal would be to layout the nodes and links in a way that the graphical ouput is of similar quality than the http://www.webgraphviz.com/ output - but with more interactivity.

[dobkeratops]

awesome, i'll give it a go

[bbernhard]

(Just realized, that the wikipedia page preview isn't working - at least in the graph editor mode. For me personally, that's one of the most interesting features; it makes browsing a big label graph so much more fun - and hopefully makes the layouting trouble worth it

When it's working, the wikipedia page preview can be set inside a node with the URL property

e.q: { r1 [label="r1" color=green URL="Orange_(fruit)"] }

Internally, the system queries the wikipedia API to get a page preview for the provided name. e.q: https://en.wikipedia.org/api/rest_v1/page/summary/Orange_(fruit)

When hoovering over the node r1, the page preview appears:

I'll fix the broken page preview with the next update :) ).