A way to preserve the thingness could be to keep only one set of attributes in the note itself (as in current TBX) – the alternative xpos,ypos do not have to be inherent to the note, they can instead be attributes of that new thing we are discussing.
When using the new thing, it pulls in everything from some container and overwrites the attributes for which it has its own version.
An analogy to this behaviour would be a mostly transparent cape, that you can throw over your item, to dress it up. You mostly see the original item, but on a few spots (where the cape is not transparent, but has some print on it), it covers the properties of the thing we dressed up. Any changes that happen to your original item can still be seen through the transparent parts of the cape.
When f.e. you color notes through the cape, you “paint on the cape” not on the original items – i.e. those changes become new/update values for attributes saved in the cape.
This is also similar to the way CSS is based around some idea of separating apperance/styling and content. There you can also cover the styling a page has on its own by injecting some custom CSS that will cover parts of the original styling. We could limit the attributes a “cape”/“diagram view”/“empty shell” (…whatever we want to call it) can have. Color, positions, shapes etc. can be saved in there – but anything that is more content-like in nature is not.
some thoughts on "real content" possibly being encoded in attributes considered "styling"
the line one can draw between what is styling and what is content is kind of tricky – one might have encoded content-like information in an attribute we’d consider styling, for example making all notes that represent objects of a certain class one color. Nothing one can’t get around using Prototypes for such distinctions instead however?
A bit more towards keeping ideas well-defined and seperated:
What I was going for in my original and also this post is different from what @entropydave was describing earlier here:
What he described includes changing the set of notes(or replicants of such) seen on the 2d-canvas. Though this could be worked into my “cape” idea as “well adding another note, or a replicant of one to the canvas is equivalent to painting that addition onto the cape” I did not intend that. I in contrast thought that the set of notes you see on the 2d-canvas is given by the original container – with that given, replicants are not needed.
Maybe this is a useful distinction.
Yes, this is an interesting alternative way of thinking about it. One way of conceiving it is that containers could have a modalising context, i.e. that they put the thing into a mode in which its properties are transformed. Within the mode that the container sets, some properties would be different.
If you want an analogy and perhaps a use case, consider three containers: Past, Present, and Future, in each there is the same entity, but some of its properties would be different in each container. These might be spatial (e.g. its home address) or they might be other ones (e.g. its age in years).
This is an interesting point Mark, but it does mean that you are thinking about a (software-based) entity as being a real thing because it has a spatial place. But place is not conceptually a spatial notion, there is also a place in time and a place in a hierarchy (and many other logical notions, e.g. a place in a sequence). If we take real people as an example of a thing, we can imagine that someone has three places, e.g. in the hierarchy of his genealogy; in the hierarchy of the org-chart of the job he has; and in the hierarchy of the Army Reserve in which he serves. None of these is primary I’d submit.
I would argue that the minimum you need for thingness is non-identity, namely that it be possible to distinguish one thing from another, and that seems only to require that two entities do not have all and only the same properties.
But you’ve been wrestling with these issues in Tinderbox for a long time and there is likely some other consideration I’m overlooking.
Thanks for your other comments. By the way, I love Chart View. Feature request: Now that we can select a series of notes in the Outline and edit any of them while they’re all shown, could we please have non-contiguous selection in Chart View plus editing of any one of the notes. I tried that in TB recently and it did not seem to work.
Perhaps we’re talking at cross purposes, maybe because I’m not conceptualising things hypertextually. If it were possible to address the linkbase in Tinderbox, e.g. LinkBase.contains(“inhibits”), then I would agree that there was one. The fact that they’re stored in one place in a file seems to me of no consequence: if TB were to store all the images that occur in the $TEXTs of notes in one place in the file there would not then be an “ImageBase”.
I have used most of the operators you’ve listed. Indeed, I may have been among those whose input shaped some of the demand for and implementation of those operators. See: How to create a label for link without creating link-type
Suppose I have a link type “inhibits” that describes an inhibiting relation between the ideas in two notes. And links of this type are used in various places. Now suppose I’d like to find all the inhibiting relations in my TB file. So far as I understand, I’d need first to collect all the notes with links using linkPath, then I’d need to iterate over all the notes returned, calling eachLink on each note, and iterating over each link to find those whose link type was “inhibits”. If there were a linkbase, I could query it directly, as in my imagined syntax above.
The first requirement is to be able to keep notes related to the link itself, for example explaining some details about what the link is describing apart from its link type. Today, we can do this with link notes, but so far as I understand it is still not possible to access or set the note text programmatically. We talked about it a bit in the thread above. Link notes are good, but just as $TEXT is better with attributes, so too would link notes be better with attributes. Again, searching against the notes in the link base is not possible.
If links were solely to facilitate hypertext, then there would be no need for what I’m describing. But it seems obvious from how others speak about links, link types, and the properties of links already existing that they are using links to encode information, knowledge, relationships, etc. not just connections to other notes. To give an example, suppose that you want to indicate that x, y, and z, are jointly sufficient to inhibit A (by jointly sufficient, you might substitute, A is inhibited only when x, y and z are present) it will not do simply to put a ‘sufficient’ link type between each of A and x,y,z because it is ambiguous in its meaning between any of x,y,z is sufficient for A and the case when they’re jointly sufficient. Moreover, suppose that A is jointly inhibited by x,y,z and a,b,c then six links of one type will fail to capture what is intended.
Now as Mark B noted, if you had links to links, you could then have inter-link links of type ‘jointly’ between x, y, z to indicate this. Or you could have an attribute jointWith of list-type that would hold the paths of the other notes (to include potentially those in other places in the outline hierarchy).
The problem can be generalised to any part-whole relation where as it were the whole adds up to more than the sum of the parts. In that case, simply knowing that x,y,z and are parts of A is not sufficient to know under what conditions A has the property of being whole. As I say, this can be generalised in more than one way. This is important for sequences too, e.g. x is only an inhibitor of A when y has been previously operative on A and then only when z has been operative on A.
There are lots of use cases for modelling the interactions of elements in a system, for when someone could or could not have known something, and more besides. I think I described some more I think in the thread linked above from message #32 onward. I believe I described some of the original use cases for replicants et al in this thread Hard Links and Tinderbox++
I’m not saying that one cannot bodge or kludge around the limitations of TB to do much of this, one mostly can but in ways that are fragile and require remembering how you did them rather than encoding their structure into the structures TB offers. You ask which PKMs permit what I want. None so far as I know.
At cross-purposes (unintentionally!)? I think perhaps so, as a lot of interesting suggestions need to start from a different place. Hypertext certainly doesn’t, generally, use anything but node to node links so branching/joining links might need a quasi note at the join and a means to map a link though that node.
Much of what’s being discussed better fits a drawing tool like Visio or Omnigraffle, or something more multimedia (in terms of content). Part of the problem, is we’re often working backwards from an imagined outcome to a non-existent start place, and (cross-purposes!) one then might not easily exist. Most make sense if the view is a diagram holding a user- (query?) defined scope of notes. There are unaligned/conflicting desires there. For instance, some want a diagram that doesn’t/can’t change except by deliberate user action on the diagram (essentially a re-editable snapshot). Others want same content/different render. Some want multiple visible renders of the same source notes but again with different styling, etc.
None of those, from what I know of the app, lend themselves to starting in a Tinderbox Map view, in terms of the underlying objects and how a map works. A map might look like what I’ll term a ‘diagram’. But, if I nest a note on a map it disappears off the map, something that is not wanted in a diagramming context.
I very much agree with it being desirable to ‘address’ (interrogate/edit in some facets) a link. Essentially links lack a GUID so that we know, especially in code, exactly to which link we refer. It’s actually doable today without such an ID with some code (except if there are two links between the same two notes and in the same direction and of the same type (which though possible in Tinderbox is functionally meaningless). Which isn’t to say it couldn’t be made more simple, but action code has strengthened markedly which makes me positive in this regard.
Good to hear of someone using those linking operators as all to often links seem to get treated only as drawing lines missing their greater potential.
linkPath("inhibits") returns a list all notes that have at least one in or outbound note of link type “inhibits”. Want to know inhibited notes only? Use linkedFrom("*", "inhibited"). Want to know inhibiting notes only? Use linkedTo("*", "inhibited"). I guess which you want depends what you intuit to mean "find all " as and how you imagine the resulting data to be presented to you. If you don’t want to use code, you can use Hyperbolic view and select the “inhibited” path. This causes only link paths of that type to be highlighted. Not possible at present but and already requested feature is being able to hide/filter out notes not on the ‘path’ (i.e. the link type that is the type selected). Hyperbolic view will be less useful if there are lots of “inhibited” links between links not otherwise linked to each other as the view’s original design is optimised for displaying (only) notes reachable via a link from a selected note. Unconnected notes or other link network with no connection to the current one are not shown in the view.
Effectively correct. eachLink() can read/report but not write a link comment† but as you note eachLink() is a cumbersome route to the info in this sort of context. This leads to a chick and-egg that such link-comments are little used as they are (programmatically) hard to access. Of course this is small beer unless it’s a key thing you are after!
Not quite, as linkPath() gives you all notes on the link type path whilst eachLink() iterates the links and can test for type. Given that now Tinderbox has functions you can parameterise this such that you likely only need to write the main code once and then use it as a custom action operator. I’m not suggesting this is the imagined answer or even an answer from your perspective but it might be interesting if you posted a small TBX including links with comments and a description of what you think you can’t do. Adding bespoke UI does need time/engineering cost (so ROI consideration likely apply) whereas I’ve seen additions/tweaks to action code appear quite quickly (for those on the backstage with beta access, very fast).
The don’t facilitate hypertext, they essentially are a hypertext. So, the type of link use you mention is conceptually very different. But it’s still PoV. Note A is capable of knowing if the list of notes linking to it (by specific linkType(s) if needed) contains x, y and z. Same outcome, it’s just assessed in the affected note rather than assessed in the link. This might also be usefully unpicked with a test TBX; not shirking the task but you’d need to make the TBX to ensure the scenario has the conditions for the assessment you believe can’t be made.
Aside, you might want to take a look at Flying Logic. It comes out of a very different place (enacting concepts from Goldratt’s Theory of Constraints) but it does have the sort of link annotation you want. Data interchange is poor IMO as the dev assumes [sic] his customers are mainly corporate with a programming department down the hall to do import/export in Python. But, FL might just fill a hole for you: the link joins and such might outweigh shortcomings elsewhere.
One bridging notion here, as has been posted before is that the join would be a special form of note: forget how it looks but think function and communication with the join. The issue isn’t the look but how the join is represented. In context, an agent is a special form of note [sic] but functioning quite differently from notes, a link join/split node doesn’t seem a big leap. I think the roadblock is as much about misaligned perspectives about the task. If the outcome is possible and can be archived with significant damage to other forms of use of Tinderbox, there seems room for improvements in the areas. Note I write this just as a fellow user, albeit with some deep knowledge of the app and how it currently works. I suspect a challenge in this area no one has touched on—as we all assume [sic] it ‘just’ works—is the signalling task and speed of response. I tend to be more cautious: I’d rather be surprised by a solution than disappointed by it.
Indeed. Whilst it is a thing we wish to know, is it a natural fit for an app that centres more on textual annotation and analysis. System modelling is a loose fit, though please don’t read that as being negative in intent.
I do think there are couple of things that may be more do-able (well, as described here) than supposed but really need a a reference document to anchor discussion (I suggest new threads if following up on that).
HTH
†. [Later edit] Comments will be editable via eachLink() from v9.6.0.
