Aliases and Hyperbolic view

I am trying to work out how to organise my document into topics, where there are links between notes in different topics. Where a Note is relevant to Topic1 and Topic2, the obvious solution seemed to be to have the original note in Topic1 and to put an alias in Topic2. I expected that when I entered Hyperbolic view, they would be treated as the same Note, and Hyperbolic view would connect the networks in both topics but it does not seem to work like this. Have I missed an option such as “Treat aliases like the original note in Hyperbolic view”? Or or is the best solution to create a type of link such as “Identity” and to link a Note to its Alias as soon as the latter is created? If I decided to do that, could I create a Stamp which said, “Create Alias and link to it using Identity”?

(I have not yet worked out how to edit the list of link types, but I am assuming I will find the method and it will be straightforward.)

See the Document Inspector > Links tab.

Thank you. It should have been obvious.

On aliases and links see here and here. Reflecting one of its early roles as a blogging tool (and so exporting HTML) alias link logic supports that. Thus aliases:

  • outbound links:
    • text links. Aliases always share their originals links.
    • basic links. By default, aliases share these with the original unless/until the user adds an outbound basic link from the alias. Think of it akin to attribute value inheritance: the alias inherits outbound basic links until it has some of its own and which point the two have discrete sets of links.
  • inbound links: these always only point to the original. However, the alias can receive its own discrete inbound links though these need to be created new for the alias (i.e. added after the alias is created).

No worries. Much of Tinderbox is below the waterline.

I am not sure I understand all of this (in fact I am sure I do not) but it sounds as though the solution for what I want is to create links between notes and their aliases.

Is it possible to create a stamp that creates an alias of the selected note, and also creates a link of a certain type to it? Insurance against creating an alias, moving it to a container, and then forgetting to create the link!

Not using action code as there is no means (out of an abundance of caution) for creating an an alias.

Action code has no means to create an alias, but if the alias exists we can link to it. We can also defined the link type used though as at v8.6.2 that designated link type must already be defined for the current document.

So, latter in mind, add a link type ‘alias’ to your TBX. Then add this stamp, calling it “Make alias link”. with this code:

linkFrom(find($OutlineOrder=($OutlineOrder(that)-1)&$Name==$Name(that)&$IsAlias==false),"alias");

Now the drill is two steps:

  • Select your note and use Cmd+L to alias it. The alias it created and selected. With the alias still selected…
  • Use the stamp “Make alias link”

Hey presto, your alias now has a link from the original, to the alias of link-type ‘alias’.

How does this work? We know we want to find() the alias’ original but preferably without checking every note in the TBX. We know a new alias is added to the next sibling of its original note. therefore the find() query is:

  • is the tested note the previous sibling of the object (here, the alias) running the query
    This should find the right note but two other fail-safe checks are added…
  • AND the note tested has the same note of the object running the query
    … so we’ve go the original of the current alias…
  • AND the note tested is not an alias
    … in case we made two aliases by mistake and we are linking to another alias and not the original.

I’ve reported the issue about linkTo and making new link types, but until that’s fixed, ensure your desired link type is defined (a once-only task per TBX) before use.

Whether you use linkTo() or linkFrom() is up to you (Tinderbox links are uni-directional) and the link type are both things you can alter as you see fit.

Thank you very much. The explanation stretches my understanding of Tinderbox, but it works nicely. In most cases I will apply the stamp immediately after creating the alias, but from what you say I presume it will work even if I have moved the alias somewhere else, in which case it could have a wider use when my document becomes larger.

Incidentally, a question I have not seen answered is how many notes a Tinderbox document can contain before it becomes too slow. I am assuming the answer is a very large number.

1 Like

I think you misunderstood this:

We know a new alias is added to the next sibling of its original note.

If you move the alias on a map, and the current map at that, that’s OK. But if you move the alias into a container for example. Anyway, if you want the original to link to a new alias why would you then choose to not link to it while it is in a known relationship ($OutlineOrder as opposed to map or other view) to it’s original? It seems self defeating. I appreciate one might forget, but hopefuly not to often and at a rate where a manual fix is approariate enough.

To help understand OutlineOrder, i’d recommend this section of aTbRef, Outline vs. Map Interface. Despite using the context of just two view types the general point holds true re $OutlineOrder. The outline seen in Outline view is also the outline as stored in the TBX (in XML) as the underlying data structure.

Most Tinderbox facilities are fine with thousands of notes.

Few Tinderbox facilities are much good with a million notes. A map with a million notes, for example, wouldn’t really let you examine individual notes while perceiving any global structure. Finding a specific note would always require searching; you couldn’t remember it was “up there with the rest of the pre-Raphaelites” or "fairly near the end of the Facilities Committee records.”

As a rule, Tinderbox is best with hundreds or a few thousand notes in a document. The boundaries are quite indistinct.

Thanks again. I had discovered my error, but did not understand why. But if I remember to do it straight away, your stamp saves time. Right now I do not need containers, but I am trying to get used to using them because using Tinderbox proves successful, I will need nested containers to organise thousands of notes. It is because

At any time I anticipate working with a few dozen notes, or even up to a hundred or so, but as the project grows, I want to keep other notes in the document, hidden in containers so that I can preserve links to them, discoverable periodically through Hyperbolic view, that I might otherwise have forgotten about.