auto-generated views for tagging / references about tw5-tiddlymap

[felixhayashi]

Hi @tobibeer,

this could allow creating some form of plugin that auto-generates / -updates a "tagging" view or a "references" view or preferably one containing both as different types of edges.

Yes, that's what I thought as well! @pmario mentioned this idea in a hangout to use an api on top of taskgraph to programatically create views based on the TOC or on tag-groups. I think my current implementation is a step towards this idea. I published the api docs here.

However, rather than having a monstruous graph of all tiddlers, one might just want to see x-levels deep starting from the current tiddler, i.e. the last one displayed in the story column / the last one clicked in taskgraph... so the graph would have some awareness of levels with respect to a centered / selected node or edge.
Such a view could be opened in a popup from a toolbar button at the current tiddler, so as to explore its relations, even navigate around...

It is funny that you say that because I am using taskgraph for a university project (going live in two months) and we thought of exactly that. I mean a view that always shows the neighbours of the tiddler that is currently focussed. My idea is that if a tiddler reaches a certain position in the storyList it is regarded as "tiddler in focus" and an event is triggered and the graph on the right displays all neighbours of this tiddler. I will upload a demo of this functionality soon. As you said, a button in each tiddler menu called "explore from here" or "show neighbours" is also possible of course :)

By the way, I really like your top navigation bar (tb5). TW5 should allow a top menu like yours optionally in every tiddlywiki. I guess I have to build it myself at the moment...

-Felix

[tobibeer]

I will upload a demo of this functionality soon.

This is very exciting news, Felix! Do you plan on making this graph "dynamic" in the sense of being able to center it on the next node, and the next node, and the next node?

By the way, I really like your top navigation bar (tb5). TW5 should allow a top menu like yours optionally in every tiddlywiki. I guess I have to build it myself at the moment...

Thanks. Beware that the css needs a some more polishing. I haven't gotten around implementing the calc() css stuff so as to have the bar on full width. In other words, it's not so pretty yet on mobile... but some day it hopefully will be :)

[felixhayashi]

Hi @tobibeer,

This is very exciting news, Felix! Do you plan on making this graph "dynamic" in the sense of being able to center it on the next node, and the next node, and the next node?

yap. I call it "diving" and I already implemented a short demo. Just go to the demo site open the editor on the right and go to the diving mode example view. the start double clicking a node. it will open the node on the left and as forthe graph you will "dive into" the node. this way you can even break your views boundaries and "dive" from neighbour to neighbour.

It's not perfect yet, I know.

I think this is similar to what you had in mind?

-Felix

edit also I have not yet implemented that the storylist triggers a "diving" in the editor. well I have to spend some time thinking how to increase the usability of this feature anyways.

[felixhayashi]

ok optimized the diving mode a little bit. there is now a surface button to quit diving

[tobibeer]

I think this is similar to what you had in mind?

As for the browsing behavior, indeed! As for what relations are shown... not yet, I assume. The relations would be dynamic in nature, i.e. all of tagging to, referencing, as well as tagged by, and referenced by... and maybe some future, generic relations not yet mentioned, e.g. things like listed by and listing?

[felixhayashi]

As for the browsing behavior, indeed! As for what relations are shown... not yet, I assume. The relations would be dynamic in nature, i.e. all of tagging to, referencing, as well as tagged by, and referenced by... and maybe some future, generic relations not yet mentioned, e.g. things like listed by and listing?

Ah I get what you are up to. My plan is to make the plugin extensible so in the end we can add the "dynamic edge calculation" as another plugin. But this is a great idea.

[tobibeer]

Needed to drop this here from Jermolene/TiddlyWiki5#1326 (comment)...

We need to distinguish two fundamentally distinct use-cases...

1. We model graphs that relate tiddlers.
   • with such a view, we model entirely independent relationships
     • different views of that kind are entirely independent, both in terms of nodes and edges
     • view foo could thus display relationships that view bar would never display
   • therefore, an update to the graph never updates a represented tiddler
