3 ms·

I think the main problem with using non-tree graphs isn't the choice to use the graph; it's the lack of definition for the edges. Most people, when they first r

I think the main problem with using non-tree graphs isn't the choice to use the graph; it's the lack of definition for the edges. Most people, when they first reach for a non-tree graph, choose to weaken the definition of the edge even beyond what is implied by tree edges, which usually means "owns" or "contains" or the like. By default, an edge in a non-tree graph simply means "relates to, somehow". And a beginning user faced with a bunch of nodes are just going to draw a bunch of lines between topics that seem to tangentially relate to other nodes, until they get the big hairball. If, however, you get stricter about the definition of the edge in a graph, they're superior to trees in many contexts. An edge might mean "predates", or another edge might mean "implies". Those are the two main definitions I use, because when needing a graph I'm usually either thinking of planning (prerequisites, when some things need to be done "before" another), or I'm thinking of arguing/concluding (where some things when combined "imply" a conclusion). It doesn't really work to conflate the two. You can also combine multiple edge definitions into one graph, and maybe it'd look like a hairball if you're displaying all of them at once, but if you filter it gets more useful. Two more things... graphs almost always, in my experience, are more visually useful when they are directed, whether acyclic or not. Radial just doesn't seem to have much added benefit. And, a pet peeve is mine is when people use radial UX to display a tree and then call it a "graph". I know, it's a picture of bubbles and arrows, so it's a "graph" in that sense, but most bubble graph software doesn't even support graph data structures. If you grab one bubble and apply gravity, it just shakes out into a tree.

Lichtso 3y ago
Oh yes, edges of different types and their direction are definitely what the author of the post was missing. This is precisely where triple (hyper) graphs and the idea of semantic networks comes in. Unfortunately, the designs, architecture and implementation of the semantic web are all completely impractical garbage. I did a lot of research on rendering ontologies and in general the best way to do so is not at all. Instead try to do domain specific bijective projections (akin to DSLs). And if you really need graphs do not render the edges. It always leads to chaos, it is better to show all vertices and only display edges on request (e.g. on hover).
- gwervc 3y ago
  I wrote a dictionary system based on graph, the graph itself isn't being displayed. I agree RDF is garbage tech, it's easier to do something without it. The solution is came with to display content from a given node is first to group neighbors nodes by the type of their relationship. Each vertex and relation type has a dedicated component for display and if not, uses a default one. The display order of relationships is set with configuration. It very simple yet powerful system, that was implemented on mobile and web. I've prototype of very cool stuff (like a Chinese dictionary, and another multilingual one) but none very completed because most of more senior researchers I worked didn't see the point.
- davidy123 3y ago
  Your approach doesn't apply to the semantic web. Apples and oranges. Two dimensional non-tree graph are neat but in most cases at best a debugging tool or whirlygig.
  - Lichtso 3y ago
    > Your approach doesn't apply to the semantic web. Not sure which approach you are talking about. > Two dimensional non-tree graph are neat but in most cases at best a debugging tool or whirlygig. That is what I was saying. Layouting and rendering general case graphs is a mess.
    - davidy123 3y ago
      I mean semantic web is designed to turn the entire web into a semantic database. You could treat "your" parts of the web as DSLs in the simplest possible RDF/linked data and then link it to semantic web concepts (and other people can link it as appropriate), but I don't think you can create anything like a semantic web with standalone DSLs. > That is what I was saying. Layouting and rendering general case graphs is a mess. Yes, unfortunately and somewhat ironically since the web is a non-tree graph.
ivancho 3y ago
Knowledge graphs are traditionally collections of triplets, 2 vertices/entities plus edge type/relation. They are vastly superior to trees for data representation, but are completely useless for visualization. There is no meaningful question that can be answered faster or better by looking at the drawn edges - just print a list of entities and add hyperlinks.
- tunesmith 3y ago
  There are plenty of meaningful questions that can be answered by focusing on one edge meaning at a time, though. Call graphs (edge: this calls that), pert charts or dependency charts, (edge: this is required by that or this enables that), recipes (edge: do this before that), arguments/conclusions (edge: this premise combined with that premise implies or justifies that lemma), etc, etc. All of those are very useful to look at visually.

Lichtso 3y ago

Oh yes, edges of different types and their direction are definitely what the author of the post was missing. This is precisely where triple (hyper) graphs and the idea of semantic networks comes in. Unfortunately, the designs, architecture and implementation of the semantic web are all completely impractical garbage. I did a lot of research on rendering ontologies and in general the best way to do so is not at all. Instead try to do domain specific bijective projections (akin to DSLs). And if you really need graphs do not render the edges. It always leads to chaos, it is better to show all vertices and only display edges on request (e.g. on hover).

gwervc 3y ago
I wrote a dictionary system based on graph, the graph itself isn't being displayed. I agree RDF is garbage tech, it's easier to do something without it. The solution is came with to display content from a given node is first to group neighbors nodes by the type of their relationship. Each vertex and relation type has a dedicated component for display and if not, uses a default one. The display order of relationships is set with configuration. It very simple yet powerful system, that was implemented on mobile and web. I've prototype of very cool stuff (like a Chinese dictionary, and another multilingual one) but none very completed because most of more senior researchers I worked didn't see the point.
davidy123 3y ago
Your approach doesn't apply to the semantic web. Apples and oranges. Two dimensional non-tree graph are neat but in most cases at best a debugging tool or whirlygig.
- Lichtso 3y ago
  > Your approach doesn't apply to the semantic web. Not sure which approach you are talking about. > Two dimensional non-tree graph are neat but in most cases at best a debugging tool or whirlygig. That is what I was saying. Layouting and rendering general case graphs is a mess.
  - davidy123 3y ago
    I mean semantic web is designed to turn the entire web into a semantic database. You could treat "your" parts of the web as DSLs in the simplest possible RDF/linked data and then link it to semantic web concepts (and other people can link it as appropriate), but I don't think you can create anything like a semantic web with standalone DSLs. > That is what I was saying. Layouting and rendering general case graphs is a mess. Yes, unfortunately and somewhat ironically since the web is a non-tree graph.

ivancho 3y ago

Knowledge graphs are traditionally collections of triplets, 2 vertices/entities plus edge type/relation. They are vastly superior to trees for data representation, but are completely useless for visualization. There is no meaningful question that can be answered faster or better by looking at the drawn edges - just print a list of entities and add hyperlinks.

tunesmith 3y ago
There are plenty of meaningful questions that can be answered by focusing on one edge meaning at a time, though. Call graphs (edge: this calls that), pert charts or dependency charts, (edge: this is required by that or this enables that), recipes (edge: do this before that), arguments/conclusions (edge: this premise combined with that premise implies or justifies that lemma), etc, etc. All of those are very useful to look at visually.