News:IMPORTANT MESSAGE! This forum has now been replaced by a new forum at http://forum.eastgate.com and no further posting or member registration is allowed. The forum is still accessible via read-only access for reference purposes. If you wish to discuss content here, please use the new forum. N.B. - posting in the new forum requires a fresh registration in the new forum (sorry - member data can't be ported).

I've been seeing a lot of email lately from people who are getting started with their dissertation research. Suppose you were making a new Tinderbox document for a dissertation, a book, or another big project.

Three things spring to mind.Firstly, a place to think about and play around with the proposed research questions that the PhD will focus on. They're sort of the basis on which everything else rests, so there should be a separate section for that.Secondly, a little bit of attention should be payed to prototypes, I think, esp if you're planning on including all your references/material in your TBX document.Thirdly, there should be some structural walls between- Scribbling (a sort of inbox for random notes that can be filed later on)- The PhD itself (separated out initially by theme, and eventually by chapter)- References (YMMV on this, but some people use TBX, others use Bookends or some other dedicated tool)- Planning/Management - I had (have) a separate section of my document related to administrative matters. I put my workplan (ie which chapters I was going to work on when, and in what order etc) in this section.

A unique strength of Tinderbox is that it is very flexible, and that it supports emergent structures: you don't need to have an exact blueprint for the architecture of your Tinderbox file when you begin. This is important, because (a) we often don't know where our research will lead us, and (b) Tinderbox allows so many ways to massage one's notes and rework them. No other note-taking/database software I know of can do this, and it is one reason why I think it is a most excellent tool for research that, by its nature, is exploratory and a bit uncertain as to its own destination.

Having said that: perhaps the first tip I'd give is to accept that mistakes will be made, and to not be afraid of scrapping your dissertation's Tinderbox file and starting afresh, if need be. When I was starting to take notes for my dissertation (in medieval textual/historical studies), after close to two weeks, I trashed my file and started over. It was an excellent decision: I had learnt a lot about the mechanics of Tinderbox as well as about how it could help me understand the text that I was studying. At that moment of starting over, I felt that I had wasted precious time; but I later came to see that first file as a scratchpad, or a draft, and the time expended on it as well spent.

Of course, at the time of starting afresh, I still didn't know most of what I would later learn about Tinderbox's various tools. But the basic structure, tricks, and skills I developed (and learnt from others around here!) continued, and continue, to serve me well. Years later, I am still learning what Tinderbox can do, and the myriad ways it can do so.

As for containers, in my own use of Tinderbox for the purpose of textual analysis, my basic top-level containers usually begin as follows:- Prototypes- Data (the body of my notes culled from the text under study)- Inbox (notes to myself, tasks, "about this file", etc.)- Analysis (various agents which analyse the "data" notes).

As such, much of how I structure my file actually matches what Alex has advised.

Here’s an example of a project that I’ve started that might be useful. Having done a dissertation eons ago, this method would have been helpful to me back then. This project is loosely conceived as a possible book at some point.

I do psychological assessments as a consultant on disability for a government agency. I was asked to provide some advice to a colleague who is starting to do these exams.

My first idea was to write out a “top ten” list of suggestions. I started it as a single note in my main Tinderbox doc. But when that list of “ten” items had tribbled into 30+ suggestions, and given that I’ve noodled around with the idea of an eventual book on this topic, I copied the list as a first note into a new Tinderbox doc.

I exploded that note. Now I had 33 notes in an “inbox” container. Of course, each of these notes could become a paragraph or a topic to research. It could be linked and grouped with other notes in the collection, and so on. But so far it’s a simple, unsorted list in an outline format.

Over the next few days, I had other ideas that I added to the inbox list. (Of course, the fact of having done this much work tended to prime the unconscious: I became more likely to notice interesting topics and dilemmas in my daily work and drive home from the office, and added them to the list.) Now I have over 50 notes of all sorts: questions, suggestions, a copy of an email discussion with agency officials about a dilemma that we were wrasslin’ with, etc.

Without having devoted any time to “working on a manuscript” at this point, I’d started to get some spontaneous ideas on structure, a possible outline if one use for this list were to be a book. The next step was to do a new top level container note for an early outline, beginning with an idea for an introductory section of a manuscript.

