I’m new to using TB for my research projects. I’ve watched a number of Meetup and training videos to help me think about how to structure TB to explore industrial history during the 19th century in New England. I have not found examples discussing approaches to exploring history, so I’m hoping the members of the forum can give me guidance or examples. Though I’m sure it will change, I’d like to set up a high level map of the various activities, people, products, inventions, and industries. One thing I might do is create folder for each of the above categories and use either attributes or links to connect them, I’m not sure what would work best. For example, for a particular person, they would work for multiple companies and each company they would have different roles during different time periods, maybe represented as children notes under the person (these activities would use a different prototype than the person). Similarly in various companies there are both inventions and improvements to technology that occur during a period of time through the work of various technicians, inventors and management leaders, perhaps this is modeled by children notes or the industry representing each major technology and how it is used in production. Or, maybe the changes in technology should be its own category because of the interest in collecting these changes in one place, maybe via an agent? Any suggestions would be most welcome.
Given your historical focus and its implicit temporal axis, I’d suggest you might also want to investigate Timeline view. This brings up a fact many overlook, unlike most apps where there is only one (or possibly a couple of) view of your data, i.e. your factual notes, Tinderbox offers a larger range. So you can have maps, and timelines, and … other views. What this means is don’t become a slave to others’ processes.
Top tip: don’t build out complex maps, timelines etc at the root level of your document. Make a root level note and start indie that container. Hard to explain before the fact, but your future self will thank you for that small but productive step.
What does that mean in practical terms? Rather than use the default view—a root level map, make a container (next tip, issue a short unique title for it), drill down into it (in map view, select , then ↓ down arrow to drill into the child map. Only then start building out your data. The why will become apparent as you move forward.
Could you tell us a bit more about the problem you plan to investigate? And — though of course this might change — what end-product(s) you envision?
One thing to keep in mind: your don’t need to get the organization right from the beginning. Set up your document so it’s easy for you to use right now; you can always reorganize later.
How Interesting.
It sounds like you have some natural candidates for prototypes ( activities, people, products, inventions, industries, companies ) and maybe some use for user-defined dates for all of them. Aside from that I would echo Mark B’s comment - just start and don’t spend ages conceiving of every possible attribute you might need - they can be added and removed with ease - get messy with it first and make small incremental changes that make sense and then after a while perhaps share an initial file so that the forum can comment on tweaks that might improve the visuals, logic and suggest some automation that helps what you have discovered is important.
There is some Becker-code you might want to explore on how links can populate set/list/other attributes which I have found very helpful - for instance a ‘Company’ could have a number of products which could be captured in a $Products set
$Products=links.inbound."product".$Name+links.outbound."product".$Name
I’m already getting too detailed - just start and don’t pre-plan too much would be my £0.02p in addition to the excellent advice above - good luck, enjoy and post back a file
This is exactly where I was going. As @eastgate points out you want to be VERY careful with pre-mature formalization, you’ll want to allow the emerging structure to evolve naturally. I’d encourage you to watch my last couple of YouTube Videos, especially this one: https://youtu.be/g4HBBbHlqa4.
The key to make something like this scale for you is to get the automation right.
Note, I’m been building exactly this model in my industry analysis work, documenting history in real-time. I’ve been talking about it for months now, in the meetups.
I would also encourage you to have a citation strategy, you’ll want to keep track of your sources.
Finally, what is your ultimate goal? Write a book? Publish and article? What do you want to do with all the info?
If you’d like, DM me, and let’s set up a zoom call. I"m not ready to share all my processes just yet.
Perhaps you can propose a challenge to the community for July, e.g., maybe you could create a sample data set of 20 or so people (Name, companies, and initiatives associated with, the title held at each initiative, state/country, description of role held, accomplishments during the role, dates role held).
- How to associate roles that an individual may have in society, employment with different companies or groups, and other initiatives, and activities they’re involved in.
I’ve just reread Charles Morris’s “Dawn of Innovation.” Excellent resource.
There were very obvious patterns of cross fertilization.
The dilemma you appear to be facing is very similar to one that I experienced not so long ago. As you seem to be doing I approached my subject–early modern philosophy in the Dutch Republic–with the tacit assumption that my Tinderbox document should be structured so as notionally to encompass the entire field. When this became unwieldy, following suggestions from the forum, I started to reorganise everything so that the root map showed a container for each of the projects I was working on–two journal articles, and the translation from Latin to English of selected texts. This has provided a structure into which all the other containers and notes I have developed can be incorporated (early days yet: it’s very much a work in progress).
As both @eastgate and @satikusala suggest, the key is to reflect on the purpose you envisage for the information you’re assembling. This of course can, and will, change over time. But by using the aims of a particular project as a starting point for your structure, you may find that things fall into place more readily than by beginning with an all-encompassing overview.
Yes. A top tip for laying out your document, that’s hard to explain for a new-ish user, is start your research work notes under a single container at root level, or as here several discrete root level containers for different projects.
Short explanation is that if all work is under (inside/descended from) a single folder, then it is much easier to separate actual ‘content’—your notes—from other things like prototypes, templates, general utility agents. It’s not that root level maps don’t work (they do!) but it can make querying things harder than it need be. You don’t have to do this but your future self will thank you if you do.
In fact, drawing on the last, as you start to store your notes, do give a thought to how you might find them (or associated groups of notes). If all queries end up as a $Text.contains() type of query, take this as a hint that you might want to be adding more metadata (i.e. extra attribute info). That might be as informal as adding tags/keywords to the build-in $Tags, or more structured use of user-added attributes†. Don’t worry about that from the outset, especially on your first project. Happily, Tinderbox does not punish you if you want to add (or alter) your metadata at a later point. That is a strength as rarely are we able to start research knowing the exact form of the emergent research results.
†. Tinderbox comes pre-configured with some 400 attributes. Pretty much everything except a few preferences, is actually an attribute under the hood. The key one you will interact with are note titles (Name) and note text (Text) and don’t worry about the other until you need to. You can also construct your own ‘user’ attributes with names/data types you decide. Don’t worry about detail. If lost when the need comes, ask here in the forum. Lastly, if not a tech-centred person, a nice metaphor is to think of your notes as pre-printed library cards. Every card has the card the same set of boxes with a printed label (user attributes) and a blank area for you to add your own boxes (user attributes). Not every card needs a value in every box, but ‘has’ every attribute including any user-defined ones.
Thanks you for the suggestions. As a background to this work, I’m the archivist (volunteer) at the Charles River Museum for Industry and Innovation, and I’m also responsible for cataloging the artifacts. I’m building this TinderBox DB to assist me in understanding industrial history in the New England area. More practically, as I better understand the history, it should help me catalog and document the many archival materials in the museum collection, many of which are poorly documented. Later this information may be used to help support the creation of new exhibits at the museum, but that is a long term goal.
As a first pass I think I’ll limit my studies to the Boston Manufacturing Company, the history of which is pretty well documented and has many individuals who played roles in the building of other companies. This example should help me to explore what information to include and how to usefully tie it to other information.
What a fascinating area and project, Tom.
You might get some research process and organizing ideas from Andrew Abbott’s Digital Paper: A Manual for Research and Writing with Library and Internet Materials. I found it really useful (even if not everything was directly relevant to my work). Especially useful for me: using a Research Log to track the steps taken, things looked into–even if my logging isn’t methodical (at all at all). I’m pretty sure I learned about this helpful book from someone’s post here.
The research log helps a lot when one runs into those cool ‘oh, this is wonderful’ nuggets that aren’t related to the search at hand.
I use research for worldbuilding in fiction, so it’s definitely not a linear process!
Abbott talks in terms of folders, and I’ve actually moved more toward tagging materials. For my work, tracking where I’ve happened on something is really helpful, so I add all my sources into Bookends, and drag-drop any references I work with in Tinderbox into a References folder. A Link from the Reference note(s) to the topic note helps me find the source easily.
To drag from Bookends, use Command-Option-drag.
Mark has often counseled keeping data separate from Tinderbox workings, and so all research work goes into the Data folder, and technical underpinnings (Prototypes, Templates, etc) stay separate.
Keeping things simple at the outset is the easiest path, though I got tempted at first to get technical and delineate all sorts of prototypes. It was far too much and not necessary for what I needed, so I pulled way back.
One agent I have relied on a lot is called Recent–I can quickly see what I was recently working on. The code, which may or may not be correct: $Created>=(today - 30 days) This agent resides in the /Data folder, so it should capture all notes created within 30 days.
Very broadly, in the /Data folder are these areas:
/Research - includes Research Log, Sources (includes References as well as Sources to Explore)
/Topics (quite messy), including Scene details, Browsing for ideas, Story topics, Settings.
As a more visual person, I rely mostly on Map view, which affects how I organize materials.
It took me a while to realize–working with my materials and topics, as well as how I worked best and what seeing my work focus demanded of the materials and process–that simpler really is best. So, I now keep all my digitized materials in one folder and use finder tags to find or browse the research I’ve collected.
Tinderbox’s timeline is wonderful. You may also find Aeon Timeline useful.
It’d be wonderful to see what you discover–the New England industrial history as well as the process you develop. Have fun!
Progress has been made on modeling industrial history by finding a smaller project that is more doable. Currently, we have a collection of various types of lathes, maybe 15 or so - we are still cataloging the collection. This small collection is the core of my current Tinderbox file as I collect information on the history, type of technology and use of each type of lathe. Besides adding information for documentation of each artifact, this can provide information for creating an exhibit on the development and history of our collection of lathes and how they tie to New England industrial history.
It strikes me that such a document can also generate the fixed metadata needed by standard archival systems. On one level it’s “just” metadata but in practice my observation there is a difference interacting with the source data of metadata in Tinderbox compared to dealing with the cold, dead, hand of a fixed metadata database which is where such data often ends up. Databases are designed for efficient storage/retrieval, not for understanding or exploration. Conversely, Tinderbox excels at the latter.
I agree. I’m using TB to explore the history of the artifacts and how to tell that history. The actual formal record of the artifact is stored in our museum database, which is very inflexible.