Manage Prototype Creep

[wajakob]

I’m midway in a major historical research project with a large number of sources both primary and secondary. To this point, I have created a new prototype for each source. Not surprisingly this threatens to become unmanageable. Can anyone advise on this problem?

[galen]

My first approach to this would be to have a single “Source” prototype, or possibly a prototype for each type of source, such as “Book Source”, “Video Source”, etc. Could you summarize why you feel you need a prototype per source? What does that get you? What other note would use a specific source as a prototype, and to what purpose?

[regan]

Perhaps consider using Bookends. When dealing with a large set of primary and secondary sources, Bookends and it’s keyword, smart group, and color coding capabilities provided me with a great deal of flexibility. These capabilities proved invaluable in my historical analysis. Tinderbox was helpful too, but not in this context.

[wajakob]

When I began serious research 50+ years ago, I worked on the principle of one data point per 3x5 card. I manually coded each card with the source details. Tinderbox prototypes allowed me to continue with one data point per note and spared me the tedium of repetitive entry of source details. If done correctly, one does not lose data points or source details.

[mwra]

What differs between the prototypes as opposed to the sources?

[wajakob]

Each note contains both data and the source reference per ancient 3x5 card practice. Using a specific TBX source prototype (now a few hundred in total) for each note eliminates the need to re-enter the source data over and over again. Unfortunately my practice also creates an unwieldy list of prototypes.

[PaulWalters]

Using a specific TBX source prototype (now a few hundred in total) for each note eliminates the need to re-enter the source data over and over again.

I assume, then, that there are some or several or maybe numerous notes inheriting each source prototype?

[wajakob]

That is correct. One source yields multiple notes.

[galen]

Tinderbox prototypes allowed me to continue with one data point per note and spared me the tedium of repetitive entry of source details.

Ah, gotcha. If I understand, you’re using prototype assignment to quickly copy certain attributes, say Title, Author, and Year, from a source note to a data-point note. As you are discovering, this is not the intended use of the prototype mechanism, and will quickly become unmanageable as the prototype drop-down list grows longer than the window. There’s a nice way to get exactly the behavior you want, though it does involve some moderately complex action code.

Here’s a solution:

1. Create a Source prototype, which will serve as the prototype of all source notes. This will have whatever Key Attributes you require for your sources. I will assume you will put the title in $Name, and use $Author and $Year as Key Attributes.

2. Create a Data-Point prototype that will serve as the prototype for all your data-point notes. This will include Key Attributes $SourceTitle, $SourceAuthor, and $SourceYear.

3. Give the Data-Point prototype an $Edict that copies the relevant info from whatever note you link to with a “Source” link. For example:

if (links.outbound.Source.$Name.count > 0) {
  $SourceTitle = links.outbound.Source.$Name.at(0);
  $SourceAuthor = links.outbound.Source.$Author.at(0);
  $SourceYear = links.outbound.Source.$Year.at(0);
}

Now when you want to copy source data from a source note to a data-point note, you create a “Source” link from the data-point note to the source note, and the data-point’s edict will copy over the info.

Tinderbox doesn’t act as a relational database, but I use this idiom whenever I want a join.

This Tinderbox document (60.9 KB) shows this setup in action.

[wajakob]

Many thanks for this useful idea. I will give it a try.

[PaulWalters]

Very clever idea – Data-Point prototype. I don’t recall ever seeing that suggestion before.

[galen]

Thanks! I discovered this while tracking a bunch of events that occurred at various venues, in order to avoid copying the venue info into the event notes by hand, and it has turned out to be pretty widely applicable. I end up using it in most documents that feel a bit like a database.

[mdavidson]

As an alternative you can map source and data points into containers (for each source) and notes inside each container (for each data point related to the source) using the a procedure similar to discussed a previous forum discussion under this link.

You then follow the following steps as you do :

• create source notes with the relevant information in attributes based a single generic “source prototype”
• type datapoint notes at the main level and assign data point prototype
• drag or move the datapoint into the relevant source container (typically in Map or Outline view)

The $OnAdd action for each prototype then takes care of copying all the relevant information from source to datapoint. I attach an example TB file below.SourceandPoints.tbx (60.3 KB)

[rickdude]

Does anyone have a perspective on which of the two approaches outlined here would be the most promising to use as a default? Or on the types of projects where you might choose one over the other?

[mwra]

I don’t think it’s either/or. The link based method is a plus if you are a mainly-map-view person as the latter needs a hierarchical layout, if only when adding new. That said both can be done entirely in map view (but not all in the same map).

