RootsWeb.com Mailing Lists
Total: 1/1
    1. Re: [Clooz] Organizing CLOOZ (long)
    2. Lewis
    3. Wow, Joe. What a word of wisdom! Yoda could not have said it better. Lewis ----- Original Message ----- From: "Joe Bissett" <jbissett@txdirect.net> To: <Clooz-L@rootsweb.com> Sent: Monday, November 14, 2005 9:53 PM Subject: Re: [Clooz] Organizing CLOOZ (long) > Hi Thelma, > > Please allow me to ramble on with my thoughts on this continuing question > of "file names", "organizing", etc. > > At 09:57 AM 11/14/2005, you wrote: >>I am a long-time CLOOZ user and love it! >>However, I have not entered any data for a long time and have run into an >>organizational problem. >>I have Documents filed under Births 0001, Deaths 0001, Marriages 0001 and >>Internet Information 1000 etc. >>Internet information is my problem. >>I have begun a file Internet Information 0001. Some internet pages I >>copied have birth ,death and marriage info for several people. If I file >>this under Internet Information 0001 and use the event column for Birth I >>run into a problem with where to enter the marriage and death info. Same >>problem would be if I were to enter all the information under Birth 0001. >>In this case of multiple information data, would I have one copy for each >>bit of information? > > Since I first found CLOOZ years ago, folks, including myself, have been > wrestling with this "organizing" problem. Liz told us early on to use the > most basic KISS principles, but we pressed ahead with our established > norms. Because of the "organizing" problem, when Liz announced a new > version forthcoming some time ago, I ceased entering data with the > intention of inputting my new and old data into the new version in a more > simplified manner. So please forgive me if my memory is "a little dim" > here and there. > > I am now of the mind that many of us have totally over-complicated what I > now perceive as one of the most basic values of the CLOOZ database. By > that I mean that CLOOZ has the structure and architecture to pull together > all sorts of bits and pieces of information in order to allow the > researcher to FOCUS on the genealogy problem being researched, rather than > "how" it is organized. To CLOOZ, it matters not where the information is > found - nor filed; if the data deals with any information about John Doe > of Podunk, AR 1850-1940, all of the data will be available in concise > reports regardless of its source. Assuming correct data entry, the source > of the data will be clearly shown, allowing one to re-visit the "hardcopy" > to verify, cogitate, or for whatever reason we return to paper copies. > > Because we have been raised in a "paper data organization" world, it is > uncomfortable for most of us to think about filing an important document > in any other way. In other words, birth certificates should be filed with > other birth certificates, etc. That's just the way most of us think. > > The challenge to me was to ask myself "why"? > > If I have all of my certificates filed in books or folders by type, then I > have to decide on their "internal" order. Do I file and number the > certificates by date? By family? By surname? At some point we throw up > our hands and make a purely arbitrary decision and vow to "stick to it". > So what we have really done is to create some "defined" filing > architecture that by the nature of our genealogy calling can not be > without problems. Picture twins. Do we number and file the two > certificates alphabetically by given name, or by age or time of birth? > Decisions, decisions, decisions. > > But we, including myself, are "satisfied" because we have a book or file > called Census or Births, with papers numbered CEN0001, CEN0002, etc. > > I finally realized (rather late in the game) that so long as I am faithful > to CLOOZ, it matters not one whit whether my census page is numbered and > filed as CEN0054 or just plain 0054. > > Why do I say this? Because - no matter WHAT arbitrary filing system that > I devise, once my paper information starts to grow, some other Index, or > list, or database will be necessary to help me find what I need WITHIN my > neatly labeled notebook or folder. In other words, once I have a large > file, I need "some" external reference to guide me to find the 1892 Kings > County State Census page within the 300 plus census page print-outs that I > hold. Perhaps I can remember that I've filed these pages by state and by > census year; or did I really do it by state, by county, by census year; or > was that by year, by state, by county? In other words, there is NO WAY > one can devise a perfect "subject oriented" filing system that probably > will not be blown away when we suddenly discover that our long lost aunt > was actually living in Vancouver, BC in 1900, and not in Washington State. > So that Canadian 1901 census page is either filed out of order, or we > "adjust" to the problem, numbering that page CEN0054A, or something like > that. Then three years later we have no idea how we numbered that page, > and we must resort to our CLOOZ database to find it. Could we find it if > filed with all the other census pages? Of course - but we would either > have to resort to some "index", or riffle page by page, hoping to remember > the "sub-architecture" that we invented to fit that particular "anomaly". > > In my humble opinion - this "simple" use of CLOOZ is exactly how things > should be. In other words, through the beauty of the CLOOZ architecture, > if it is numbered simply 0054, then it resides at the 54th "place" in the > paper file, be it notebook, folder, etc. But JOE, I admonish myself, if I > file it with the other census pages at least I will know what file it is > in, and I won't need to search through many file folders. I answer myself > that if I know the document number is simply 0054, it is in the 54th > position in File One, no matter what the file identity is. > > Let's think about one of our personal favorite genealogy family history > books (don't we all have at least one?). Folks, we are extremely happy > that the writer prepared an index at the end listing alphabeticallt every > surname, with given name and listed every page on which our dear ancestor > is noted. I submit to you that this "architecture" is a tiny mini-model > of the architecture that CLOOZ allows. If your ancestor is noted on 43 > different pages, the index points you to each and every page. Without the > index, you would page through the entire book, reading or at least > scanning for the person of interest. To me the page number represents a > CLOOZ file name, and the book represents the CLOOZ database. If there is > an obituary listed in the book on page 79, with wife, brothers, sisters, > married names, residences, etc., listed, they are each individually > referenced to page 79 in the index. We do not seem to have a problem > accepting this architecture in this situation. Such, in my humble > opinion, is the wonderful simplicity and beauty allowed by CLOOZ. > > So Thelma, in the situation you refer to, there would be ONE piece of > paper, i.e., 00024 or some such number. Every tidbit of information in > the reference would sort to it's proper owner, or value. But for you to > check out some tidbit of information as you research using CLOOZ, you > would always be referred to 00024; not in one case to CEN0005, in another > case to BMD0009, etc. > > I have lived my six plus decades working diligently to complicate as much > of my life as possible. :-( Hopefully when CLOOZ TWO arrives, I will be > "mature" enough to break the "filing system" bonds that have held me and > watch my family history information flourish. > > Thanks for bearing with me. > > Joe > > Joe Bissett, PIGGOTT/CUMMISKEY List Administrator/Rootsweb > > I use America's Book CDs in my genealogical research to access otherwise > unavailable primary source material. http://www.abcd-usa.com/ > I support the Godfrey Memorial Library. http://www.godfrey.org/ > > > > ============================== > Search Family and Local Histories for stories about your family and the > areas they lived. Over 85 million names added in the last 12 months. > Learn more: http://www.ancestry.com/s13966/rd.ashx > >

    11/15/2005 12:17:42