Automatic Alias if title+prototype already exists


(Sebastian Stuewe) #1

Hi everybody,

while filling up my tinderbox, I have created a prototype called “Term”, which is intended for a glossary that is populated by an agent looking for all prototypes of the type “Term”. A term may be a scientific concept, a method, …

Whenever I create a new term, I would like to have TB check whether a note with this very name and prototype exists, and if so, instead copy an alias at my current location so that I can add up information to the existing term.

Is that possible?

Thanks for reading!
Sebastian.


(Mark Anderson) #2

Tinderbox allows notes to have the same name (the UID is stored in $ID) and doesn’t have a built-in duplicate warning/or suppression. There was a duplicate title warning setting in v5 (here) but it appears that wasn’t carried over to the new v6+ re-write of the app - or if it is I can’t find it. So, for now checking for duplicates is a user task - you could do something like list all notes of pprt type ‘Term’ and sort on $Name and check if any has a previous sibling of the same name.

Do you mean ‘copy an alias’ or ‘create an alias’? As the former doesn’t make sense I’ll assume it’s that latter. If so, No, an action can’t create an alias. I assume this falls under the same pragmatic assumption that doesn’t allow action-based creation/deletion of notes - to guard against user error doing serious damage.

As the agent collecting terms will make an alias for each term, for what purpose is the extra alias proposed above. I ask only because there might be a different way to achieve your goal.


(Mark Anderson) #3

I can now confirm the old v5 ‘warn if a duplicate name’ for new notes was indeed dropped in v6+.


(Sebastian Stuewe) #4

Thanks for your help!

Let’s assume I have a TB with 3 sections:

  1. Glossary (Agent): displays all cards of type “Term”
  2. Article 1. In here, I read about some research, and find that the researcher 1 is adding nice ideas to concept A. Hence, I make a card of type “Term” regarding concept A.
  3. Article 2. In here, I read about some other research, and find that the researcher 2 is also adding nice ideas to concept A. Now my “Term”-Card of concept A already exists, so instead of creating a second card and having lots of individual cards for the same concept in my glossary-agent, I would have liked it if TB could have checked among the term-cards, and then tell me that there already is a card relating to that concept, move an alias of that card to the very same “Article 2-map”, so that when I want to read Article 2 again later, I can also see the relating context (regarding concept A) from Article 1, and at the same time add up to the glossary, as that compiles everything together.

I guess I could have agents for each keyword. Would there be a way to make my glossary function in a way that it creates an agent for each element in $keywords, which then collects all cards of type term relating to that keyword? Like, an agent within an agent?


(Mark Anderson) #5

Don’t make an agent per-keyword as that approach doesn’t scale well. Much better is to use a new tab with an Attribute browser view, which is designed for such a purpose. For a given Attribute (e.g. $Keyword) it will show you each discrete value in use in the document and each value lists the notes using that value. You can set the scope of the view, e.g. to just one container for example. Or you can apply an agent query to further filter the ranges of notes listed. The view also supports column view.

As to your workflow, I’m unclear in step #3 how you propose to tell Tinderbox the value you wish to test. Action code doesn’t do input dialogs for script. So, you’re going to have to put that value in an attribute if you want to test/act on it via action code. Remember, action code is not like a full programming language so don’t assume a programming feature exists (e.g. input dialogs). The best overview of action code options is probably this.


(Sebastian Stuewe) #6

Thanks, Mark. That is helpful.

As to #3: I understand the restrictions, and I am too inexperienced to say whether they limit or liberate. The idea was to pass on that value through the title of a new note, which is then tested, discarded and replaced by an alias of the existing note of the same title.


(Mark Anderson) #7

Well, as action code doesn’t create new notes**, the issue is moot.

** As a design intent, action code does not (currently) allow new notes to be created, or existing ones deleted, or (apart for a workaround) to create aliases. This choice was because of the scope for user error to create run-away actions that resulted in a lot of work to repair unintended outcomes.