Hello, I would appreciate some guidance as to how to approach an issue I have with my academic quote database.
A bit of background: I have a container note for each academic work. That container note contains a number of notes that are quotes from the work, a Reference note created by Command-Option-dragging the work in from Bookends, and an Abstract note. The initial Reference prototype was created by Tinderbox when I dragged my first reference in, and has since been tweaked by me. The Quote and Abstract notes are also based on prototypes created by me.
The Reference note in a given container has a lot of data that it would be useful to copy into the other notes in the same container. Though it isn’t the most elegant method imaginable, I decided to try to do this initially by making a new prototype for each Reference note that would enable the Quote notes to inherit some values from it (Authors, ArticleTitle,
BookTitle, etc.) and creating my first Smart Adornment with an OnAdd rule that would trigger this inheritance.
So in one of the container notes I made an adornment called “Inherit Reference Fields”. I created an OnAdd agent for this adornment thus:
$Authors=;$ArticleTitle=;$BookTitle=;$Journal=;$Publisher=;$PublicationCity=;$PublicationYear=;$RefKeywords=;$Abstract =;$ReferenceURL=;$RefType=;$Volume=;$Pages=;
$Prototype=“EXPANDING VYGOTSKY’S ACCOUNT OF CULTURAL MEDIATION";
I also turned the Reference note into a prototype so that the Quote notes could inherit values from it.
That worked, but the problem is kind of predictable, since the new prototype, being based on the Reference prototype, changes the color and key attributes, meaning that the notes lose their character as Quote notes. (I was kind of hoping it would ignore properties of the prototype other than those I had explicitly reset.)
Is there a better approach I could be taking here?
I believe creating a unique prototype for each container is going to get very unwieldy very soon. Normally, prototypes are “generic” in the sense they can be applied to multiple notes, and are not designed to be applied to a single, specific note.
What I would do is make the container the reference note, with the Reference prototype assigned to it. I would have a separate prototype for Quote notes, and another prototype for Abstract notes. So we have a hierarchy like this:
Expanding Vygotsky’s Accout of Cultural Mediation <-- Prototype == Reference
— Some Quote <-- Prototype == Quote
— My Abstract <-- Prototype == Abstract
Now, if you want the quote notes to inherit the value of $Authors from the parent, then your Quote prototype can include a rule like this:
$Authors=$Authors(parent);
In the example above, then, since “Some Quotes” is a child of “Expanding…”, then $Authors in “Some Quotes” will be assigned the value of $Authors in “Expanding…”
The trick here is to think about inheritance and how to make it work as simply as as straightforward as you can. The problem with “one note, one prototype” is that it becomes difficult to sort out how the inheritance works and you get unintended effects such as you described – badges getting wiped out, etc.
Oh, I had thought of various alternative approaches, but that hadn’t occurred to me at all. It makes perfect sense now that you explain it. My existing container notes are basically just dumb boxes, whereas your idea allows them to actually work for me. Thanks as always.
To spell out a few more implications of the excellent advice from @PaulWalters:
You can think of the container for each book as holding all the basic info about that book, which you would like anything drawn from the book to share. Thus you create a Reference prototype for these containers, and you add all the relevant attributes that would apply to a book as a whole, from $Author on down. The only ones you might omit here would be, for instance, $PageNumber or $Theme, which might apply to the location of specific quotes but not the entire book.
As recommended, you also create Abstract, Quote, and any other prototypes that will be useful. And when creating them you specify that they will be based on the Reference prototype, so they will automatically share the same key attributes, etc, by inheritance unless you specify differently. Eg here is a screenshot showing how to create “New Prototype,” based on one called *Note.
If most of the notes you’re going to be creating inside the container are going to be quotes, you could set an on-add action for the Reference prototype of: $Prototype="Quote" . You would then have to manually change those you wanted to end up as Abstract instead, but if most were of one sort or another, this could simplify things.
You could add a similar on-add rule, setting prototypes, into both the Quote and Abstract prototypes, so that if you had some descendants of them, they’d be set up the right way too (subject to manual override.)
Main point is to agree with @PaulWalters’s suggestion that a small number of prototypes is the way to go, rather than one for each book. Good luck.
To take @JFallows brilliant advice one step further – prototypes can have children and those children can be prototypes. So your Reference prototype can have Abstract and Quote children and each of them can be a prototype in its own right. (And Reference can be the prototype for Abstract and Quote.)
So, I create a note. I assign Reference to be its prototype. This automatically creates children (new instances of Abstract and Quote – be sure to rename these notes, by the way or use a rule that changes their name based on the book or article title). And because the $OnAdd action for References is to set the added note’s prototype to Quote, then you get a new quote note every time you add a new note to the container.