2. We define a graph that represents (inherent) tiddler relations.
   • such a graph is completely tied to the underlying (standard) wiki relations, e.g.
     • tagging to
     • tagged by
     • linking to
     • linked by
     • listed in
     • listing
     • custom foo
     • inverse of custom foo
     • etc...
   • therefore, if such a view was editable, it would always update the corresponding tiddlers and their relations (which will work for things like "tagged" and "listed", but not "linked")
   • views based on this paradigm are not independent
     • if view foo updated relations also displayed in view bar, both would reflect the changes

[felixhayashi]

Yes. I call the first type of relations "global" or "shared" and the latter "private". TiddlyMap stores global relations in a central path "[...]/edges/" and local edges are stored in a subpath of each view like "[...]/view/exampleview1/edges/". This is a common approach used in unix (e.g. /usr/bin and /usr/local/bin). When using TiddlyMap, a user has to decide whether to use a global or private approach.

A use case for private edges is e.g. isolated mind maps: No global edges are displayed and on the other hand the private edges are nowhere else displayed (not spamming the global edge pool).

If the edges should be displayed everywhere because they, as tobi puts it, describe the "(inherent) tiddler relations", then a global mode should be used.

Only one addition:

different views of that kind are entirely independent, both in terms of nodes and edges

The problem is that tiddlywiki cannot create nodes with the same name, so independence of nodes is hard to achieve as we cannot create nodes with the same name. Even when using captions, a node is bound to a tiddler and the tiddler is global so I cannot prevent that a tiddler appears in another graph context if it matches the views filter.

-Felix

[tobibeer]

The problem is that tiddlywiki cannot create nodes with the same name, so independence of nodes is hard to achieve as we cannot create nodes with the same name. Even when using captions, a node is bound to a tiddler and the tiddler is global so I cannot prevent that a tiddler appears in another graph context if it matches the views filter.

Of couse, I was not implying to have different nodes, that is correct. Luckily, edges are not (yet?) top-level tiddlers. What I was implying was that how those tiddlers are displayed in such a graph is independent from that tiddler, in all regards, thus edges and node properties relating to a tiddler but not persisted at it.

For example, if such a graph allowed to enter some additional "node-note" then that note would not be stored at that tiddler but rather in some system tiddler with respect to that "private" view along with any other properties, such as icons, colors, etc...

However, when we're looking at a "global" view, we're looking at that very tiddler, so any modifications and additions we do for that tiddler should probably be stored at that very tiddler or stored in a way that any other global view refers to the very same globally accessible information.

Personally, I think the amount of graph-data that is dumped on actual tiddlers should be as minimal as possible, if not non-existent. Only global relationship-stuff should be directly persisted at a tiddler, e.g. making an actual tagging relation.

[felixhayashi]

Yes, I agree. Only stuff that would also play a role if the plugin were not installed should be stored in tiddlers. For example I would never store position information or something in a tiddler.

[tobibeer]

@christophvarga, would it be ok for you to link to those images instead of embed them?
They don't seem to directly relate to the issue.

[felixhayashi]

Hi @christophvarga,

as follows some further thoughts on the map-view

I am sorry, I didn't quite get your point. Also why the blockquotes and why is some of your text italic?

i did a research and here is a list of graphic and information designers from students to agencies wich adressed me by their work. maybe one of them like to contribute to this project?

What do you mean by adressed me by their work? Do you correspond with the authors? And why do you ask me if they would like contribute, I don't really know them...

here are some examples i came to

What is the meaning of these examples? I mean, I know what cluster networks and graphs look like...

Maybe you could clarify this or open a new issue.

-Felix

[pmario]

@christophvarga
As Felix pointed out, please clarify. ... IMO this is spam and should be removed.

[tobibeer]

if this post is not in place here, where should it be moved to?

Make a new issue with a well defined purpose and scope... to open up discussion.

[felixhayashi]

@christophvarga,