I think the real answer is to do a small test of both and see what works best for you. At the risk of repeating an old mantra, very few things have one ‘right’ way to do things. Plus depending what you add into the mix, things like efficiency/performance can alter a simple comparison of the base methods above. so, try both, pick one.

[PaulWalters]

Does anyone have a perspective on which of the two approaches outlined here would be the most promising to use as a default?

Consistent with @mwra’s advice, I’d suggest this is a case of “try it”. Ultimately what anyone suggests here should be tried out with your own notes and data – usually a small test file is best. You’ll find what fits your own thinking mode and the content you’re working with.

If I had to vote, I’d split my vote because the answer to “most promising” is “it depends”.

[mdavidson]

It depends and executing small tests… is the right answer.

Nonetheless as a guideline you should consider in this case and similar tasks how many sources and data points you expect e.g. how many notes in total. Consider your research will end up with 10 sources each with 30 datapoints. This corresponds to 300 notes with 30 links between data points and each source. I expect that your Map view will get extremely busy and dense with notes and links.

The container approach is likely better for this case as all you get at the main level is 10 source containers and you can explore easily the data points for given source container either in Map or Outline view. You can always add links between source and datapoints using this method too within the $OnAdd action.

For cases with 5 sources and 5 datapoints and strong interest in a single Map view the link based approach is certainly very good as well.

[galen]

Does anyone have a perspective on which of the two approaches outlined here would be the most promising to use as a default? Or on the types of projects where you might choose one over the other?

The link-based approach is more robust and imposes fewer restrictions on the structure of the document. The $OnAdd approach uses simpler action code and is thus easier to understand and implement correctly.

To expand a bit, the link-based approach is more robust because changes to source notes are automatically propagated into data-point notes. For example, if you find an error in one of your source notes, you can just change the source note, and all its data-point notes will be updated automatically — no further action is needed on the part of the user. With the $OnAdd approach, after you correct the source note, you have to ensure that the $OnAdd action is rerun on every data-point note that uses that source, which in turn means you must remove all the data-point notes from the source container, and then add them to the container again (you could also use a stamp, but you must then ensure that your stamp and your $OnAdd action remain in sync).

This basically requires that with the $OnAdd approach, you keep all data-point notes as children of their source note, and if you want your notes organized in some other way you have to use aliases, which bring their own complications and limitations. By contrast the link-based approach allows you to structure your document and organize your notes as you please, since the connection between source and data-point is represented by a persistent link, rather than by the parent-child relationship.

The advantages of the link-based approach are largely independent of map view. Any large or even medium-sized research project would most likely have too many notes to yield a coherent map anyway. (I personally almost exclusively use outline view in documents that use this approach.) And there is no need to keep all the notes in one map — organize them in whatever way you like.

TL;DR: If you’re happy with always having data-point notes as children of source notes, or don’t expect to have to augment or change source data once it’s been entered into the data-point notes, the $OnAdd approach is simple and effective. If you want more freedom in your document structure and want to make sure that changes and augmentations to the source notes are always propagated to all the data-point notes correctly, the link-based approach is a better choice.

[gnoli]

wajacob, many thanks for touching a topic useful for all involved in academia, with extensive readings and taking notes.
As a newbie, I want to submit to you and to the gurus mwra and PaulWalters my very basic approach and ask you if you see any error or weakness in my way of taking notes. I am working almost exclusively in Outline view because now I am putting data in my document, rather than elaborating or analyse data …

• Whenever I begin to read a source, I create a new note using the built-in prototype ‘reference’
• Then, I fill the metadata with author, data, pages etc. of that source - all these data are stored in a huge Bookends DB
• Then, I check the button Is Prototype in Properties Inspector
• I add a $OnAdd action to that new Prototype note and I use this new Prototype as a container
• All the new data point inherit the metadata from the new Prototype
• When I finish taking notes from this source, I eliminate the Prototype deselecting the button Is Prototype in Properties Inspector

Thank you in advance for any suggestion

[mwra]

Then, I check the button Is Prototype in Properties Inspector

Not needed. Just give the new reference note an $OnAdd. The effects of this are:

• The new $OnAdd code will apply _only to (new) children of this container note.
• As you are setting $OnAdd locally, if an OnAdd is set in the ‘reference’ prototype then it won’t be inherited.

Making the new reference note has no effect as regards your process so you can omit this task. If you don’t understand why that is so, by all means ask—though I suggest you do so as a new thread.

If worried here—or in the scenario up thread—that a subsequent change/correction of the ‘master’ reference for a set of quotes may change, use a stamp or an edict with the same code as the OnAd. Using either will-thus re-apply the parent values to the children (assuming the quote notes remain children of the reference note).