Writing all these notes and thinking about them started to enlarge the project in my mind. It suggested a sort of “big picture” perspective on the possible value of this kind of consulting. I started to think about how disablity consulting is a kind of “mountaintop observation platform” for developing first-hand exposure to many of the political and social issues we face in constructing our society: how we treat the poor and less able, political arguments about “entitlements” programs (the “takers” vs “makers” arguments), medical controversies (e.g., does “fibromyalgia” exist as a physical condition, or is it a psychological condition?), moral/psychological issues (is substance addiction a “moral” or “medical” condition?), urgent medical problems (assessing PTSD vs TBI effects in returning war veterans), etc.

This seemed like the kind of insight that, while early and unsorted, has potential for enhancing the value of what was going to be just a list of suggestions on doing reports for a colleague.

I wrote a rambling, brain-dump paragraph listing those kinds of examples. I could have exploded this paragraph again, but instead (mostly for the fun of it) I added new notes to the “inbox” container on each of these topics. Returning to the brain-dump paragraph, I started highlighting each topic with my cursor, and used the link tool to connect each topic in the paragraph to its corresponding note.

This process of writing “insight paragraphs” can be repeated a number of times as my “big idea” collection develops. If this were a dissertation, I’d be developing it into lists of possible topic ideas to discuss with an advisor or colleagues (or perhaps, for a writer, with my editor or agent), along with gradually developing a pretty nice in-depth level of expertise on my topic, which could be more easily shaped into the final book or dissertation or whatever.

This is as far as it’s gone so far. But after a minimal amount of work, this is already a large, growing Tinderbox document which can become the nucleus of a blog post, essay, book or dissertation, an ongoing writing program, a research program for an academic, a project for a journalist or business team, and so on. You just keep adding sources, tags, references, organization and so on, often in dribs and drabs.

I would recommend to almost anyone starting a dissertation or large academic research project Andrew Abbot's book, Digital paper: A manual for research and writing with library and internet materials. Abbot's book is targeted toward humanities and social sciences, but it could be adapted to science for "non-bench" science work, e.g., interpretation and synthesis). Its focus is on the quality research and using print resources (library) and online resources to most effectively recognize and produce high quality research. This is a unique book, even somewhat Tinderbox-ish (including an early chapter that is an ethnography of library work--an "Abbott's way", that brings to mind The Tinderbox Way.

The book emphasizes the non-linearity of library work and the ongoing management of research and bibliographic activities and their iteration starting from the puzzles that get one started on framing research questions, through browsing/scanning to learn the vocabulary, concepts and themes of an area that will guide the "brute force" reading and production of mini-analyses of topics, and finally to writing. Because of the way that the book "spirals" about the activities as they progress from Preliminary through Midphases to Writing, it is suitable for the beginning grad student writing seminar papers through the later work production of the dissertation. It is a good accompaniment to Booth et al. The Craft of Research, but not a replacement for it. I've found Digital Paper useful as an advanced scholar; like others on this site, I've a series of articles that I want to transform into a book (more on that later in a different post).

Specifically relevant to Mark B.'s question about "what containers you would want to create," a short list of containers is given in the first chapter, "Preliminary Phase" of research. It is easy to imagine these as an initial start, not only for one's research, but also a low demand on TB skills, at least at first. In the second, and much more detailed discussion of the Preliminary Phase, the file folders grow in number and depth as they have to support a more extensive project. Let me say that it's clear from Abbott's book that a list of containers cannot provide the guidance and enforce the discipline of using them without the development of the Design Document folder/container (concerned with research questions, bibliography, conceptualizations, semi-controlled vocabulary, etc), which initiates and recursively is modified to keep research activities focused on quality and constraints.

Given that I'm a "low-end" user of TB (coloring notes, pulling them around on ornaments, the occasional prototypes and linked notes, exploding previous written material), I would probably use TB for the initial folders/containers and other activities (e.g., mini-analyses) where I'm trying to get down details and introduce tentative structure. I would probably move this material to short files in a Scriv project or simply a hierarchically controlled research folder on Dropbox. I would use DTP to store and manage the variety of items that come through my Downloads folder and short notes through the DTP desktop inbox. I would use Sente for bibliographic information and organization of sources by topics, ratings, chapters, etc., minimally having an "active" and "archived" bibliography, and Scrivener for doing the final drafts.

By the way, I don't know Abbott (although I've established two degrees of separation!) nor am I in any way affiliated with the publisher or have any other interest, beyond finding a book I'd like to share.

