Still feeling my way around how Tinderbox functions, and I’m increasingly working with annotated text that we’re importing into a Tinderbox file.
Under this scenario, each annotations is converted into discrete TBX notes, and which contain fleshed out Attribute / Value relationships.
I’m wondering: is there a way to attach or include comments to TBX notes? I’m wondering how this would work both as I’m including notes to comments, while the Text window is already filled with text from annotation and if there’s a way to also carry over comments for annotated notes before we import them into our Tinderbox file.
Yes. the general concept is to use the Explode method. As the default configuration is to explode each paragraph to a new note, you will want to use a custom limiter in the source that will be unique. For instance if you place ####—a string that won’t occur† in your source notes or annotations, you can explode on that (marker) text via the Break at delimiter option. Indeed, using the latter you can choose to Delete Delimiter so that the added-in marker its not retained post-explode.
The latter method mean you can have one comment source file containing a source and one or more annotations appended after it, using a special explode marker (as above) between each segment to form a note in Tinderbox.
Indeed you could join each of those combined notes into a single composite composite text with a different explode delimiter. Then, post import, you’d expode the first level to vive a discrete note+annotations. Then you would further explode eacg of the latter into the main note and discrete annotations.
That leases a little work of deciding where in your document you wish to place the main notes, e.g. perhaps next to, or linked to, a note describing the source. Then similarly describe where the annotation(s) got and how/if they are linked. If that seems a chore, it shouldn’t be. If nothing else it will make you consider why you are so arranging the notes and whether your first choice of arrangement makes sense.
But in summary, yes!
†. If it does, just pick something else but making sure it doesn’t occur in the to-be-exloded text.
To give some context, we’re using the annotation approach that @mwa assisted @print714 with, involving annotations with MarginNote, rendering annotated notes and their attributes / values with OmniOutliner, and then importing them into Tinderbox. It’s quite a good process, and we’re trying refine it and add some features – such as ways to include comments to notes on the annotation end, and carrying over those comments to Tinderbox.
While I like the approaches you and @eastgate have provided, I’m wondering if it might make more sense to create out commented in Ziplinks. I’ve just reviewed some of the Ziplinks configurations, and it seems like one could include comments with the [[<SAMPLE TEXT>]] approach within MarginNote, and have it survive the OmniOutliner rendering process and import into Tinderbox (hopefully). Naturally, this requires experimentation.
Before getting to far ahead of ourself, I was wondering if it’s possible to create an agent query that would combine one of the values we use (e.g., Follow up, Follow up QTS, Review incidents) with something that identifies the the existence of Ziplinks in notes. I’m just trying to find a way to capture all comments (i.e., say, through the existence of Ziplinks), and organize them by select attribute / values we’d use for research review.
As @Markoconnor has already correctly pointed out the term zip-link refers to the method of creating a link. Importing/pasting text with content like "In this text [[AA|this]] links to note ‘AA’ will not generate a link.
I think your error of assumption is to assume Tinderbox $Text is written in wiki-style mark-up. As my example above shows, it isn’t. This also explains why there is no feature to do as described previously.
If you think this feature is needed, then as is the general case, email your idea, with an explanation and the need, to Eastgate. Explaining the need helps explain value to the user base and judge whether the engineering cost gives acceptable return on investment (if only in terms of effort being used that might otherwise be expended on other features or maintenance). Why you? Because you have the problem so can best describe the need.
Issues affecting the idea:
what happens to text containing what lo’s like relevant wiki-markup but isn’t, e.g. a code sample. We wouldn’t want some users’ import ruined just so other users are inconvenienced.
As the zip method allows creation of a blank target note, mis-detection of specimen zip-link-style mark-up could cause havoc.
what happens if the target note is not present? The input might misdescribe the target title/path or there might be duplicate targets, etc.
… and so on. Given the above, I think automatic processing of import, i.e. in all cases, is too likely to have false positives. But a feature to post-process selected note(s) $Text could work given something I noticed testing my example imported text in the opening paragraph above. I found I can invoke the desired link creation by inserting the $Text input cursor after the last ] and pressing the Return followed by the Backspace. The former causes the wiki mark-up to be detected/processed and the latter key removes the actual keystroke character entered into the $Text.
So, worst case, today you can easily manually post process the ‘zip’ links mark-up using the keystrokes described. Indeed, that might be good practice as it makes you review your data and check the correct target is linked.
Thank you, @Markoconnor & @mwra. I appreciate your input, and believe I understand what you’re suggesting.
The problem with making a feature request is that we don’t know what syntax will work for making a comment in MarginNote, surviving the OmniOutliner rendering process (though I suspect we can find something that will be fine), and then serve as a some kind of note-comment in Tinderbox.
As to what you’re suggesting, @mwa, can you first describe the Ziplinks syntax we ought to first use?
Under this scenario we’d have the text window include the captured, annotated text from the MarginNote annotation & OmniOutliner rendering, and then the comments contained in the Ziplinks syntax – followed by manually inserting $Text afterward the Ziplinks syntax in Tinderbox. Have I got that right?
Again, I thought that marrying comments in Ziplinks and using a query agent (e.g., using a “Follow up” value) would provide a possible solution to what we’re seeking.
The syntax for the zip method is described here. There are lots of options, so you need to read that and decide which options you want for your process and then describe them here. Otherwise it is a lot of time and guesswork for others to try and figure out what at the moment is only clear in your mind.
To what will these new text links point? Can you give an example.
If still stuck describing the process, make a small TBX with an example of the sort of content you are importing to Tinderbox and also including the same content properly processed into its correct location/configuration in the TBX (links created, info taken from $Text and placed in attributes , etc., Then, the most important part, describe that process so someone with the file can start with the same sample input and get the same result. Don’t worry if you can’t describe how everything in the input gets to its right place don’t worry. The point is giving the reader an understanding of how many discrete tasks must be applied to the note with the imported source info (you simply can’t guess with a workflow of your complexity). Then post the TBX in this thread.
If that seems like a homework assignment, it definitely is not and is necessary to understanding your process. If we can see what In fact it is exactly the sort of process experienced users apply in their own work when facing such an implementation problem for which the answer is not obvious. Experience shows that either/both the creation of start and end examples or/and documenting the process sheds light on the likely solution. Or, as here, it provides the minimum necessary information for others to understand your problem. After all if I can’t document a process, I probably don’t understand the process—I lesson I learned in the early years of writing aTbRef and still re-learn.
By looking at the start/end of the process in the test TBX doc we can ascertain meaningfully if zip-created links are feasible and how, if at all, the data leaving MarginNote needs to be altered so as to arrive correctly into Tinderbox.
It’s been a while, but I’ve finally figured out how to integrate Ziplinks into my annotations in order to create comments. The Ziplinks syntax I settled on was: [[<note name|anchor name::comment text>]]
As most of you already know, this Ziplinks syntax sets up the comments so that it creates a discrete note, with links that connect the parent note to the Ziplink comment and vice versa.
As part of my set up, I need to include the Ziplinks into the annotated text – not as separate part of the annotations, such as with tags or comments.
The Ziplinks syntax remains in the annotated text, and is then activated in Tinderbox once I apply a stamp to the note, changes its prototype, etc.
The only thing is, it seems like the notes created from Ziplinks appear in agents, where I’m query specific values, but they do not seem to appear in the AB view.
Is this just the nature of the way Tinderbox handles notes created from Ziplinks? Or is there something else I should to to enable these notes for appearing in the AB view?
There’s nothing special about notes created by zip links and opposed to notes created in any other way. If those notes fit the criteria in use by the attribute browser, they’ll appear in the attribute browser.
I’m afraid I cannot do that with this particular file, since it’s one that I’m working on collaboratively and contains sensitive data. Let me test this further in another, smaller file and see if I can upload it.
Further @Pete 's point, when you click on a tab’s title you may see the tittle text show in red: this is nothing to worry about but does indicate the view is being refreshed/redrawn. I say ‘may’ as in all but the biggest/busiest views the process happens so quickly that you never get to see the red text.
Thank you. That did “refresh” some of the notes in my AB view.
However, when I’m looking at the notes under the Outline view, I’m able to see the notes that contain the in and out arrow icon for that that contain the [[<note name|anchor name::comment text>]] Ziplinks syntax and the corresponding Ziplinks-created notes.
But in AB view, I only see a one arrow icon for the notes containing Ziplinks and none of Ziplinks-created notes.
Is that how it should be? Or is there some other way I should be setting up the AB view so it can also contain Ziplinks-created notes?
I don’t understand that. If you use the zip-linking method, the result is a text link. There is no such thing as a ziplink, the term applies to the keyboard-based method of inserting text links. I think confusion arises for people who are new to Tinderbox but used to wiki-style apps where the only links are those user-typed in via [[ ]] tagging or Markdown and assume that this is the only way to link in Tinderbox. This in turns confuses other Tinderbox users who are less used to such limited link-creation methods.
Again, this is confusing terminology, from a Tinderbox perspective. The zip method of linking does have an option to create a new note (if the specified target doesn’t exist) but is just a note. There is no way you can find only notes created via the method, which is why the terminology is ultimately unhelpful as
it implies a category of things that don’t exist, except conceptually. Again, I think this arises from thinking of a Tinderbox document within the much more limited concept of a wiki.
I can’t replicate this, so the notes you can’t see are likely not in the scope of your settings for the AB view. You control what AB view shows. If it doesn’t show you what you want you have either set ther controls wrongly or you haven’t set values the controls are expecting to find.
Can you please post a small demo showing the problem. A useful adjunct of that is if you can’t reproduce it in a test doc, it helps indicate the problem is in the set-up. If you can replicate the issue, it is important to tell use which note(s) you expected to see but can’t.
By Ziplinks-created notes, I was referring to a text link.
As I said, the Ziplinks syntax I’ve used creates text links – or, what seem to be discrete notes that link to where the Ziplink originates – and they appear in an agent under Outline view, but not in an AB view.
I’ll try to replicate this, though it will take me some time to do.
