I would like to display text (~5 words) on top or adjacent to a link (in Map View). Is there such a thing as a link label or caption — a light-weight alternative to link-type?
I am aware of two ways to get the intended effect, but both have drawbacks:
define a link-type. The link-type appears as a label next to the link. However, the label I have in mind is not as significant as a link-type. I tend to reserve link-types to convey more significant and broader meaning, e.g., “contrast”, “exception”, “supporting evidence”, etc. The label I have in mind has a narrow scope and is a one-off annotation that is unlikely to be used outside this map (in a TBX file with hundreds of other maps).
create a note adjacent to the link. The issue here is that the note cannot be pinned to stay with the link, as far as I can tell. If the link is redrawn or moved, it will leave behind its label.
There is no “label” for link lines. That would be a new feature. An email to bernstein @ eastgate . com explaining the use case would help formalize that request.
But, in the interim, isn’t a label and a link type semantically the same? If you want to put “meaningful” and “minor” link types into different buckets, you might consider a simple private grammar such as prefixing “meaningful” links with “*” or some other indicator.
I’d agree with the last, why not add a link type. I think it’s worth pointing out Tinderbox isn’t a drawing tool like Omnigraffle or Illustrator, where the outcome is all in the visual.
Is a new link type so hard? I can see that this scales badly if every note has its own link type. But, if you are writing a short sentence (or paragraph) on link intent, what not link to a note with that as the title or text and then link that to the target note, if map-only visibility is the aim. Otherwise I’d re-visit link types that maps are only one of the ways to look at your data in Tinderbox. Where would this extra info show up in other views? I note that not to devalue work done in map view , but many mature docs then need to do other things like create long-form text output, or export metadata; how would such data be accessed outside map view? Tis doesn’t argue against the idea, but if worth doing, it’s worth doing properly, so access outside map view is a point that needs addressing.
Links already support per-individual link metadata. Perhaps that could be shown as a tool tip, as more than one or two word labels make dynamic views like Map view rarther busy and hard to read (recall: this is not a drawing tool like Illustrator or Omnigraffle where output is static, and essentially a proxy for print).
Attributes belong to notes, and link comments of course belong to links. So you’d need something like
links.outbound…$Name
which would give you a list of link comments on outbound links. But that won’t work to set link comments, since we have no way to specify exactly which link we want to change.
@mdavidson, hey there. I’ve been doing a lot of exploration with links lately. Can you explain what you mean by “link comment.” Link Types are really powerful, as you can use them to pass attribute data back and forth between notes. If I can get a better idea of what you’re looking to accomplish, maybe I could help. For example, I think you might be able to accomplish what you want to do with a combination of queries and stamps pretty easily. Would love to explore this with you.
Thanks @satikusala - I agree with you on how useful links can be and this is one area in TB that in my opinion could be expanded in the future fairly easily.
However, I think it’s tricky if not impossible if there is no action code that provides access to the link comment information. As @eastgate pointed out links are treated differently from notes - unlike notes there are no attributes to retrieve for links. Here I’m talking about the classical internote links - links within the $Text (zip links?) field are visible in the text and can be manipulated there as I’ve found out in a recent parallel thread.
It would be nice if there were programmatic access to links, something like this:
mySet = someNote.linksPropertySet
where the value assigned to mySet was a set of link properties. These could be accessed by offset or by some name-value pair scheme. If by offset, new properties could be added to the end to retain backward compatibility. This would not make links first-class objects, not least because there would be no assignment mechanism for link properties, but it would probably increase the extent to which the relation of being linked could be made semantically powerful. Link comments could store attributes peculiar to the link.
That said, without the ability to alter link comments (or link types) programmatically, it might not be worth the development effort.
It is not that they are treated differently, they are different. I suspect you’re using HTML as a model, but the the Web is just once form of hypertext and only a partial implementation due to technical constraints at the time of its convention. Embedding links into text was one such compromise.
A more normal hypertextual model is to store the links separately from the notes they link, in a linkbase. That is the model Tinderbox follows. If you look at the raw XML of a TBX file you will see that links are stored as discrete <link> elements within an enclosing <links> element and the latter is discrete from the stored notes. The link’s info included the character offsets (in plain text of $Text) of the link anchor and the IDs of the source/destination notes plus any further customisation—such a per link notes. For basic-type (i.e. note-to-note) links no anchor is recorded as it is not needed.
The reason I describe this is building out from a wrong assumption generally only compounds the mismatch between reality and aspiration. The issue is at hand is as much one of addressing the correct links as it is the means of doing so (action code, AppleScript, whatever). The latter choice is thus moot if the former is not resolved.
It is worth bearing in mind that a pair of notes can be linked by more than one link of the same type. Any such issue above must address this extra complexity. A model of a two notes with a single link (or single link per link type) would be too simplistic.
`classical’ in what sense? My notes above would suggest this too is a description based on a mis-understanding about how these systems (can) work. There isn’t a unified model (thuogh that was attempted by the hypertext community before the world just chose the Web’s mote limited model instead).
The note you describe is one of the two described link types for Tinderbox (three if you count out-of-app ‘web’ links). In this instance you refer to ‘Text’ links, as opposed to ‘Basic’ links. this is unsurprising as in general use a Web document only has ‘Text’ links as any links have to be embedded into the HTML source of the document.
‘Zip links’ is a further confusion. A zip link in not a type of link, it is simple one method of creating a Tinderbox ‘Text’ link. Calling zip-links a type of link mis-presumption and a path to confusion. This is exactly the issue that led Key Attributes to be renamed recently as Displayed Attributes, precisely because users started ascribing all sort of assumed characteristics to them based on … no real understanding.
How. Once the zip-link method has been used to make a Text link, you have a text link which is no different to those Text links created by other methods. Again, there seems to be a misunderstanding here as to how links work in Tinderbox.
Tinderbox sets are normally lists of strings. This query seems to be asking for an N-dimensional array, which is a coding construct not found in action code. In fact you need a more complex method to filter one or more of:
link type. A note can have both basic and text links(s) to any given note. You presumably only want one.
for text links, the link anchor text. One $Text can have multiple links to the same target and these can even have the anchor text (they are unique per the character offset of the anchor text within $Text.
destination. You may have otherwise similar links that differ only in their destination note.
link styling. You may have two links differing only in style.
presence of a link free-form annotation. Not all links have these. Currently you can only set or view these via Browse Links or a stand-alone Roadmap window.
direction of link. By Tinderbox convention notes are unidirectional. Working with inbound links would liekly add further processing.
The simple case of Note A with a single text link to Note B is not rich enough to define the use case here. Also unclear is the nature/complexity of per-link free-from notes. The existing feature was added without (I’d assume) the intent of programmatic access. so, having decided which annotation we want, we also need to consider how the contents might get mis-read. If annotation content is not more closely defined doubtless someone will want to put action or export code that and want it rendered on access—if only because no one has said they can’t.
Given how Tinderbox uses a linkbase external to notes rather than Web-style embedded links, I think link annotations want some careful thought and discussion before rushing add new features to them.
None of this is an argument against link annotations. But, to be useful, they need to be considered from within the context of the app’s existing design or the outcome is likely lots of effort for a sub-par result.
While I am quite sure that one can effectively produce the required data structure using strings and some index or namespace for values, your points are well taken in suggesting that this would be something of a bodge, take a lot of development time, and be of limited value.
Some time ago I made a remark about making links first-class objects which I seem to recall was not well received. I will make the point that lay behind that request which is that relations between notes (or nodes) can be informative. That is why people find the containment hierarchy informative and why many want to take the spatial relations between notes to be informative (no doubt this is a reason TB offers easy ways to align or distribute notes). As it were, the relation of being to-the-left-of can be informative, just as the relation of being contained-within can be.
If links were programmatically addressable and adequately extensible to allow individuation as well as assignment to kinds, then there would be a framework that allowed users to create arbitrarily many meaningful kinds of relationship structures. That is to say, it would create a framework for relations generally (one might say logical relations) rather than a restricted domain of such relations.
To give a trivial example, suppose one were modeling access to resources. Inbound links to a resource might show that access was possible, but a variety of kinds of links could show whether it was physical access, another whether it was remote access, escorted access; or whether access was restricted to set intervals of time; or which conditions had to be satisfied before access was possible, and so on.
That said, it is possible to do this using attributes in the nodes, but a richer link architecture would increase the affordances for doing so.
From the questions I see on this forum, one can infer that people are trying to use links to scratch itches of this kind. (Some questions relating to the use of adornments and smart adornments seem to me to point to related impulses to create additional informative hierarchy relations.)
I’m absolutely with you on the aspect of capturing link intent. The problem is not a zero-sum issue, as I’ve tried to show above. I do think there is a valid consideration about whether the current architecture is the place to start, which itself is not a zero-sum judgment on the app. IOW, to get to there, is here the right place to start.
The example in your second paragraph, about modelling access, is do-able now as Note A can link to Note B in multiple link-typed was, a relationship that is accessible to action code.
Link Types were a thing and then sort of got kicked into the long grass in the late 1980s. The now suffer from a slight chick-and-egg loop where we don’t see their potential as we don’t have the right (rich enough) tools to exploit them, so don’t use link types, etc.
I totally accept there is a difference between a link type, which sensibly wants to be short/descriptive (even if only for easy use in code), and a more fulsome distribution of the rational for the link’s choice of link/type. Still, making greater use of the existing features may help given a better fix on how best to (possibly) implement the richer form you describe.
My experience, to date, has been to push data to attributes (ironically, I don’t use $Text much in my own Tinderbox work) which allows me to get at it via action code or other means without having to trawl everything from $Text using regex.
So, I think we’re actually on the same page here lest it appear otherwise.
Yes, I can see that we’re on the same page. And I hear what you say about whether this is the right place to start. I’d really love to have this in Tinderbox because Tinderbox is the only application that comes anywhere close to having all the other parts of the solution for this kind of work. Or, I don’t know of anything else, except the now departed Hypercard, that provides anything like the combination of action code and attributes for notes that Tinderbox does. Thanks for your responses.
You’re right to think that I missed those debates and so I probably am missing some subtleties.
My first thought is that what is needed is a way to hold a persistent reference to a link so that one can query it for identification or for assignment of values. So obviously a simple solution is simply to have a link data type to hold such a reference. I can see that is probably a major intervention.
Isn’t the problem you describe in the first syntax example a bit like the problem of finding which of several immediate children of a note you want to modify? To solve that we might make a list of the names of all the children, take a count of the number of elements in the list, then use the count to parameterize a control structure so that we can iterate over the list to find the index of the note we want, then we use that index to access the child we want. The advantage of the note is that we can then derive the full path to store as a persistent reference.
So if we had index access to links as in your first example syntax, we could replicate this pattern for finding the link we want. However, without a link data type we could not save a persistent reference. One solution would be to give links a unique identifier attribute and then make a UID an alternative parameter for Links() access. This would have the additional advantage of allowing reference to a link without needing the note path.
When you ask about the second example syntax, “But what if there are two such notes?” I take it you meant, what if there are two such links? I see the problem and agree with what is implied that there is nothing about the characteristics of specific links that allows us to identify one as unique (eq vs equal). Again, a unique ID would solve the problem. However, I do not know how much of an intervention this is.