Thanks Mathias and Bernd, On Fri, 2008-06-27 at 09:53 +0200, Mathias Bauer wrote: > Hi Tony, > > Tony Walker wrote: > > > I have grown quite tired of paper lab notebooks. They are hard to share, > > expensive, not easily searched, awkward when incorporating electronic > > data (acquired data, digital photos, etc.), etc. There are commercial > > applications which replace paper notebooks, but they are expensive and, > > frankly, I love open source. As a result, I have started writing what > > will become an open source electronic lab notebook. As it stands right > > now, my application uses oowriter as the editor, odt as the document > > format, subversion to track changes (and enforce academic integrity), > > and gnupg. As my application becomes more tightly integrated with > > OpenOffice, I am increasingly thinking it should actually be part of the > > OO suite: oolabnotes or something like that ;-). > > > > I have a lot of thoughts and questions, but I think the most important > > initial questions are: > > > > 1) Is there ANY interest from the OO community for integrating lab > > notebook functionality into OO? > > For me that sounds quite interesting. :-) > > As Bernd Eilers wrote, the simplest way (from a deployment POV) would be > making it an extension. But without a more detailed information about > the functionality and the architecture it's hard to judge whether this > is possible or if we either needed some changes in OOo or even had to > integrate your stuff completely into OOo. > Implementing an extension gives you an update cycle independent from OOo > and a much more stable interface. Of course you must get familiar with > the UNO world of interfaces and services - but even implementing > everything directly in the code code base wouldn't "save" you from that.
Correct. I had already installed the SDK and skimmed the developers guide. However, as I though about how I would shoehorn the functionality I would want into an extension, I began to think that using the extension, from a user's perspective, would be too confusing. After reading Bernd's reply I thought about it pretty hard and spent much of yesterday reading and thinking (instead of doing my work ;-)). There are several ways to think about an electronic lab notebook. Because a paper lab notebook is a title page (often the cover), a table of contents, and a series of pages with one experiment or note per page, one way is an extension of a master document. If you think about the electronic version of a notebook in this way, then adding functionality to a master document sounds like a good way to start. However, why constrain your thinking to the way a paper lab notebook has always worked? My research, like everyone else, as all related, but is composed of "sub-projects" or ideas that branch out from the main line of research. That is, like you, I am thinking hierarchically. I, like most everyone, "skip around" while doing my research. One day, I will do a few experiments that relate to one idea. The next few days, I will be working on other ideas. Then, I will come around to the first idea again. That is, a lab notebook is not something you read cover-to-cover because it won't make sense. The master document approach has the same problem: to find the next experiment, you need to go back to the table of contents or scroll/search (like flipping through the pages of a paper journal). Instead, I would like to see a tree view of my experiments/notes where the branches of show the relationship of ideas and the leaf nodes contain the set of experiments. Of course, you could have multiple tree views, like by author. For java application I have been very slowly working on, I working on an interface where there are tabs along the top which correspond to open notebooks. Within each tab is a split pane where the left is a tree view of the data and the right is (hopefully) and embedded instance of oowriter in read-only mode (like using -view from the command-line). If you want to edit an existing document, you can (hopefully) double click on it and open it in an external copy of oowriter. (Also, the application needs to track the changes, I am currently using subversion to do that.) > > 2) If there is interest, how do I get started with the non-technical > > aspects? That is, who needs to approve, etc. > > I would like to know more about your project. First to be able to give > better answers and second because I'm curious. :-) > > Do you have something to look on? I mean concepts, code, ideas ... ? I have some code and lots of concepts and ideas. Unfortunately, I don't have any of the concepts and ideas in writing -- I don't program for a living so I don't write design docs, etc like I should. I know I am bad. I could write something in OO, we could exchange ideas via email or IM. I'll let you decide. > > 3) How would I start hammering out the overarching technical details? > > For example, how does this application integrate with the others? > > Some time ago I thought about implementing a notes taking application - > comparable to (and hopefully better as ;-)) Microsoft Office OneNote. > This is an application that provides hierarchically organized notes. Yes, I looked at OneNote as well. One of its biggest drawbacks is a lack of revision tracking. That is, a program for labs needs to track changes to a given page to ensure academic integrity, satisfy government agencies, etc. I can expand on this more if you are curious. Also, digital signatures would be important, which OneNote doesn't support either. > The first thing I would try to clarify is the possible file format: > should it be one file for parts of the hierarchy or even the whole > hierarchy? Or should it be one file per note sheet? Would be interesting > to know yout thoughts about that. I have been storing the documents separately, as odt files, where each document corresponds to a single experiment, note, thought, etc. Doing so, makes it easier to organize the notes (files). Also, it makes it easier to organize notes later. For example, you may have a series of general notes about calibrating a piece of lab equipment. After a few months, you may decide to sub-divide these notes. In that case, changing the hierarchy of the documents is simply a matter of moving the files to a new directory, editing a XML doc, or whatever depending on how you want to save those relationships. I have been thinking of keeping all of the individual files (one note each) in a single directory because its easier to manage programmatically. Also, in this way, the hierarchy is logical and disconnected from the physical layout. This approach will allow the user to form multiple hierarchical trees to express the relationships between their notebook entries. For example, I might do an experiment where I discover something interesting about the technique I am using. In such a case, I might want to associate that notebook entry with both the goal of the experiment AND the body of knowledge we are collecting about a technique. To give you a more concrete example, which may not help, we are using a technique called western blot to determine if a specific protein exists in a specific collection of cells that we are interested in. To do this these experiments, we ordered new antibodies and other supplies that we had never used before. As we are performing our experiments to determine if this protein is present we are also learning a lot about using these new supplies and antibodies. Put another way, a single experiment may generate new knowledge in several categories of knowledge. I hope that make sense. By the way, I was thinking of using simple drag-and-drop between the branches of the tree much like a file system (move, copy and link). > I developed a first idea for the integration of the program: make the > notebook a container document that embeds all the note sheets, each one > being an odt document. Editing one of them would be "activating" them in > a document window. This could work fine even as an extension, my > colleague Mikhail Voitenko some time ago provided a Java example how to > use the Embedding API. Interesting. I was thinking of the notes as being odt documents rather than something embedded in them. One of the reasons I decided to use oowriter and odt is that other options, like an HTML editor, lack a good equation editor, drawing program, etc that I would have to write; however, that openoffice has all that wonderful stuff ready to go. In fact, I thought that someday, I might encourage someone to write an extension drawing molecules (I use oodraw now, but a few more features would greatly enhance to process). Also, OO would allow the user to embed spreadsheets in the notebook entries. And one other random thought that will give you some insight into my thinking is, I would like to make it easy for users to integrate programs like Matlab to analyze their data. > This way the notebook application didn't need to take care of the > integration and could focus on the notes organization. A drawback might > be that Writer does allow much more to do with the text than you might > consider useful for notes. But IMHO we could let the users decide what > they want to use and what not. I agree on the flexibility part. That is why I was thinking of this as a separate application. To me, adding some menu items, a tree like table of contents, integration with version control software, and fitting all that into a master document seemed complex and constraining. Tying this together, like I said above you can think of an electronic notebook simply as a digital instantiation of a paper notebook. However, I think that really wastes the potential of the electronic lab notebook. Having said, that I am sure I still don't appreciate the power of extensions, so you all may need to lead me along some more. > Best regards, > Mathias Thanks, I really appreciate the input. I would love to discuss this further. I should also add that I have no attachment to all of this nor am I using this to find a job, so I am open to anything. - Tony Walker [EMAIL PROTECTED] http://mypage.iu.edu/~tonlwalk --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