it's nice that you want to help but I think Mario and Tobias are right. Please be concise about your suggestions and create a new topic for your thoughts and do not make such big posts, it's hard to read and understand.

and these are only contacts i found so if there is any interest in working together with an graphic designer i am shure one of them could be interested in contributing to this project. ?

It's not necessary to reference people that are professionals with visualization software. Unless I ask, I don't need help with that.

you offered me in an other issue to contribute to the graphic style of the map.

Then I certainly meant that if you have any specific ideas how to improve TiddlyMap, you could open a separate issue on that while clearly explaining your point.

-Felix

[tobibeer]

I am beginning to think that — next to global and private edges — these are a third type of edge, call them "system" or "dynamic" or "computed" edges. They are dynamic in the sense that instead of querying any stored TiddlyMap node-relationships, you call core functions (or functions calling core functions) that create the relationships via predefined queries.

So, you would have helper functions for directed relationship pairs, e.g....

• taggedNodes(tiddler) — tagged

• taggingNodes(tiddler) — tagging

• referencedNodes(tiddler) — referenced

• referencingNodes(tiddler) — referencing

• listedNodes(tiddler) — listed

• listingNodes(tiddler) — listing

• etc...

In some ui you would tick off each of these implemented auto-relations. Once activated, the view would call those funtions to query relationships rather than the generic ones you use to store otherwise persisted, default TiddlyMap relationships. (Sorry, haven't yet taken a closer look at the code). The key is to reroute that query to something dynamic and maybe later even respond to updates to the store accordingly and update the graph when a tiddler gets a new tag or link, etc...

These edges really only exist at the moment the graph is drawn and are not otherwise persisted or editable via TiddlyMap (, except perhaps tagging).

[felixhayashi]

Hi @tobibeer,

what you describe makes perfect sense. This is actually how "display neighbours" works (see node filter in editor). "display neighbours" is dynamically calculated and not based on any filter. So I think it should also work for the scenarios you described (of course, I need to write some code, but it is the same idea). It is good that you listed some examples above, then I have some orientation when I actually implement it.

-Felix

[tobibeer]

Perhaps a good starting point on how to gather such tiddler references in a function call is to take a look at the corresponding filters.

[rcrath]

@felixhayashi , Am I correct in understanding that tags do not show up in live view unless they have a tiddler with the name of the tag as its title that has content in it?

[felixhayashi]

@rcrath, yes correct!

I cannot show nodes in the graph that do not correspond to an existing tiddler. Therefore, the tag-link is only displayed if it points to an existing tiddler.

[rcrath]

@felixhayashi THnx!

[tobibeer]

I cannot show nodes in the graph that do not correspond to an existing tiddler. Therefore, the tag-link is only displayed if it points to an existing tiddler.

May I ask: Why? ...or can you not do without and apply some fallback info for tids that don't exist, like a missing tiddler link does?

[felixhayashi]

It's not that it is not possible, it is just that this premise "a tiddler has to exist in order to be displayed" is essential to many operations. This made/makes it easier for me to develop the plugin.

For example I always operate on ids. Once the graph is drawn, I expect all nodes to have ids that correspond to tiddlers and all of the various user actions trigger handlers that expect the nodes to relate to a real tiddler. It would require a huge effort and much concentration to implement checks everywhere, whether a tiddler really exists.

But I also think it would be nice to allow showing nodes even though the tiddler does not exist. Maybe I can add this in the future at some point when I have more time :)

[tobibeer]

It's not that it is not possible, it is just that this premise "a tiddler has to exist in order to be displayed" is essential to many operations. This made/makes it easier for me to develop the plugin.

I understand, you would need conditionals in some places so as to have a tiddler created before you can modify / add properties.

Or there would be "not editable" nodes, or some way to have the user "create first"... so they are aware that here we have a node that ain't a tiddler yet.

I understand, all that may require modifications to the ui.

Not sure what your code will do if a title won't return an id => perhaps the error handling can do the rest of interpreting something as being a missing tiddler.