Beginning question on structuring a research database

DEVONthink Scenarios
1

I am a new user in legal academia. My database will consist of court cases and pretty lengthy articles, some text and some PDF.

I need a good way to integrate my notes and thoughts on this material. When reading a case or article I jot down some ideas it triggers, or how it is relevant to current and future writing projects.

I understand I can use replicants to categorize a document under several groupings, but what is the best structure to store my thoughts associated with the text? Actually add my annotations to the text of the document, use comments, or have a text file associated in some way with the piece to contain my musings?

Thanks

2

There are many ways to approach database organization and handling notes and comments about documents within the database – depending on personal preferences and workflows.

Personally, I prefer not to modify my original documents, but to create rich text documents that hold my notes and comments – often, I may associate multiple such notes documents to a single source document.

I may “associate” a note to the reference document by using the same Name, with additional text. So if I do a Lookup search on the reference document’s name, the Search window will show me all the notes I’ve created about the reference document.

Or I may create a link in the note to the referenced document, by selecting some text, Control-clicking on the selected text and choosing the contextual menu option Link To… That let’s me “jump” to the source reference by clicking on the hyperlink.

I usually organize my references into conceptually related groups. But when I’m working on a project, such as writing an article, I’ll create a new project group. I may replicate some of the more important references into that project group, perhaps into a subgroup, or duplicate a reference into the subgroup if I plan to “mutilate” that copy by inserting highlights, markups or adding notes to it. If I’m going to insert keyword tags into the Comment field of a source document, I’ll usually do that on a duplicate copy within my project group, as that tag is probably going to be highly specific to the project I’m working on, and probably irrelevant to the next project for which I might use that reference document.

When I start a writing project, I’ll usually start by creating a rich text document in which I lay out to myself the purpose of the project and then the principal sections of the product in semi-outline form. For each section I’ll include notes about what it should contain, and perhaps important references materials are listed. I’ll create hyperlinks as I go, so that this document becomes a working record of the project (eventually, a sort of table of contents of the draft sections) and from it I can quickly “jump” to the draft sections of the article, references, and so on.

But that’s just the way I like to work. I like to do my draft writing within my database, where all the references are at my fingertips and I can use features like See Also or See Selected text to fish for ideas. Others have different working habits. :slight_smile:

3

Bill,

Thanks for the workflow description.

Correct me if I’m wrong, but it seems that right now associating two documents (say the original and one’s notes) requires a separate “container” : making a group and replicating both to it, or having a project doc like you described and listing links to both. (for the moment I’m ignoring embedding a link in the original pointing to the notes because it only works for txt and rtf, and modifies the original document.)

While these both will work to some extent, I propose that they suffer when it comes to searching and moving documents (e.g. you have to move the container, or you have to rely on similar text titles) and just a general disconnect between the structure one is trying to add to the data (relating two documents) and how that is represented in the database model.

I’ve seen the following suggested (so they’re not new ideas) but what about:
a. allowing documents to “contain” other documents just like a group or sheet.

b. having a “linked entries” field in the doc info, to which one can drag DT entries. Fundamentally, it’s not so different from a Path or URL field, yet would really seem to refine this type of added structure.

4

I really don’t see the practical or conceptual difficulties you noted about the need for containers, or moving files.

Suggestion a) would have the result of creating some new filetype, probably of a proprietary nature. But we want to adhere to the principle that all of the documents within your database can be exported out to the Finder, without loss of compatibility with a standard filetype used in OS X. When I first began working with my own DEVONthink database about 5 years or so ago, I made a similar suggestion. But I’ve found that I can do anything that I need to do in relating data (of different filetypes) without the need to create some new package or filetype. And I don’t spend much time on organization of my databases.

Suggestion b), creating links to any other document in my database by drag & drop, can be done simply by Option-Command-Drag & drop of any document into one of my rich text notes. So I’ve then got the searchable text of the Names of the related documents, as well as working hyperlinks to them. A note of that kind is actually metadata about other content in the database, and that’s the way I use such notes. But that isn’t the only way to do that, and I expect we will see some interesting developments.

5

I tried several ways to structure the database. I settled on putting things in folders, in the most coherent and transparent fashion, ordered alphabetically. Of course, an Inbox-Folder at the top. Whenever I need something, I use the search function or see also (this is the “trust the force”-approach :smiley: .) If you loose track of your structure, you could still use a mindmap program or something (I plan chapters this way). DT is great when it comes to “this idea is great, I can support it with this argument, now where was that article ?”. The point is, ideas develop, and when it is time for writing, I just sift through the database to find new impulses, not something that could be 100% planned in advance. Then I mindmap, and when I write (with the mindmap next to me), I switch to DT to find this article or idea, or paste in my text and “see also”, to see what comes up.

annotations: best placed in the document itself, or in a note that is closely attached to the document. For this purpose, I recommend setting Skim as the default PDF editor - I found annotationg PDFs most convenient, although you can’t see your annotations in DT. At the moment, Applications like Acrobat or PDFPen can also annotate pdfs in a way that you see in DT, while Skim is free, and non-destructive.

What I found to be most important, however, is this: Whatever your setup is, you have to continue to feed the database. With a good search function already in place, the decisive factor will be the amount and quality of your material. Otherwise, your database looks like a shiny supermarket with empty shelves.

6