Hi Tobias, thanks for the input. Let me answer some points because I think there is a misunderstanding here.
In general: You have to think of nodes like tiddlers and views like tw-filters. It is almost exactly the same. > To me, a graph displays relations between tiddlers and the overhead of > having to use dedicated tags to relate tiddlers to a given view seems > redundant, to some extend bloating a tiddlers metadata. > No metadata at all is stored in any tiddler. Edges are stored in dedicated json-stores for each edge-type and views are merely filters that select all tiddlers that match them. A view here is the exact same thing as a view in SQL or a TW-Filter: it is a precalculated select statement. At the moment, only tags are possible as filter, but I will add more ways to filter the graph. Everytime you create a clone of a view it is a clone of the current filter used. > So, my train of thought is... Why not keep those "graph views" as a > self-contained entities that are independent from the tiddlers they > represent, in terms of constraint requirements? > > Yes. This is already the way it works. Imagine a view as a tw-filter which will select the nodes it will contain. No tiddlers are actually linked to a view. They just match a pattern that is specified by a view. > While being able to filter a view based on tags sure is a great feature, I > would say that to actually model a view should not (necessarily) depend on > a given tag-filter constraint. Why? Because, at some point you eventually > may want a whole range of constraints, e.g. field constraints with tiddlers > having field x of value y or some value <= z, etc... or a modified date < > dadada. > > Makes sense? > Yes. I totally agree and you will be able to do that. If you open the debug console of your browser and search the through the debug output you will see a line that says "new filter string to accept or reject graph-nodes: [!is[system]!tag[tiddler-relation]tag[todo]!has[draft.of]". It is only at the moment, that the GUI is not done and every view filters by tags. *But theoretically I could also provide a textfield where you can manually enter a tw-filter.* > > Perhaps it's a question of how the workflow of modeling a graph is > envisioned. > > For me it's this: > > - define view (name ...may at some point even require an additional > category(tag) ) > - add / create nodes (easily select existing tids) > - add / define edges > > > So, these questions may be interesting to perhaps (re)consider... > > - What defines the set of nodes that are represented in a graph? > > In its core: a tw-filter, as complex as you want it to be. > > - Are edges part of a dedicated view? > > no edges exist between nodes and are only shown if the view permits it. that means: when nodes match the filter or when not filtered by a special "edge-filter". > > - In other words, do I want all edges in a view, just because some > (tag)filter expression says the corresponding tiddlers match? > > You can create use an edge filter that is also stored by each view. Its visible in the gui but not working yet. > > - Or: How could I make differentent kinds of edges appear in different > views with the same tiddlers? > > edge filter will be implemented next time :) > Right now, I guess, it is all set up such that the nodes and actions are > global, i.e. all views share the same underlying node-tree. > No they don't. They just pick the nodes (tiddlers) they want to based on their filter. Hope that helped. Please wait with in depth discussions when I published the code. Regards Felix -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+unsubscr...@googlegroups.com. To post to this group, send email to tiddlywiki@googlegroups.com. Visit this group at http://groups.google.com/group/tiddlywiki. For more options, visit https://groups.google.com/d/optout.
