I believe this question has been asked elsewhere before, but it would also fit here: It is (not) possible to filter by link type or to have, say, agents perform an action based on a link type that connects multiple notes. Correct? Maybe @echuck in his great Diagram View Kit. @mwra
Agents collect notes that match their query. But an agentās action is free to do whatever it likes.
An agent could, for example, look for notes with the prototype āUS Presidentā. Its action might see whether the original note was linked to āWhite Houseā with a link of type ādemolitionā.
3 Likes
nice @eastgate
And: In Tinderbox, how would I display all the notes that are linked with the link type ādemolitionā? Can this be done using an agent or through Table View or ā¦?
The most obvious approach would be to collect them in an attribute ($MySet?) of the agent. But you could create notes inside a container for use in TableView if that was desirable.
1 Like
There are several parts to this: how to achieve the filtering and then how/where to view this.
The first involves a query, either in an agent or using action code to collect a set of note reference. The second relates to how the user wishes to see the notes/work on them.
To add to the answers above, there is a listing of action operators (as might be used in a query): Linking operators.
This all makes sense, @eastgate and @mwra. Thanks you.
I consider this topic to be so central that I would like to work through it systematically. Starting with filtering and then interacting with the filter results. What would be the best way to begin with this? The goal is, in the end, that I am able to select a link type and have it display which notes are connected to it.
With Hyperbolic View, we are already quite close. And filtering by link types can also take place here. Great. However, as the name suggests, a link type is just a type and thus a general pattern, whereas a specific use of this link type to describe a specific relationship between a Node 1 and a Node 2 or a Node 3 and a Node 4 should be understood as a token of the link type. And I want to be able to call up exactly this token myself as a kind of note, in which I can jot down descriptions and content, etc. So probably more or less what seems to have already been asked in this thread.
Was I able to make myself clear?
Iām not entirely confident I understand what it means to ābe understood as a token of the link type.ā
I had the same confusion as above. It is worth noting that:
- a link has one, and only one, link type.
- two notes can be linked by multiple links, each by a different link typeā .
So if the ātokenā idea is like links for tags ā¦ from this is flawed approach, at least without new engineering.
I think what is at play here is how we individually approach the task if filtering. I see two differing yet equally understandable approaches:
- Visual. I start with a view (whichever view) and 'filter it until the the results look right
- Analytical. I start with an idea of what describes what I expect to filter out and then design a query to draw forth the expected result.
Iāve noticed A lot of questions here are, or tend to be, couched in the first form yet often the questioner has already has all the necessary info to enable the second, in terms of the query needed. I wonder how best to nudge people towards the latter as it offers far more in terms of learning (for future problems).
ā . Actually, you can have multiple links between the same note and with the same link type (I just checked in v11.0.1). Yet, what would be the point in so doing?
Iāll try it with just a flowchart. Maybe it will become clearer what is meant when the attempt is made. For example, being able to link a Note to a token of a link type, to emphasize that a token of a link type is itself a kind of note, which, as a token, is an individual of the more general link type.
Thank you for the above, but in terms of existing features, what is a ātokenā?
Links in Tinderbox are stored, after the hypertextual model, separately from the notes (see more). A link has a number of fixed attributes some of whose values reflect user settings but most of which canāt be set directly by the user. More importantly there are no additional user defined link attributes.
The latter is what this ātokenā concept seems to assume. But such does not exist.
In your model (screen grab above) āToken #1ā and āToken #2ā could be enacted as link types but not as ad hoc properties of a link type.
I sense you may be wanting to have links be first class objects (āNote 5ā appears to target another link). Is this the case? I ask is it is a non-trivial design change.
Iām interested, can you describe what practical problem token resolve that can only be resolved this way? I ask so as to understand whether the underlying issue is Tinderbox doesnāt support your imagined/preferred way of working or whether there is a type of problem it cannot resolve.
Indeed: It is, of course, about first-class objects. I understand that this is not currently a feature set in Tinderbox. However, it emerged organically from the discussion linked earlier in this forum, and thatās why I wanted to lay it out explicitly here again.
Iād be happy to try to outline the added valueāin the hope of making it understandable:
This perspective opens up powerful new possibilities for knowledge work. It enables meta-discourses where we can discuss not just the content of our arguments, but their very structure and architecture. We gain the ability to recognize patterns by identifying which types of relations appear frequently throughout our knowledge base.
This approach also facilitates quality control by making the logical connections themselves observable and analyzable. We can systematically review whether a ācausalā link truly demonstrates causation or merely correlation, whether an āevidenceā relation actually provides sufficient empirical support, or whether a ācontradictionā is genuine or based on a misunderstanding. By treating these connections as objects we can annotate, question, and refine, we create a self-correcting knowledge system where the strength and validity of each argumentative bridge between ideas becomes transparent and open to scrutiny.
Most importantly, it transforms our simple networks into complex knowledge systems where we move beyond basic AāB connections to include meaningful statements about those connections themselves.
This represents a fundamental shift from simple hypertext to genuine knowledge graphs, where relationships are elevated to first-class knowledge objects in their own right.
1 Like
Thanks, that is most helpful in teasing out some detail.
Links as first-class objects, are not an option at presentāor such is my understanding. However, structural issues aside, there are two available approaches to the level of annotation you seek:
- use multiple links of different types. Tinderbox has no fixed limit in the number of link types in the document so adding a link type as a gloss to another link type is possible. In this method, notes A and B would be linked by all necessary types.
- Thinking forward from the data as opposed to backwards from the imagined UI, would help here. For instance:
- a Map view based user might choose to have visible the āmainā link types and hide the glossing link types.
- in Hyperbolic view the link types could be toggled on/off as needed.
- Thinking forward from the data as opposed to backwards from the imagined UI, would help here. For instance:
- use link comments. Although a single free-form text element it could be used for token values. Not immediately queryable via the likes of the
linkedTo()operator, etc., once (source notes of) links of a certain type have been filtered by query, eachLink() can be used to access and process the comment.- Links comments go back some way and were, IIRC, a way of capturing per-link (as opposed to per-link-type) informations. But, until the advent of
eachLink()they were somewhat hard to access other than via Browse Links.
- Links comments go back some way and were, IIRC, a way of capturing per-link (as opposed to per-link-type) informations. But, until the advent of
Iām not suggesting these are as simple as the model you propose. But given the degree of engineering implied by the latter method (including consideration on all other facets of app use) the above may be a practical approach at present (v11.0.1 at time of writing).
I hope that helps bridge the current feature āgapā. 
1 Like
Thank you, Mark. That really gets to the heart of the matter, and I understand that, as I envision it, itās not currently possible. Your workaround suggestions provide approaches to still handle it productively. Thanks.
1 Like