Linn, thank you so much for the Andrew Abbott recommendation. Actually, I find his suggestions more appropriate to something like DevonThink, but I can see how it fits in with Tinderbox as well. It was really a wonderful book for thinking about doing big research projects with lots of pieces of information. I also learned a ton about online and offline resources that libraries have.

By the way, I don't know Abbott (although I've established two degrees of separation!) nor am I in any way affiliated with the publisher or have any other interest, beyond finding a book I'd like to share.

I hadn't known about this book, and will check it out, but by coincidence I do actually know Abbott. I realize from a little clicking around that he is the Andy Abbott I knew as a classmate in college. Am glad to know of this book.

I'd really like some feedback on two Tinderboxes. This first one is a Tinderbox I've started to track LaTeX info. It is really basic and I am wondering how to glean more information from what I've entered.

The second post, to be added shortly, pertains to organizing scientific information and how to agents/actions/queries to help organize the information using adornments and/or containers.

This forum is not configured to accept uploads. Just place a copy of your files on webspace to which you have access and post a link to that here. If you don't have a web site, Dropbox allows you to post URLs to files in your dropbox so they can be downloaded (only).

I can't see any obvious problems (using v6.2.0). I can see the Research file is based on my starter doc - nice to see it getting used. As of v6.2.0 don't worry if some of the user attributes such as $MyString have moved; you doc will work the same but some of what were user attributes are new system attributes in the 'Sandbox' attribute group. You can weed out bits of the starter doc you don't need, e.g. the About 'Starter' notes, but there's no hurry. I assume this TBX is designed to be used, at least at this stage, as an outline in which case I'd drag-re-order the tabs so your main one comes first.

I see your 'proto…' series of prototypes. I think this use of a consistent prefix for your prototypes is good as it helps them stand out and you'll recognise them easily in code.

I don't see any rules or actions at this point, which is fine. For your papers and grants containers, consider an OnAdd action to set appropriate prototypes for notes added to the container; it does no harm should the correct prototype already be set.

As to the latex one, all seems OK but there's no much on which to comment.

I really appreciate you taking the time to give them a once-over. I'd really like to use rules and actions but am too much of a novice to create them at this point. For example, once I have a few dozen articles entered, I envision having some code that would assign/create a classification/adornment based on a combination of attributes such as the brain regions & constructs. Does this help explain what I'm trying to accomplish?

Sure. Don't worry about having to build all the cleverness and structure before you start (as you might if using some database). Start with what you know you'll need. Don't be afraid to enter manually attribute values you'd ideally like to automate. It's easier, starting from scratch, to figure action code if you've a clear idea of what you want.

This is where Tinderbox is wonderful - it lets you add structure later - as I'm sure others here who've trodden your path can attest. As you add structure you may need to go back and reset some inheritance (that may mean nothing at this point) but the forums' here to help.

What I would caution is assuming automation will figure out attribute values by 'just' looking at note text for example. My experience - I welcome other views here - is the automation helps most with things like:

setting prototypes. Add a note to a container and magically the key attributes you want are added already.

OnAdd actions, as well as prototype assignments, can set attribute values based on values in the parent container.

Rules. Containers can get counts of child note data or collect unique values for a given attribute (e.g. all discrete tags in use by the child notes).

Rules can monitor completion of important attributes, e.g. flagging notes that are incomplete. Or, use an agent for the same. Which approach you use depends in part on the task at hand and your personal style of working.

Stamps. These are effectively manually applied run-once rules. They can be useful for applying a number of attribute values at once to a selection of notes, of for resetting attribute inheritance.

There's lots more, but it's easy to get lost in the choice. I'd start building out part of the doc with representative data to see what attributes suggest themselves and where automation might help. Don't get too fixed on automation doing some exact thing until you've a feel for it being possible. Tinderbox is flexible if what you imagined can't be done the way you envisaged, likely it's possible to do it - or something close to it - via a different approach.

One final bit of advice, as you're document grows, be prepared to test things out in a new document. That way if you really mess up no harm is done. That's essentially one of the reasons I made the 'starter' document.