Monday, May 1, 1995 12:16:00 AM GenWeb Item From: Gary Hoffman,ghoffman@ucsd.edu,Internet Subject: DNS Updates To: GenWeb Dear GenWebbers, I made some errors when I updated the name server with the new demo.genweb.org data. However, with the help of many mentors, including some subscribed to this list, I am improving my error-rate. Some have asked why ucsd.edu is the primary name server. I moved ahead using ucsd.edu as the primary name server because it is a very well-connected machine. It is the main mail router and name server here on campus. We sit here nextdoor to the San Diego Supercomputer Center which is on the NSF backbone (or what is left of it). However, since I registered the domain, ucsd.edu has become overloaded and many functions have been offloaded to secondary machines, including two on-campus name servers, ns1 and ns2. I have read with interest the proposals to use DNS as a part of the genweb name link database. However, I do not want to put this additional burden on ucsd.edu because it has the potential of becoming a heavy load. Meanwhile, my department is bringing up a UNIX machine (486/50 with BSDI) that is very lightly loaded. It can serve in the interim. And, within a few weeks, we will have a Sun or SGI machine here in my department. When it arrives, I will be able to put some of these tasks on it. What appears to be delay is actually much behind-the-scenes work to set up the infrastructure to make this happen when we are ready. I know everyone is impatient. Sorry, I am learning as I go along, too. Let's keep the discussions here. We need both the technical, legal, and human sides of our project represented here to just keep it in balance. Cheers, Gary *************************************************************************** *Gary B. Hoffman, Computer/Language Lab Director e-mail: ghoffman@ucsd.edu* *Graduate School of International Relations and Pacific Studies (IR/PS)* *University of California, San Diego (UCSD) voice: (619) 534-7733* *9500 Gilman Dr., La Jolla, CA 92093-0519 USA fax: (619) 534-5727* *************************************************************************** Monday, May 1, 1995 2:13:23 AM GenWeb Item From: steele@census.works.ti.com,Internet Subject: Some comments about WWW and GenServe To: GenWeb I do agree with Tom Wetmore's comments on GEDCOM (I at least should be able to input a GEDCOM file and then turn around and export it and get the same thing), however I think we're trying to tackle too many problems by solving GEDCOM & GENWEB at the same time. GEDCOM was designed for the LDS purposes. It just so happens that over the years other programs started to use it. So instead of bogging down on trying to solve that problem AND representation on the net, why can't we back up to, "How do we represent Family Information on the Web?". I frankly prefer to have some family group/narrative linked together on a page generated by some utility directly from my genealogy database, whether that's Lifelines, ROOTS IV, TMG or PAF. If we come up with a viable representation for the Web, there are always people ready to step forward and write the utilities. Why a narrative? I do not give out my GEDCOM to just anyone. I do exchange paper information, freely. Yes, my GEDCOM file is on GENSERV, but Cliff Manis and I had a LONG talk before I submitted it. The information is there for someone to use without the abiliity to take my GEDCOM file in its entirety. I want to exchange primary and secondary sources with other serious researchers not 'collect' GEDCOMs of unreliable data. So I personally will be examining how to index my genealogy in such a narrative form so that from the index page, I can go to any arbitrary page of narrative via HTML links. Now for a bizarre idea.... Has anyone tried some indexing tricks? How about some way to determine an event was 'similiar'. We have SOUNDEX for the names, Can some variation to include numbers be used to know that KIRKPATRICK, Marty B 9 May 1845 TX Shelby CO KIRKPATRICK, Martha B circa 1845 TX are approximately the same person and/or event? couldn't we use a scheme like this allow for a highly distributed index? (All people with simliar names go to one place, then with similiar times and finally to the exact locality) This would keep people from staying on the starting index page for long at all.... Just some food for thought. Jeri Monday, May 1, 1995 9:14:00 AM GenWeb Item From: Gary Hoffman,ghoffman@ucsd.edu,Internet Subject: Re: genealogy/genweb To: GenWeb Morris said: (response below) I have been watching all the mail on genweb for some time now and it seems to me as though no body is really interested in the average genealogist. I mean the ones who have been at it for several years and maybe retires, like myself. We are in favor of all the resources there are on the internet, but most and most being probably 90% don't know any thing about programming or html transfer fromgedcom to html. I am not sure i want to learn, but i do want to see the genealogy put to good use. I am leaning toward genserv. maybe that's not the answer, but if I am not able to have some imput, then there is going to be a lot of people like me who won't have any imput either. I guess what I am trying to say is lets get on with it. Whatever it is. I have an awful lot of information I could be sharing with other people and like wise I could also get some informatiom from others. Genealogy is sharing. If I was completely out here doing this all alone then I probably wouldn't get very far, but with others helping we all can benifit. I dont know if anyone will read this or respond. But, do take us folks into consideration when putting this together. We want it and if we can imput our information think how much more everybody gets out. I will probably still follow gen web, but it just got to technical for me. and with all the differing opinons, well it was just to much to print out. Keep at it and let me know if there's anything I can do. Maybe I am not a programmer or am not connected to a college, but I am computer literate and know a lot about genealogy. Thanks for listening Morris Plummer mplummer@soltec.com Morris A. Plummer --------- Morris, I remember when they were building a freeway not far from my home. They seemed to take a long time surveying, moving dirt, relocating drainage, and building concrete forms. I just wanted to get out there on my bike and go, but they took so long. Well, when it was finished, I wasn't allowed on my bike, but I did drive a car on the new freeway and soon it became a routine event, just hopping on the freeway to go somewhere, like it had been there since Adam. I understand your frustrations. I want to use genweb right now. But we are trying to build it to last more than 6 weeks and it requires some planning and lots of coordination, some of it technical. When it is done, the technical, behind the scenes stuff will just work and no one will notice that it is there. If you are interested in watching the freeway being built, stick with us. Otherwise, we'll send you a notice on opening day and you can cut the ribbon. Cheers, Gary *************************************************************************** *Gary B. Hoffman, Computer/Language Lab Director e-mail: ghoffman@ucsd.edu* *Graduate School of International Relations and Pacific Studies (IR/PS)* *University of California, San Diego (UCSD) voice: (619) 534-7733* *9500 Gilman Dr., La Jolla, CA 92093-0519 USA fax: (619) 534-5727* *************************************************************************** Monday, May 1, 1995 12:01:55 PM GenWeb Item From: olsen@cs.byu.edu,Internet Subject: GEDCOM standards To: GenWeb Some standard representation for genealogical information is going to be important if we are to build a community of interoperating software packages. Perhaps casting off GEDCOM is the right thing to do for several reasons. 1) The standard is ambiguous and has several technical problems in the way data is modeled that I won't go into here. The key point is that definitions need to be tightened up. 2) The new standard needs to become a registered trademark with serious mechanisms for verifying compliance. Those software providers who do not comply with the standard must be legally forbidden to use the name in their promotional literature. 3) Such a standard is the heart of a community and the defining, arguing, comprimising and resolving of differences is part of a healthy computing community. ____________________ Dan R. Olsen Jr. Computer Science Department Brigham Young University Provo, UT 84602 (801) 378-2225 FAX 801-378-7775 Monday, May 1, 1995 2:47:23 PM GenWeb Item From: T.T.Wetmore,ttw@beltway.att.com,Internet Subject: Re: GEDCOM standards To: GenWeb Dan Olsen (>): >Some standard representation for genealogical information is going to be >important if we are to build a community of interoperating software >packages. Perhaps casting off GEDCOM is the right thing to do for several >reasons. I can agree with this, but I have a reservation, covered below. >1) The standard is ambiguous and has several technical problems in the way >data is modeled that I won't go into here. The key point is that >definitions need to be tightened up. True. But, a proviso. We often equate standards and tightened definitions with syntactical format restrictions. For example, strict rules for encoding names, dates, places, event types, marriage status, and so on. It is my contention that, for humanistic data, syntactical restrictions can be counterproductive. I believe that it is definitely possible to tighten up semantics in standards, but at the same time leaving the syntactic standards relaxed enough to handle the kinds of data generally found in genealogy. On this point I have had many long arguments with many people, and I am definitely in the minority. I have come to the conclusion that the notions of imprecision and ambiguity are anathema to computer people. I have discovered that most computer people are so ingrained with the notion that "computer == precision" that they cannot even conceive of the notion of institutionalizing imprecision. They view imprecision in genealogical data as a problem to be fixed rather than the beautiful reality that it is. The essence of genealogical data is its imprecision, ambiguity, probabilistic nature, incorrectness, unsureness, what have you; any standard for handling such data must be designed for these characteristics. Forcing this kind of data into syntactic formats designed for precise, unambiguous and correct data is counterproductive. From my observations the mind set of the typical standard writers and software system authors in the genealogical arena is to do such syntactic forcing; which is one of the reasons why I believe the genealogical standards and software situation is in such a dire state. As I have said in this forum before, "Beware the tyranny of relational thinking." I have one rule of thumb for judging a genealogical software system. Is it based on a standard relational database? If so, it can't be flexible enough. I've p***ed off a lot of people in the past for claiming this. So be it. I believe that the LifeLines approach has been the only widely available experimental test bed for mixing both the structure and the flexibility required for genealogical databases, and that the results of those experiments clearly support my arguments above. I want to issue a strong warning against "context-free" thinking in genealogical standards writing. >2) The new standard needs to become a registered trademark with serious >mechanisms for verifying compliance. Those software providers who do not >comply with the standard must be legally forbidden to use the name in their >promotional literature. This sounds pretty heavy duty to me, but I certainly agree with the compliance idea. >3) Such a standard is the heart of a community and the defining, arguing, >comprimising and resolving of differences is part of a healthy computing >community. Agreed. Tom Wetmore Tuesday, May 2, 1995 9:50:59 AM GenWeb Item From: Bill Minnick,svpafug@rahul.net,Internet Subject: Re: ROOTSBOOK To: GenWeb From: Bill Minnick TO: Genwebbers My comments on GENWEB are (and have been) from the user's (customer's) perspective. I represent the 1500-person Silicon Valley PAF Users Group in Santa Clara, CA (URL: http://www.rahul.net/svpafug). We teach people how to put their genealogy on their personal computer (DOS, Windows or MAC). We have written a popular guideline for documenting sources, and we are helping and encouraging people world-wide to include sources with their genealogy. The final measure of genealogy value is in the source citations. (See the Richard Austin Book at the above URL.) I also represent 250 folks in the Austin Families Association of America (AFAOA) (URL: http://www.rahul.net/afaoa ). I have coached 70 members of this group in the preparation of Austin descendant data bases using the methods developed in our SVPAFUG organization. So as GENWEB progresses, we'll have increasing interest in the approaches we adopt for documenting sources. I am keeping the 1750 folks in teh above groups appraised of GENWEB developments, and they are becoming evermore interested in our progress and usually ask when they will be able to place their data bases on the Web. To this end, we want to encourage those of you involved in GENWEB who are working on (or have provided) the Genealogy Book (data base) publishing tools (software and scripts) now being demonstrated on the Web. Specifically, we thank Tom Wetmore (LifeLines), Gene Stark (GED2HTML) and Birger Wathne (cgi-bin scripts) for their early efforts which we used to put the Richard Austin Book of 6492 persons on the Web (see above URLs). We appreciate Tim Doyle's efforts to streamline the indexing and delivery of on-the-fly html pages (see a test run of an updated Richard Austin data base of 8114 persons at URL: http://doit.com/tdoyle/genweb/Austin/Austin.html ) We appreciate advanced word from Mickey Lane of his efforts to help us publish Genealogy on the Web. I'll comment on his latest note: Mickey Lane writes: > >With all the discussion in recent days about indexes and linked >databases and so forth, I think it would be appropriate to spell >out what I'd like to see happen to the ROOTSBOOK software package. > > (Mickey descries Phases I - IX) > I especially like Mickey's forward thinking in his last two phases for ROOTSBOOK, and his statement on ownership: >Phase VIII - Devise a policy for distributing the public databases >around the different servers. Put these databases under the same >protection that any commercial enterprize might use: scheduled >backups, recovery procedures and sufficient redundancy to accomodate >network hickups and so on. Get to the point where we have one >global database. (A lot of notes recently have pointed out that >different people have different opinions about who begat whom. One >global database does not imply that these differences of opinion >have to be resolved, it implies that all of the information declared >to be public live within one storage scheme. If we need six entries >for the same person outlining six different presumed relationships, >so be it.) Mickey, I fully agree with you on the need to save "all six entries" at least until an entry can be proven correct through preponderance of evidence, or discovery of a primary source >Phase IX - Implement interactive updates to the global database. >It'd be a shame if someone were to enter data into something that >wasn't permanent or was the 'wrong one.' "Interactive updates" will be, in the end, what distinguishes GENWEB from all other schemes for publishing genealogy. Once the value of this feature is understood, the world will beat a path to GENWEB. (That is assuming we resolve all of our present discussion issues like "indexing", "addressing" and "linking" within the data bases on GENWEB. > >(*) "Assume ownership" can have several meanings. If you do the library >work, the knowledge and credit is forever yours. You own it. On the >other hand, you can't have two people editing the same file. Talk to >any software engineer about it. Ownership in this sense refers to >the person who has responsibility for making changes to the file. You, >as the creator of the knowledge, may direct the person who currently >owns the file on how to change it -or- you may do it yourself. If you >do it yourself, you're temporarly taking ownership of the file and it >stops being a public file and becomes a private one. When you finish, >you re-submit it and it becomes a public file again or more accuratly, >becomes *another* public file. > TO ANYONE WE'VE MISSED, we also thank you for your efforts in GENWEB publishing tools. I beleive the results of our combined efforts can and will make a profound difference in the quality and completeness of genealogy in the near future. Regards, Bill Minnick Tuesday, May 2, 1995 2:41:12 PM GenWeb Item From: T.T.Wetmore,ttw@beltway.att.com,Internet Subject: Whither UNIX LifeLines? To: GenWeb Whither UNIX LifeLines? As many of you know or have figured out, I haven't done much with UNIX LifeLines in a long time. I have been fiercely busy both at work and with unexpected family activities. Most LL energy has been spent on readying an up to date reference manual for the UNIX LL 3.0.2 release, and a little has been spent experimenting with a Mac version of LifeLines, which will be, for all intents and purposes, a redesigned system. I haven't touched that, however, in a couple months. I've still managed to send my usual allotment of tirades and p*ss off an appropriate number of persons, so I'm still on track in that area. I'm not shy about discussing my views on structure, flexibility, database storage formats, standardization, GEDCOM, the state of genealogical software and so on, nor do I pull punches about what I believe to be the very low quality of genealogical software in the commercial market, or the abysmal state of official GEDCOM, nor am I bashful about responding when I see posters to our Usenet groups and mailing lists describing their own great ideas for following down the mistake ridden paths of others, or simply being jerks. Back to LifeLines. LifeLines is the GenServ engine, and the database engine at a number of GenWeb sites. I didn't realize how powerful LifeLines would prove to be in these settings. I simply needed flexibility so I could store anything, and I needed programmability, so I could generate any output or statistics I wanted, so I gave LifeLines these features. These are exactly the features needed for the Internet applications, and no other widely available system has them. GenWeb sites must now either be run by LifeLines or by home brew systems. Other software packages seem to be in the works, which is great, but only LifeLines is already there. Though both these features (flexibility and programmability) distinguish LifeLines, it is the programmability feature that makes it unique, making LifeLines the ultimate in genealogical utility platforms. Need an HTML generator? Write a LL program. Need an index generator? Write a LL program. Need a special GEDCOM to/from anything translator? Write a LL program. This is the appeal of LL as a GenWeb engine. Just about any need can be met by one or more custom LL programs. Want to generate a book complete with text, figures, charts, footnotes, indices? Write a bunch of LifeLines programs. All this is leading to some ideas about how to evolve UNIX LifeLines. I see the need for more and more programmability. More needs for reading files have recently been discussed. I've started some work along those lines that you'll hear about soon. Some of you know I have already laid down the infrastructure within LifeLines that allows LL programs to actually change the contents of its databases (yes, that's exactly what I said, a LL program can change the contents of a database), something I have been conservative about in the past. Think about this feature for a moment; it boggles the mind. You could write LL programs to automate merging and family discovery operations. Imagine loading a bunch of vital statistics into a LifeLines database (remember, LL now supports events as well as any other type of user defined records), and then running an experimental LL inferencing program that automates, using your own experimental family discovery algorithms, the creation of sets of persons and family records, complete with links back to the event records, that best fits a family structure over top the vital record data. Don't trust such a program? Have the program stop and check with you any time its wants to add a record or make some other change, showing you what it wants to do and why, but giving you ultimate yeah and nay control. Sound like a pipe dream? All I have to do is turn on a few options and add a couple new builtins to the programming language, and it's there. But you can also imagine why I have been a little leary of giving LL programs such power. Power to do good equals the power to destroy! However, it's clear that GenWeb projects will need extra power. For example GenWeb may need the ability to automate database merging, or to automate the addition of inter-database links to records, and so on, all of which could be done by LL programs allowed to change databases. I find this very exciting. The LL programming feature has evolved over the past few years from its report generation beginnings, now to statistics and querying, and soon to full control over files and databases. Hmm. Responses, comments, disagreements, rejoinders, suggestions, flames, criticisms, rebuttals welcome. Tom Wetmore, ttw@beltway.att.com, 5/2/95 Tuesday, May 2, 1995 3:56:50 PM GenWeb Item From: Mickey Lane,MLANE@csi.compuserve.com,Internet Subject: re: ROOTSBOOK To: GenWeb Bill writes: >We appreciate advanced word from Mickey Lane of his efforts to help us >publish Genealogy on the Web. Status report: I have the wayward compiler, it's installed and works like a champ!. Most of the programs have been recompiled and work fine. (Y'all have any clue just how fast an Alpha is? Awsome!) The one last step is locating the machine in a more or less permanent place on the net. I hope to turn it loose this week. Mickey. Wednesday, May 3, 1995 6:40:27 AM GenWeb Item From: Jim Isaak- isaak@csac.ljo.dec.com,isaak@ljo.dec.com,Internet Subject: Copyright and genealogical info To: GenWeb I've been tracking the format and standards questions here with interest (having a batch of stuff I'd like to convert to HTML). However, I'd also be interested in what copyright impact there may be in the sense of loss of use by researchers. I understand that some online services, and publishers are asserting copyright ownership over materials online, either the material "as submitted", or compendium rights (combinations of the materials) etc. An example of this is on some CD-ROM's I purchased with genealogical information on them. When I printed out the gedcom file, every record had a copyright statement/assertion. It is hard to belive that my great-grandfather's name and/or birth date is somehow limited access material. One interesting variation of this is the "Free Software Foundation's" "copyleft" type copyright statement; which asserts that any person can copy the materials including for re-distribution, however they must be distributed at cost, and with this same copyright privilage provided to all receipiants. (ie. you can't assert any new copyright interests over the materials you get from them). ... in many areas of commerce this does not make business sense; but in the domain of genealogical research, where sharing of data is the norm, it could make a lot of sense. Any experience with the implications of copyright, either just putting things on the web (where I suspect you do not lose any rights, although you may want to be explicit), or putting things through various services (online suppliers, or publishers, etc.)? Thanks, jim isaak Wednesday, May 3, 1995 7:18:45 AM GenWeb Item From: Scott McGee,smcgee@microware.com,Internet Subject: Re: Whither UNIX LifeLines? To: GenWeb Tom, I have one question. What about gengine? I am currently running what I feel to be a fairly nice genweb site (still inaccessible from offsite) using LifeLines, but it is kind of kludgy writing the cgi scripts to handle the LL user interface without a user. I don't want to be seen as one who keeps bugging you about it, but since you asked, I thought this was a good time for an update if you can. Another thing I would like to do is to compliment you on this wonderful peice of software. I can imagine without it that I would have been forced to do something like buy a PC or some such, and get PAF or some other such package. I KNOW I would never have been happy with that solution. I like unix and I like LifeLines. A LOT!! Scott If at first, you don't succeed, | smcgee@microware.com (Scott McGee) go fry a hen. After all, fried | ----------------------------------------- chicken beats failure any time. | I was paid $5.00 to express these views! -------------> http://www.cc.utah.edu/~sam8644/homepage.html <------------- Wednesday, May 3, 1995 9:20:13 AM GenWeb Item From: Rik Vigeland,rikv@wv.MENTORG.COM,Internet Subject: Copyrights To: GenWeb In response to Jim Isaak's concern I am reposting an article from last June which was either here or in ROOTS-L. Basically, you can NOT copyright information and facts but you CAN copyright formats such as compendiums and indexes. (Hope I haven't violated anything by adding a couple notes! ;) Read on! Rik Vigeland rikv@wv.mentorg.com Date: Tue, 21 Jun 1994 16:10:29 -0400 From: Diane Richardson Subject: IGI and Copyright Law Once more unto the breach, dear friends.... 1. Factual Data Although John Chandler makes a good point about the "fictional" nature of much of the IGI (a problem which the FHC is trying to rectify), the IGI is intended to be a record of factual data, whether accurate or not. Factual data are not, and never have been, protected under Title 17, USC (US Copyright Act), or any other copyright law in this country or elsewhere. If factual data were protected under copyright, I could send in my $10 fee to the Copyright Office and register "Declaration of Independence 4 July 1776" or "2+2=4" and sue the pants off every second-grader in the country. Works of authorship protected under copyright are "literary works, musical works, dramatic works, pantomimes and choreographic works, pictorial, graphic and sculptural works, motion pictures and other audiovisual works, and sound recordings." (para. 102, Title 17, USC). I will deal with compilations in a later paragraph. 2. Data Ownership It does not matter if the data in the IGI are public records, private records, restricted records, or anything else. The LDS was under no obligation to make this information available to the public, but they chose to do so through the IGI. It is now public factual data (because the LDS made it so) and cannot be protected under U.S. Copyright Law any more than "2+2=4" can be protected. If the LDS were to decide to withdraw this information from public use, they would have every right to do so. If the LDS chose to allow only certain people access to the IGI, that would be within their right as owners of the IGI. They can do anything they like with the IGI, but they can't claim that the data in it are protected by U.S. Copyright Law. 3. Copyright Registration Anyone can register anything with the U.S. Copyright Office. It is merely a matter of filling out a form and sending it, along with a fee and copies of the work, to the Copyright Office at the Library of Congress. The Copyright Office makes no determination regarding the applicability of copyright protection to any work submitted to them. They merely register the work. Period. Validity of copyright protection is determined by a court of law when someone sues another for copyright infringement. There are no copyright police to break down your door and seize your illegal copy and take you to jail (not yet!). Anyone can print a copyright notice on anything they want. You are not even required to register with the Copyright Office before doing so. As stated above, the decision regarding copyright protection and/or infringement is made in a court of law, not by a "c1994" running along the bottom of every page. In fact, when I see an overuse of the copyright statement, I sort of automatically assume it's there to try to "bully" people into submission rather than to inform them of a fact. 4. Compilations of Factual Data Now we come to the only complicated part of my argument. The Copyright Act of 1976 included in paragraph 103 "compilations and derivative works," but that paragraph only dealt with compilations of literary, etc., works (e.g., an anthology of poetry). Generally, the courts were willing to extend copyright protection to compilations of factual data under the "sweat of the brow" argument. The argument went, more or less, that even though compilations of factual data did not contain any original creative work, the effort expended in producing them warranted copyright protection. The IGI would warrant protection under the "sweat of the brow" argument, since it's not a work of original creativity like a novel or a ballet or such. [ I think that if by the sweat of YOUR own brow, however, you were top reformat the information to suit a (slightly) different purpose, you would have your own work. Just don't use someone else's work letter for letter, page for page, column for column, etc. But, read on some more! -- RikV ] However, in 1991 a copyright case was brought before the U.S. Supreme Court. Feist Publications had been going around gathering up telephone books in little towns and reprinting them in directories that included much larger geographic areas. Rural Telephone, the phone company who had compiled the books, sued Fiest for copyright infringement. The U.S. Supreme Court unanimously decided in favor of Feist. They declared that the "sweat of the brow" argument could no longer be used as a reason for copyright protection. Feist (and everyone else) can copy all the phone books they want and republish them without violating the copyright act. I would also point out that telephone numbers, data "owned" by the telephone company, was copied along with names and addresses--and all without violating copyright. (The analogy here is to temple ordinance data). The Supreme Court decision, written by Justice Sandra Day O'Connor, was very specific in stating that the decision was not made for only one case but was to serve as a precedent in similar cases of copyright protection of compilations of factual data. Henceforth, compilation copyright infringement cases were to be based on the amount of original, creative work by the copyright holder, not by citing the amount of effort that went into compiling the work. There have been many additional suits since 1991, but the Feist precendent has been upheld in them all. Understandably, the 1991 decision created a ruckus in the publishing and software businesses. Most have found additional legal means (like licenses and leases) to protect their property since copyright protection is no longer guaranteed. So, now you understand why you get so many of those darned phonebooks nowadays instead of just one like you did years ago. You also understand why all that gobble-de-gook is written on the envelope that contains the new software you buy. And, perhaps, you may now understand that the only way the IGI data can be protected by copyright is if each entry went something like this: "On a cold, dark morning, 31 Jan 1883, Horatio Splat came into this world in the quaint, picturesque village of Blowhard, which has since been renamed Windcrest, Mayfield Co, MA. If anyone would care for a bibliography on the 1991 Supreme Court decision, please e-mail me (Diane) and I'll gladly provide one. Diane Richardson ao579@yfn.ysu.edu Wednesday, May 3, 1995 9:42:35 AM GenWeb Item From: Anders Andersson,andersa@Mizar.DoCS.UU.SE,Internet Subject: Re: Copyright and genealogical info To: GenWeb Jim Isaak writes: > An example of this is on some CD-ROM's I purchased >with genealogical information on them. When I printed out the gedcom >file, every record had a copyright statement/assertion. It is hard to >belive that my great-grandfather's name and/or birth date is somehow >limited access material. The information as such isn't covered by copyright, but a specific expression of that information (such as a GEDCOM record) may be, and the compilation of several GEDCOM records certainly is. You may copy individual items of information to some extent, but don't ask me to what extent (lawyers exist for the purpose of pinning down those details). It also depends on how you are going to use the data; you may usually copy quite a lot for your personal use, but if you are going to publish your compilation (and here I'd assume distributing freely over the Internet more or less counts as "publication", even though that may not be the case in other respects), your use of such a CD-ROM may be subject to severe restrictions. > Any experience with the implications of copyright, either just >putting things on the web (where I suspect you do not lose any rights, >although you may want to be explicit), or putting things through various >services (online suppliers, or publishers, etc.)? You don't lose copyright by distributing or allowing others to distribute, since copyright was invented for the very purpose of protecting published or publicly performed works. However, publication means that you restrict your rights somewhat, by for instance allowing others to quote from your work within the limits of the "fair use" doctrine (the author retains full control over unpublished works only). It's not clear to me whether electronic distribution counts as printed publication in this sense. The details may vary somewhat between countries. I think I saw something about special copyright provisions for "digital data" in the USA (in Sweden, "computer programs" are protected by special clauses, but that term hardly includes every kind of work that can be stored on a CD-ROM). Does anyone know more about that? -- Anders Andersson, Dept. of Computer Systems, Uppsala University Paper Mail: Box 325, S-751 05 UPPSALA, Sweden Phone: +46 18 183170 EMail: andersa@DoCS.UU.SE Wednesday, May 3, 1995 9:42:35 AM GenWeb Item From: Anders Andersson,andersa@Mizar.DoCS.UU.SE,Internet Subject: Re: Copyright and genealogical info To: GenWeb Jim Isaak writes: > An example of this is on some CD-ROM's I purchased >with genealogical information on them. When I printed out the gedcom >file, every record had a copyright statement/assertion. It is hard to >belive that my great-grandfather's name and/or birth date is somehow >limited access material. The information as such isn't covered by copyright, but a specific expression of that information (such as a GEDCOM record) may be, and the compilation of several GEDCOM records certainly is. You may copy individual items of information to some extent, but don't ask me to what extent (lawyers exist for the purpose of pinning down those details). It also depends on how you are going to use the data; you may usually copy quite a lot for your personal use, but if you are going to publish your compilation (and here I'd assume distributing freely over the Internet more or less counts as "publication", even though that may not be the case in other respects), your use of such a CD-ROM may be subject to severe restrictions. > Any experience with the implications of copyright, either just >putting things on the web (where I suspect you do not lose any rights, >although you may want to be explicit), or putting things through various >services (online suppliers, or publishers, etc.)? You don't lose copyright by distributing or allowing others to distribute, since copyright was invented for the very purpose of protecting published or publicly performed works. However, publication means that you restrict your rights somewhat, by for instance allowing others to quote from your work within the limits of the "fair use" doctrine (the author retains full control over unpublished works only). It's not clear to me whether electronic distribution counts as printed publication in this sense. The details may vary somewhat between countries. I think I saw something about special copyright provisions for "digital data" in the USA (in Sweden, "computer programs" are protected by special clauses, but that term hardly includes every kind of work that can be stored on a CD-ROM). Does anyone know more about that? -- Anders Andersson, Dept. of Computer Systems, Uppsala University Paper Mail: Box 325, S-751 05 UPPSALA, Sweden Phone: +46 18 183170 EMail: andersa@DoCS.UU.SE Wednesday, May 3, 1995 4:36:37 PM GenWeb Item From: Mickey Lane,MLANE@csi.compuserve.com,Internet Subject: Request for volunteer spec writer To: GenWeb Greetings, I presume that the Genweb community is made up of people from all sorts of disciplines. Hopefully, one of them is capable of writing a 'world class' technical specification document. If so, I'd like to ask that person if they'd be willing to apply their talents to the ROOTSBOOK database specification. I expect the document to run less than 30 pages. If interested in taking a shot at it, please contact mlane@csi.compuserve.com. This constitutes volunteer work and while the document may be under some type of copyright protection, it will be available to anyone without cost or obligation. Thanks, Mickey. Thursday, May 4, 1995 7:14:40 AM GenWeb Item From: Nancy Sween,nsween@falcon.cc.ukans.edu,Internet Subject: Re: Copyright and genealogical info To: GenWeb About copyrighted genealogy, the only example I've seen on my line that was copyrighted by the Mormons had incorrect and incomplete information in it, so wouldn't be worth using or copying anyway. Nancy Sween http://falcon.cc.ukans.edu/~nsween/inter-gen.html Thursday, May 4, 1995 7:51:31 AM GenWeb Item From: Jim Isaak- isaak@csac.ljo.dec.com,isaak@ljo.dec.com,Internet Subject: information accuracy To: GenWeb Nancy Sween writes: >>had incorrect and incomplete >>information in it, so wouldn't be worth using or copying anyway I discovered that the information on the CD-ROM I had was similar ... with impossible dates (mother born after child) and relationships ("person is own grandfather, inspite of any Ray Steven's songs implying that this is possible) One very useful tool would take a file (GEDCOM or other) and test it for coherence, and plausability ..... (one problem with GEDCOM files off the CD is that not all children are pointed to by marriages that the child record claims is the parent relationship; etc etc etc. ...) ----- Related to this is a question of "how to estimate birthdate" .... I've run into strings of folks where both ends of the string have a well defined birth date, but the folks inbetween do not. --- a bit of math leads one to some reasonable assumptions or estimates about birth dates within that string. (I assume "Est" is the appropriate prefix for such a date) ..... Guidence on this sort of thing would be useful within the GENWEB context so we know what to submit, and what to expect. Searching can be "date focused" within this context once we have some agreement on context. Jim Isaak Friday, May 5, 1995 6:59:57 AM GenWeb Item From: T.T.Wetmore,ttw@beltway.att.com,Internet Subject: LifeLines and Programmable GEDCOM Database Updates To: GenWeb Liners, et alia, First major addition to LifeLines 3.0.3 is now working. LifeLines programs can now modify persons in databases. Here is a summary of some built-in functions of interest. First, here are three built-ins that were snuck into LifeLines some time ago: createnode(STRING tag, STRING value) --> NODE This built-in creates a GEDCOM NODE from two strings, a tag value and a value value. [Yes I know, how can you give a node a cross reference key -- details, details!] addnode(NODE new, NODE parent, NODE prev) --> VOID This built-in inserts a GEDCOM node into a node tree. The first NODE is the new node (probably created by createnode, though not necessary); the second node is the node to be the parent of the new node (cannot be NULL, implying you cannot add a new root node to a node tree, a very good thing indeed); the third node is the node that is to be the previous sibling of the new node (can be NULL, in which case the new node becomes the first child of the parent node). deletenode(NODE node) --> VOID This built-in removes the node from a node tree. These built-ins may look like they can be used to modify LifeLines records. In fact they only affect the in-RAM version of the records, not the actual database records. They can in fact be used to modify a database in an indirect way, but I won't get into that (involves editing a record after running a program that changed the internal form of the record -- you may get the picture). Early this morning I added the following new built-in: writeindi(INDI indi) --> VOID This built-in writes the internal, in-RAM version of a person record to the database. All validity checks that are normally run on persons are run here also. That is, the person must have a valid NAME line, you cannot have added or removed FAMC or FAMS lines to the person. All other logistics are also done properly: for example, if your program added NAME lines, the updated person will get indexed under all the new names; if you add a REFN line or change the value of a REFN line, all the right updates happen. In short, all the weird little looseends that could be left hanging by programs modifying persons in wierd ways are handled properly (you wouldn't expect less would you!). As a trivial example of a program that changes a record in a database, consider the following crazy program: - - - - - - - - - - - - - - - - - - - - - - proc main () { getindi(indi) if (not(indi)) { return() } list(parts) extractnames(root(indi), parts, nparts, sur) set(newname, concat(getel(parts, sur), "/", getel(parts, 1))) set(newnode, createnode("NAME", newname)) addnode(newnode, root(indi), 0) writeindi(indi) } - - - - - - - - - - - - - - - - - - - - - - This program adds a new NAME line to a record. The new name has a first name which is the surname of the person name, and a surname which is the person's first given name. I said it was crazy. So, if you had the following person in your database: 0 @I45@ INDI 1 NAME James Richard/Joyce 1 BIRT 2 DATE ... ... then after running the above person on this person, the record for this person in the database would become: 0 @I45@ INDI 1 NAME Joyce/James 1 NAME James Richard/Joyce 1 BIRT 2 DATE ... ... and the person would be properly indexed under both versions of his (her?) name. In this program especially note the use of the createnode, addnode and writeindi built-ins. Pretty slick! As I said before, the implications of this teensy, weensy new little built-in are fairly great; I'll leave it your fertile imaginations to conjure hundreds of ways of destroying your own databases! I imagine some GenWeb folk are already contemplating the many possibilities for automating database maintenance, updates, and so forth. Of course, writefam, writeeven, ... are not far behind. Once we have these under our belts, how would you feel about, tum te tum, createindi()? And once we have createindi(), createfam(), mergeindi(), and a few others, LifeLines has finally entered what I have been calling the third generation. By this I mean a system that can process databases, running inferences, coming to conclusions, modifying the data, creating and deleting records, and so on, based on heuristics and other rules, all untouched by human hands. Maybe one of you will write a LifeLines procedure, let's call it do_my_research_for_me(). This is not as far fetched as it sounds. I have a logic programming subsystem that I wrote many years ago (a very fast unification algorithm with infrastructure for storing axioms and theorems and proving theorems, all packaged as a C library) that could be added to the programming language fairly easily, giving programmers full, Prolog-like, "fifth generation," logical access to the their databases. This is also not as far fetched as it sounds. I hope I have whetted a few appetites. Tom Wetmore, 5/5/5, ttw@beltway.att.com, your programming pal Friday, May 5, 1995 11:35:44 AM GenWeb Item From: Mickey Lane,MLANE@csi.compuserve.com,Internet Subject: ROOTSBOOK web server To: GenWeb The ROOTSBOOK web server is temporarly! on line at http://mlane2.inhouse.compuserve.com:8000/GenWeb.htm Please address questions and comments to the GenWeb list. Mickey. Friday, May 5, 1995 1:21:57 PM GenWeb Item From: Bill Minnick,svpafug@rahul.net,Internet Subject: Re: information accuracy To: GenWeb JIM ISAAK Writes: > > I discovered that the information on the CD-ROM I had >was similar ... with impossible dates (mother born after child) >and relationships ("person is own grandfather, inspite of >any Ray Steven's songs implying that this is possible) ..... > (one problem with GEDCOM files off the CD is that >not all children are pointed to by marriages that the child >record claims is the parent relationship; etc etc etc. ...) >----- > Related to this is a question of "how to estimate >birthdate" .... I've run into strings of folks where both >ends of the string have a well defined birth date, but the >folks inbetween do not. --- a bit of math leads one to some >reasonable assumptions or estimates about birth dates within >that string. (I assume "Est" is the appropriate prefix for >such a date) ..... > > Guidence on this sort of thing would be useful within >the GENWEB context so we know what to submit, and what to >expect. Searching can be "date focused" within this context >once we have some agreement on context. JIM and Other Interested GENWEBbers: Recognizing the quality problems in existing secondary genealogy sources, our Silicon Valley PAF Users Group has developed a set of Guidelines for improving the quality of genealogy entered into computer data bases. We offer our efforts as a starting point for a GENWEB documentation entry standard. We also offer to coordinate development of such a guideline or standard for GENWEB. To this end I submit our initial efforts for comment. Please bear in mind that we created these guidelines for PAF users, so some of the PAF flavor is stilll present here; we expect there will be some changes to accommodate the needs of GENWEB. I've included an HTML version (below the line) of our Data Entry Guide (for Names, Dates and Places). Please move the text below the line to a file and use your Web Browser or other HTML viewer to look this material over. Please send your comments via GENWEB, and I'll attempt to make requested changes and additions. I also have our SVPAFUG guidelines on place abbreviations which I will provide in a separate E-Mail and HTML Page to GENWEB. I will add links in our SVPAFUG home page ( http://www.rahul.net/svpafug )to the GENWEB Documentation Standards Pages provided here and in the next E-Mail. I volunteer to maintain the pages on our system. Looking forward to your inputs; let's see if it'll be possible to converge to a GENWEB data entry standard. If this looks like it's working, we'll offer up our Source Documentation Guidelines for discussion. Regards, Bill Minnick _______________________________________________________________________________ SVPAFUG Data Entry Guide Addendum

Silicon Valley PAF User's Group

Documentation Guidelines Supplement for
PAF Individual and Marriage Data Entry
May 1995

Revision (HTML Format for WWW)

by Carol Harless, Alice Malquist, Bill Minnick,
Leland Osburn, Karen Tippetts, Jan Unter
Data Entry Subcommittee

© 1995 Silicon Valley PAF Users Group. All rights reserved. Reproduction premission granted only when done in conjunction with the Silicon Valley PAF Users Group PAF Documentation Guidelines, in which case this document should be attached.

FOREWORD

Our members have asked for a guide to entry of data into PAF individual and marriage data screens. We considered inputs from the PAF Users Manuals, Versions 2.2 and 2.31, Appendix G; Joan Lowery's PAF 2.2 User's Guide, Fourth Ed.; 25 pages of E-Mail responses received from Compuserve subscribers; the LDS Family History Department and the divergent opinions of our subcommittee members.

Our goal is to help people prepare PAF (and GEDCOM) data bases which can be shared with a minimum of editing. In several cases there is no best way to enter an item. We point out these situations, offer several solutions and state the pro's and con's of each approach. Finally, to produce a useful data base, we urge you to be consistent in your methods of entering data.

We believe this Guideline is a useful initial effort, but recognize that Internet readers will have many good suggestions for changes and additions to adopt these guidelines for Genealogy on the World Wide Web. Please E-Mail comments, additions, recommendations or changes to the Data Entry Subcommittee, Silicon Valley PAF Users Group, at E-Mail Address: svpafug@rahul.net.

GENERAL GUIDELINES

INDIVIDUAL and PLACE NAME ENTRY

Enter names using the case conventions below. If a name is unknown, leave the field blank. If a name field is blank, it is "assumed" unknown in PAF.

Never enter the word "unknown" as an individual or place name. A blank field is sufficient to indicate the name is unknown to the researcher. Enter the complete name, avoiding abbreviations except those from standard tables below, special codes including numbers and punctuation characters including periods.

Avoid enhancements such as "near London." Enter additional information, describe spelling variations, information conflicts in PAF Notes. Avoid entering a person's occupation in a Name field; rather, document occupation(s) in Notes via the !OCCUPATION tag.

In this guide where several methods of entry are offered, the first METHOD is generally preferred.

NAME CASE CONVENTION Enter all names in lower case letters except as follows:

Enter the first letter of a name in upper case.

Enter state and country ABBREVIATIONS in all upper case

Enter the first letter of a name and the first letter following a space in uppercase (such as in Mc or Mac, i.e. "Mac Murray").

If uppercase surnames are desired in reports, PAF can be configured to automatically place them in all uppercase-PAF can either show surnames the way you enter them or in all uppercase in Family Records Reports and Pedigree Search mode.

INDIVIDUAL DATA ENTRY

SEX: Type 'M' for male or 'F' for female. If the sex is unknown, leave the field blank.

SURNAME-GIVEN NAMES-General

An Individual Data Screen requires at least one of the four name fields to be entered. Note that even if you don't know anything about the parents of a family, it is still possible in PAF to link either or both spouses. Simply choose the spouse "not known" option in the "add family" menu.

Do not enter titles, such as "boy" , "girl", "child", "stillborn", "Miss", "Mr.", "Jr.", "Dr.", "or "farmer" in any name field. "Mrs." Is the only exception when a wife's given and maiden names are both unknown

SURNAME: (Last Name)

METHOD 1: Enter each surname as recorded in birth records. Enter individual's subsequent surname variations in Notes using the !NAME tag.

METHOD 2: Enter most recent surname spelling for all individuals in a male line. This permits more useful sorts and searches of male ancestral lines in PAF. Document Individual name changes in the Notes using the !NAME tag.

Enter MAIDEN SURNAMES for females, or leave blank if unknown . Avoid entry of present or previous husband's surname.

GIVEN NAMES: / Given 1 / Given 2 / Given 3 /

Enter first name in Given1 field; enter middle name in Given 2 field. Enter second middle name (if applicable) in Given 3 field. Leave unused fields blank.

NICKNAMES: Alias, AKA, or other assumed Names

(In the methods below, Given name fields are separated by "/" marks.) When entering nicknames into PAF, also place a NAME or AKA note tag explaining use of the name in the Notes section for the individual.

METHOD 1. Enter Nicknames in Given name field 2 or 3 with the word "or" preceding it: SMITH / John / or Jack / Frederick

METHOD 2. Enter Nicknames in PAF Notes for the individual: SMITH / John / Frederick; in Notes enter: !NAME: John was known as "Jack" most of his adult life.

NO GIVEN NAME:

SITUATION 1: For a child or children who were documented with no given name, enter do not enter anything in any given name field..

SITUATION 2: If a wife's given name and surname are both unknown, , enter the husband's surname in wife's surname field, and enter "Mrs." Followed by the husband's given name in wife's Given1 field, and husbands middle name(s) in given 2 (&3) fields.

TITLE

Never enter occupation in the PAF Title field. Instead, place occupation in Notes using the OCCUPATION tag. The PAF Title Field is only for entering special relations, formal military and royalty titles. A period after an abbreviated title is unnecessary. The Tables below show common titles and their abbreviation.

Table 1-Common Titles and Abbreviations

      Relationship             Royalty/Official
U.S. Military
    Title  Abbreviation       Title
Title          Title   Abbreviation 

    Junior       Jr           Ambassador    Governor       Admiral
Adm          
    Senior       Sr           Baron         Judge          Airman
Amn             
    II                        Baroness      King           Captain
Cpt          
    III                       Baronet       Lord           Colonel
Col          
    IV                        Congressman   Marchioness    Corporal
Cpl          
    adopted                   Count         Marquis        Ensign
Esn          
    twin                      Countess      President      General        Gen 
                              Czar          Prince         Lieutenant     Lt 
     Religious                Czarina       Princess
Major          Maj
    Title   Abreviation       Duchess       Queen
Petty Officer
    Archbishop                Duke          Representative Private        Pvt
    Bishop                    Earl          Senator        Seaman
    Cardinal                  Emperor       Sir            Sergeant       Sgt
    Deacon       Dea          Empress       Sir Baron      Warrant Officer
    Elder                     Esquire       Sir Knight
    Monsignor 
    Pastor

    Pope

    Rabbi

    Reverend     Rev

    Vicar

DATES ENTRY

Estimate birth, marriage, death dates if not documented. Use the following entries to precede estimated dates: "About" or "Abt", "Before" or "Bef", "After" or "Aft". Enter a range of dates as follows: "1810/1820". Avoid entry of the words "See Notes" in date field.

Estimating Dates

Birth dates can be calculated by using known birth dates of other family members. Precede estimated year with "Abt".

Estimate the father's birth year by:

Subtracting 26 years from birth year of first child

Subtracting four years from birth year of wife, or

Subtracting 25 years from marriage year.

Estimate the mother's birth year by:

Subtracting 22 years from birth year of first child

Adding four years to birth year of husband or

Subtracting 21 years from marriage year.

Estimate birth year of other children by adding two years to birth year of previous child.

If birth date of child is unknown add 25 years to birth year of husband or 22 years to birth year of wife.

PLACES-GENERAL

METHOD 1: Enter the place name used at the date of the event. Document subsequent place name changes in the notes using the !PLACE tag. Advantage: this method works consistently no mater when the research is done.

METHOD 2: Enter current Place names. Document old place names in Notes using a PLACE tag. Enter placename used when the event occurred. Advantage: Place sorted lists work much better when one name is used to identify a specific place.

Leave a field blank if an item such as county is unknown. Capitalize only first letter of place names. Avoid entering "unknown" in any field. Avoid entering numbers or special codes in place names.

If birth place is unknown, enter earliest location known to be the individual's residence. You may choose to enter 'of'' in front of city name in Level 1, name of county in Level 2, name of state or Providence in Level 3; enter country name other that USA in Level 4. Disadvantage: Place names prefixed with "of" do not sort well because all names with "of" are listed under the "O"s

PLACE LEVEL ASSIGNMENT

Above all, be consistent when assigning place divisions to place Levels 1-4. This helps with sorting and searching for place names in reports or merging of other data bases later on.

The best process to use when assigning places is to think backward-first assign the largest geographical area name to Level 4, next largest to Level 3, and so on to Level 1. For places in the U.S.A., the established convention is to have Level 4 (country) blank; State or State Postal abbreviation in Level 3; County in Level 2 (avoid "Co" after county name); and Town in Level 1. Add Twp after the name in Level 1 to indicate a township.

Place level 4: Country

Spell out the Country, or use abbreviation from tables below. Do not enter USA or United States, since a blank country field implies USA. Avoid periods following abbreviations.

Place level 3: State, Province or European County

SITUATION 1: Enter State name or abbreviation; avoid periods in abbreviations. Use PAF HELP (ALT-H) or choose PRINT option in PAF Main Menu to list State Abbreviations.

SITUATION 2: Enter a non-US Country when only three place names exist (leave Level 4 blank).

Place level 2: County

SITUATION 1: Enter the County name without the suffix "Co."

SITUATION 2: Enter European Parish or Districts.

Place level 1: Town or Township (Twp)

SITUATION 1: Enter the Town name, or a Township name followed by "Twp" like "Sawyer Twp."

SITUATION 2: Enter non-Parish European town, Scandinavian farm name, etc.

CEMETERY NAME

METHOD 1: Document the cemetery name in Notes using the CEMETERY tag.

METHOD 2: Enter the cemetery name in Level 4 under Burial Place (abbrev as "cem"). Disadvantage: PAF Place Sorted Lists do not give desired place order.

METHOD 3: Enter the cemetery name in Level 1 for Burial Place; and move town to Level 2, county to Level 3 and state to Level 4 in Burial Place. Disadvantage: Place Sorted Lists do not give desired place order.

CREMATION

Enter date when and place where person was cremated in the Burial fields. Use the CREMATION tag in Notes to document relevant details of this event and the location of remains (scattered or a mausoleum, etc.)

HOSPITAL NAME
(facility where individual was born or died.)

METHOD 1: Document the hospital name in Notes using the HOSPITAL tag..

METHOD 2: Enter the hospital name in Level 4 under Birth or Death Place. Disadvantage: Place Sorted Lists do not give desired place order.

METHOD 3: Enter the hospital name in Level 1 of Birth or Death Place; and move town to Level 2, county to Level 3 and state to Level 4 in Birth or Death Place. Disadvantage: Place Sorted Lists do not give desired place order.

Above all, when entering place information use one method consistently.

MARRIAGE INFORMATION

ENTER MULTIPLE MARRIAGES for each spouse in the date order that they occurred. Avoid typing "Unknown" in any field. For each marriage, state "Y" or "N" for divorce.

If marriage date is unknown, year can be calculated by subtracting one year from birth year of first child. Enter "Abt" before the estimated marriage year.

If there were no children by this marriage, add the following Note to the Spouse's PAF Notes: "!CHILDREN: No Issue."

REFERENCES

Acronyms, Initialisms and Abbreviations Dictionary, 1989 (3 Vol.), Gale Research Co, Detroit, MI

Genealogy Research Directory, National and International, 1992, Keith Johnson/Malcomb Sainty

PAF Documentation Guidelines, 1993, Silicon Valley PAF Users Group, San Jose CA

End of Document E-Mail Address: svpafug@rahul.net Friday, May 5, 1995 1:41:16 PM GenWeb Item From: Matthew Helm,helm@alexia.lis.uiuc.edu,Internet Subject: Re: ROOTSBOOK web server To: GenWeb Mickey, I just tried your ROOTSBOOK project. The system seemed very responsive and the access times were at a minimum. One thing that you might want to think about adding is a source field for the data. Given the various forms that the GEDCOM data comes to you, I don't know how feasible that is. However, it is useful in putting the information that the user is seeing into some sort of context. Thanks. Matthew Helm helm@alexia.lis.uiuc.edu Genealogy Toolbox - http://ux1.cso.uiuc.edu/~al-helm/genealogy.html >The ROOTSBOOK web server is temporarly! on line at > > http://mlane2.inhouse.compuserve.com:8000/GenWeb.htm > >Please address questions and comments to the GenWeb list. > >Mickey. > > Friday, May 5, 1995 2:19:47 PM GenWeb Item From: Bill Minnick,svpafug@rahul.net,Internet Subject: Re: ROOTSBOOK web server To: GenWeb >The ROOTSBOOK web server is temporarly! on line at > > http://mlane2.inhouse.compuserve.com:8000/GenWeb.htm > Mickey: Comments on ROOTSBOOK: [I'm using NCSA Mosaic (b4 version)] 1. Your BOOK - - ENTRY links in the right colume of a surname index page all produce and error message because they arent producing a complete URL; they generate a URL that looks like: GenWeb.exe?SPEED1:333 The rest of the URL (to the left) is missing. Am I doing something wrong? (I hand-entered the 'complete' URL and accessed person 333 in Book SPEED1 OK, but this is darned inconvenient) 2. The person I randomly looked up (SPEED1:333) was born in 1980. This person and her parents, etc are all living persons. If you don't have written permission to put this info for these living persons on the Web, you are advised to eliminate living person information from Web data bases. 3. I concur with Mat Helm's statement that you need a means of documenting source citation to achieve any credibility for the information presented. 4. Is there a way to add a photo to the individual file in ROOTSBOOK? Regards, Bill Minnick Friday, May 5, 1995 3:04:45 PM GenWeb Item From: Bill Minnick,svpafug@rahul.net,Internet Subject: Re: Whither UNIX LifeLines? To: GenWeb Tom Wetmore, ttw@beltway.att.com, 5/2/95 stated: >. . . . All I have to do is turn on a few options and add a couple new >builtins to the programming language, and it's there. But you can also >imagine why I have been a little leary of giving LL programs such power. >Power to do good equals the power to destroy! However, it's clear that >GenWeb projects will need extra power...... > >Responses, comments, disagreements, rejoinders, suggestions, flames, >criticisms, rebuttals welcome. > TOM: Go for it! Can you put in a transaction history option so we can go back n steps if we inadvertantly tell the new LifeLines to destroy a data base? Regards, Bill Minnick Friday, May 5, 1995 3:18:54 PM GenWeb Item From: Scott McGee,smcgee@microware.com,Internet Subject: Re: LifeLines and Programmable GEDCOM Database Updates To: GenWeb Now, see what I meant about Tom! Not only does he have plenty of ideas up his sleeves, but he does this just to tease us! I don't even have 3.0.2 and he has me salivating about 3.0.3! Well, like I said, as long as he DOES make new releases availible from time to time, I'm willing to let him keep doing it to me. Scott |- I never actually SAID that! -|- email: smcgee@microware.com -| |------------ http://www.cc.utah.edu/~sam8644/homepage.html ------------| Programming in assembly language is a lot like digging a post hole with a teaspoon. Of course, you DO have complete control over every bit of dirt! Friday, May 5, 1995 3:18:55 PM GenWeb Item From: Mickey Lane,MLANE@csi.compuserve.com,Internet Subject: Re: ROOTSBOOK web server To: GenWeb Matthew Helm writes: >One thing that you might want to think >about adding is a source field for the data. Given the various forms that >the GEDCOM data comes to you, I don't know how feasible that is. However, >it is useful in putting the information that the user is seeing into some >sort of context. In theory, each entry page is supposed to have a "" indicator immediatly following the "Entry N" label at the top left of each page. All but one or two books are missing this indicator due to a programming error that has since been fixed. It's my intention to have the "" indicator be a hypertext link to a page produced by the software that displays as much information as possible about the book. In my own work, this page was hand written and inserted at the beginning of each book. I never implemented the software to do anything like this although I've had lots of ideas over the years. Given the GEDCOM files I've used, there's not much available. Some of them contain the name and address of the author which is probably the most valuable part. The computer can calculate all sorts of basically useless information like number of entries, min, max and mean date, primary locations and so on but since people don't think in terms of books, there's not much point to it. Certainly something to think about.... Mickey. Friday, May 5, 1995 4:23:22 PM GenWeb Item From: Mickey Lane,MLANE@csi.compuserve.com,Internet Subject: Re: ROOTSBOOK web server To: GenWeb Bill Minnick writes: > Comments on ROOTSBOOK: [I'm using NCSA Mosaic (b4 version)] >1. Your BOOK - - ENTRY links in the right colume of a surname index page >all produce and error message because they arent producing a complete URL; >they generate a URL that looks like: GenWeb.exe?SPEED1:333 >The rest of the URL (to the left) is missing. Am I doing something wrong? >(I hand-entered the 'complete' URL and accessed person 333 in Book SPEED1 >OK, but this is darned inconvenient) Well, no, it's not OK :-) I'm no expert on URLs but I think the problem is the difference between relative references and absolute references. The code for the html engine can produce either but the character count doubles if I use absolute references in every case. (Character count times 2 = rotten performance.) It seems to work fine with NetScape. Can you try that? (You're the first person to voice this particular complaint.) >2. The person I randomly looked up (SPEED1:333) was born in 1980. This >person and her parents, etc are all living persons. If you don't have >written permission to put this info for these living persons on the Web, you >are advised to eliminate living person information from Web data bases. Good point. The policy I've used is to present the info in GEDCOM files (processed but not altered) that people have put on publically accessable servers. I presume that the person who put the information there intends to have this information available. As I state in the disclaimer, I'll 'cheerfully' remove anything. :-) I'm willing to take direction from the Genweb community on this. My only concern is the amount of work involved - I have limited time to 'proof' every submission (or in this case, file copied.) >3. I concur with Mat Helm's statement that you need a means of documenting >source citation to achieve any credibility for the information presented. Agreed. See recent note on the subject. >4. Is there a way to add a photo to the individual file in ROOTSBOOK? Yes. It opens a can of worms, though. As I stated in my "what I'd like to do with ROOTSBOOK" thing, we have a problem when we modify the GEDCOM file. All the stuff currently on the server came from GEDCOM files and I haven't made any modifications to them. (One exception - VARNEY:19. Author of db knows. It's the only linked entry currently on line.) If someone submits a ROOTSBOOK database instead of a GEDCOM file, all these problems go away and we can do photos, links, sounds and you name it. Regards, Mickey. Friday, May 5, 1995 5:29:05 PM GenWeb Item From: Anders Andersson,andersa@Mizar.DoCS.UU.SE,Internet Subject: Re: ROOTSBOOK web server To: GenWeb Bill Minnick writes in response to Mickey Lane: >1. Your BOOK - - ENTRY links in the right colume of a surname index page >all produce and error message because they arent producing a complete URL; >they generate a URL that looks like: GenWeb.exe?SPEED1:333 >The rest of the URL (to the left) is missing. Am I doing something wrong? Oops! Mickey asked me to check his URLs earlier, but I didn't spot this problem then. Having partial URLs is fine, as the browser is required to compose full URLs from existing defaults according to given rules. The problem here is that the partial URL contains a colon (:), which probably leads to "GenWeb.exe?SPEED1" being interpreted as the access scheme (instead of "http"). For this reason, colons aren't allowed in the local part of a URL. If a colon would be the natural delimiter in the ROOTSBOOK context, it can still be represented in a valid URL by using the equivalent character code in base 16 preceded by a percent sign (%), resulting in a partial URL of "GenWeb.exe?SPEED1%3A333". I just checked accessing Mickey's server using this syntax, and it works already (this may indicate that ROOTSBOOK uses ASCII internally, which hardly comes as a surprise anyway). Thus, Mickey only needs to modify his program to output "%3A" instead of ":" in these URLs. >(I hand-entered the 'complete' URL and accessed person 333 in Book SPEED1 >OK, but this is darned inconvenient) This worked because your browser only looked for the first colon when parsing the URL, transmitting the final part of it untouched to the server. Still, colons are explicitely disallowed wherever they don't indicate the access scheme, password or port number, and no software is required to understand or accept formally invalid URLs. Sticking to valid characters only is the best way to avoid problems. -- Anders Andersson, Dept. of Computer Systems, Uppsala University Paper Mail: Box 325, S-751 05 UPPSALA, Sweden Phone: +46 18 183170 EMail: andersa@DoCS.UU.SE Friday, May 5, 1995 6:34:08 PM GenWeb Item From: Mickey Lane,MLANE@csi.compuserve.com,Internet Subject: Re: ROOTSBOOK web server To: GenWeb Anders Andersson writes: >Oops! Mickey asked me to check his URLs earlier, but I didn't spot >this problem then. Having partial URLs is fine, as the browser is >required to compose full URLs from existing defaults according to >given rules. MY MISTAKE! I changed the server this afternoon to cut down on the character volume. When you checked it, it was producing absolute references, not relative. I tested it with NetScape, it seemed to work. >The problem here is that the partial URL contains a colon (:), which >probably leads to "GenWeb.exe?SPEED1" being interpreted as the access >scheme (instead of "http"). For this reason, colons aren't allowed >in the local part of a URL. Well, that's easy to fix. >If a colon would be the natural delimiter in the ROOTSBOOK context, >it can still be represented in a valid URL by using the equivalent >character code in base 16 preceded by a percent sign (%), resulting >in a partial URL of "GenWeb.exe?SPEED1%3A333". Actually, the natural syntax for ROOTSBOOK is NNN but the "<...>" than pose more of a problem so I chose the colon. >Thus, Mickey only needs to >modify his program to output "%3A" instead of ":" in these URLs. Will do on Monday! Thanks for the advice. Mickey. Saturday, May 6, 1995 5:51:35 AM GenWeb Item From: Morris Plummer,mplummer@iquest.net,Internet Subject: Roots Book To: GenWeb I have just finished looking over your new addition and to me it looks fine. I am not a programmer just barely computer literate. But, I am a genealogist, and have been for some time. I did notice I couldn't add it to my bookmark list on netscape. Will this change. I did find the Moon family there and that is also one of my families. I have a great deal of info on them and could contribute. Who done the research and could you put me in touch with them ? Keep up the good work and thanks. Morris Plummer e-mail address mplummer@iquest.net Morris A. Plummer Phone (317)865-9686 mplummer@iquest.net Monday, May 8, 1995 6:18:58 PM GenWeb Item From: Bill Minnick,svpafug@rahul.net,Internet Subject: GENWEB Data Entry Standards To: GenWeb TO: all GENWEBbers (including Lurkers) FROM: Bill Minnick Silicon Valley PAF Users Group SUBJECT: Genealogy Data Entry Standards for GENWEB We need your help in the form of feedback on the proposed Data Entry standards posted at our SVPAFUG Web site - URL: http://www.rahul.net/svpafug From our home page, select the "GENWEB Project" link, and then please checkout both the "GENWEB Standard for PAF Individual & Marriage Data Entry" link and the "GENWEB Standard for Place Name Abreviations" link. Please look over these proposed standards and send me your suggestions for changes. I would prefer that you grab the HTML, enter your recommended changes, then email the segment back to me. I'll include all reasonable material as updates to the pages presently posted. Note that I have not attempted to revise the "PAF Individual & Marriage" page to be general for all Genealogy Programs. I felt we'd be better off leaving the PAF materrial as is, and writing standards specific to other genealogy programs, or like groups of programs. So if anyone wants to develop a "Individual & Marriage Data Entry" standard for "their" Genealogy program, we'll be glad to post it at our SVPAFUG site. Feel free to take a copy of our HTML and edit it for your favorite Genealogy program. Bear in mind that the purpose of these standards is to guide thousands of people of limited experience so they can produce Genealogy data bases with some reasonable consistency. If anyone on GENWEB can't access these standards pages via the Web, let me know and I'll try to e-mail you current copies. Regards, Bill Minnick PS: The present material has the SVPAFUG copyright which basically says any provate party is welcome to the information, but we don't want the material to be copied and used in commercial (for-profit) ventures. Tuesday, May 9, 1995 2:26:41 PM GenWeb Item From: Bill Minnick,svpafug@rahul.net,Internet Subject: Re: GENWEB Data Entry Standards To: GenWeb Pat Place wrote: >I realise that you are PAF oriented, but it would be nice if your >standard could accept GEDCOM. I use LifeLines and, although there >is a PAF export capability it is not perfect, particularly with >respect to place names. Equally, so far as I can see from the >GEDCOM standard, multiple NAME entries are fine which seems like >a better way of representing other names or nicknames rather than >cluttering up the NAME field. PAT: Before I launch into an answer, these are good questions; perhaps many people can learn from the answers below. For at least the next couple of years, there are 200,000 people (mostly Americans) out there who are entering Genealogy via the PAF program. Our proposed Data Entry Standard at URL: http:/www.rahul.net/svpafug/entstd1.html is aimed at these people. Using this standard, PAF users can produce genealogy of reasonable quality to place on the WEB. PAF has many limitations that force the need for many rules that are unique to PAF's idiosyncrasies. We do not intend this PAF guideline to unnecessarily limit people who are using other genealogy programs. At best, the proposed PAF data entry standard can be useful as a template for writing the standards for other genealogy data entry programs. So, since you are using LifeLines, perhaps you would be willing to propose/write a standard for Lifelines data entry. Because LifeLines is so powerful compared to PAF, the standard will probably be closer to an ultimate GENWEB final standard than the current proposed PAF standard. We offer the PAF standard, because we have 5 years into it, and it is a start. Also bear in mind that LifeLines accepts GEDCOM files without a hitch from PAF genealogies prepared according to the proposed standard. The Richard Austin Book with a link at URL: http://www.rahul.net:80/svpafug was produced per the proposed PAF standard, and is running under LifeLines on the WEB right now. (It loaded into LifeLines without a hitch the first time.) > >For dates, why use "Before" or "Bef", ... rather than the standard >"BEF"? This is a good example of a PAF idiosyncrasy. During the data entry process, PAF converts (immediately) any of the following to "Bef": be, bef, befo, before, and any combination of upper case letters in these four variations listed. The same is true of "Aft". >The restrictions on data format that you have would make it hard for >me to make a copy of my data available. PAT: Again, if you are not using PAF, you will need to devise a different set of data entry requirements unique to your favorite program. We'll post it if you write it! By the way, I look to the day that these old, 8088-targeted programs are superceded, so we can take full advantage of the Web for composing and correcting genealogy data bases. But I am forced, reluctantly to start with what we have. (If Tom Wetmore is listening, I'd like to see LifeLines with all the new features he has alluded to this past month, PLUS a graphical user interface running on UNIX and Windows platforms. I'd be glad to put a lot of effort into a standard for data entry for such a powerhouse program.) Anyway, thanks for the questions. They have given me an opportunity to clarify some aspects of the proposed PAF data entry standard for GENWEB. Regards, Bill Minnick Tuesday, May 9, 1995 11:40:26 PM GenWeb Item From: Gary Hoffman,ghoffman@ucsd.edu,Internet Subject: Indexing and then linking To: GenWeb We have had some discussions here about linking records in one GenWeb database to another. This discussion will continue in conjunction with topics as the URN and portable documents. However, before pages can be linked, they must be located. Locating related pages can be facilitated by a unified indexing format. I would like to renew a call for a unified index format. Some have suggested that we piggyback on the Domain Name Service hostname lookup service. However, I continue to advocate a separate indexing system that relies on HTML as the linking syntax. In such a system, each GenWeb site has an internal index, either precomputed or generated on the fly. That is, every record of a person at that site has an entry on an index page. I suggest that there be an index page for each surname. Others have suggested that surname Soundex indexes be built. I think more than one system could be used. In any case, a single page at each site should serve as the primary index entry point, perhaps with links to each surname page. That page should be named 'gendex.html.' Likewise, a central GenWeb index site will be established that can serve as the index to these gendex pages. This site will be the Yahoo of the GenWeb and will allow searching perhaps by surname. The search at the gendex.genweb.org will yield a list of server sites and their gendex pages. Automated searching processes at user sites or GenWeb archive sites would query the gendex.genweb.org just once as they begin a search so that they would know where each registered GenWeb site was located. But they would make their own contacts directly, not through the gendex site. There will be no centralized name searching. The advantage of this system is that it allows manual as well as automated searching and it does not burden the DNS system with superfluous information. There are of course disadvantages, including the need to set up gendex updating mechanisms which may replicate functionality of the DNS system. I invite further comments on this topic. *************************************************************************** *Gary B. Hoffman, Computer/Language Lab Director e-mail: ghoffman@ucsd.edu* *Graduate School of International Relations and Pacific Studies (IR/PS)* *University of California, San Diego (UCSD) voice: (619) 534-7733* *9500 Gilman Dr., La Jolla, CA 92093-0519 USA fax: (619) 534-5727* *************************************************************************** Tuesday, May 9, 1995 11:43:30 PM GenWeb Item From: Gary Hoffman,ghoffman@UCSD.EDU,Internet Subject: Document References To: GenWeb Out of my attendance at the NGS conference came the realization that referencing genealogical source documentation may be as important as reporting the results of research. The lack of source references has lead (at least in part) to the downfall of such large databases as the LDS's Ancestral File. At the NGS, I had a chance to see some of the new personal genealogy database programs that handle references much better than does PAF. In an ideal system, a source need only be recorded once within the system and then referenced as needed within the system. Of course, if we are building a global system, then we may need to build a global reference library. Here is what I mean: a genealogical record will contain information about an event, perhaps a birth, which was recorded in a parish record book. The genealogical record could contain a full bibliographic reference to the parish record book (perhaps using the SVPUG's documentation guidelines) or it could contain only the link to a separate documentation record. The latter begins to make sense when more than one person's genealogy page references that source. That is, just make a bibliographic entry once and cite it as often as needed. And we can put all such references on a given GenWeb server in a central place, say perhaps a directory called 'gendocs.' Well, that same source could be cited by GenWeb pages on several servers. Of course, there would be no need to replicate the entire citation, as long as we had a link to it anywhere on the network. But where is that citation? I suggest two possiblities. One choice is to use the computerized facilities of the Library of Congress, the Online Computerized Library Catalog (OCLC), or the LDS Family History Center Catalog, all of which have cataloged an enourmous number of published works. I just don't know how to cite a work within their databases. The second possibility is that we users all begin to create a distributed database of genealogical source materials that will shadow the GenWeb. We would have to standardize our references and allow others to link to our referenced pages. This could be an enormous effort that has the potential of taking the fun out of genealogy. I hope that some combination of these two choices will develop. That is, we could cite a catalog entry that was already extant in a national database, but if not, we can add it to a backup system of lesser-known works. We may hasten the use of the Uniform Resource Number which is a unique number applied to every document in existance. This would allow a reference citation to be applied even when the exact location of the reference is not known. I invite comments on this theme. I don't believe we should push the GenWeb very far ahead of its sources. *************************************************************************** *Gary B. Hoffman, Computer/Language Lab Director e-mail: ghoffman@ucsd.edu* *Graduate School of International Relations and Pacific Studies (IR/PS)* *University of California, San Diego (UCSD) voice: (619) 534-7733* *9500 Gilman Dr., La Jolla, CA 92093-0519 USA fax: (619) 534-5727* *************************************************************************** Tuesday, May 9, 1995 11:44:20 PM GenWeb Item From: Gary Hoffman,ghoffman@ucsd.edu,Internet Subject: Ownership and updating To: GenWeb As I spoke at the NGS about GenWeb, I was often asked what would keep this system from foundering as has the LDS Church's Ancestral File. My answer was that we would allow the contributor to "own" their contribution and to be responsible both for the validity of the data, and for updating it in face of new information. Where the site administrator contributes his/her own genealogy, there is no updating problem. However, where third party contributors send data to central sites for publishing on the GenWeb, then we need to create a mechanism for that contributor to remain in contact with their data. At present, we have been talking about converting GEDCOM data in batches. In the future, we may need to discuss how users can contribute information on a record by record basis and how they can update individual records. Using the e-mail system is one choice. Another is the use of an HTML form or template that would include a password for security. I suppose we would even need to establish a formal relationship between host site admin and contributor before the GenWeb data were put on line, confirmed by written (or email) contract. So I see more features that Tom Wetmore will need to add to LifeLines: ability to maintain multiple GEDCOM submissions, ability to update individual records remotely via password-controlled access, and a contributor's name and email address attached to each record. Comments are welcome. *************************************************************************** *Gary B. Hoffman, Computer/Language Lab Director e-mail: ghoffman@ucsd.edu* *Graduate School of International Relations and Pacific Studies (IR/PS)* *University of California, San Diego (UCSD) voice: (619) 534-7733* *9500 Gilman Dr., La Jolla, CA 92093-0519 USA fax: (619) 534-5727* *************************************************************************** Tuesday, May 9, 1995 11:57:20 PM GenWeb Item From: Gary Hoffman,ghoffman@ucsd.edu,Internet Subject: NGS Conference Report To: GenWeb Dear GenWebbers: I promised a report following last week's National Genealogical Society's Conference in the States here in San Diego. I was on the schedule to give a presentation on GenWeb the first day of the conference which was Wednesday. With a telephone link back to UCSD, I was able to mount an introduction to the Internet using Netscape as my presentation program driving an overhead projection panel from my PowerBook 540c. (Actually, the PPP connection was a bit flaky, so I resorted to a backup copy of my "slides" on my hard drive until near the end, when I went online live.) Attendance exceeded the room's seating capacity and people sat on the floor in the aisles to see this demo. The conference chairman was so impressed with this response that he asked me to make an encore presentation and cleared a larger room the next day. I had again as many in attendance at the second event. (I was the only lecturer to be asked to repeat.) On Friday, I was scheduled to speak on "Surfing the Internet" which topic I modified to cover some of the experimental work being done by others inspired by the GenWeb idea. What I found, however, was that there were many new people in the audience, so I had to go back over the Internet basics before linking to various GenWeb databases. The connection was a little better that day and I demonstrated some good GenWeb pages. Thanks to all who have been putting good stuff together. I also assisted Brian Mavrogeorge and George Archer with their demonstations of other genealogy resources on the Internet. Brian had both prepared slides and a live on-line presentation. George showed how to use WWW without a GUI browser or even an Internet account. (You'll have to ask him how to do it.) Prodigy had a booth in the exhibit hall as did AOL. I got a chance to see Prodigy's WWW browser, but AOL did not have a live demo. Also, Silicon Valley PAF User's Group had a booth and so did Everton, which is getting its own WWW server very soon now. The conference was especially good for the chance to "network" face to face with others who are working on related projects. I was approached by a representative of a major online service who offered to host major components of the GenWeb service. I hope to finalize these arrangements and make an announcement very soon. Please stay tuned. As a result of a series of discussions, I have reformulated and revised some aspects of the GenWeb proposal. For the sake of threading the discussions, I will introduce them in separate messages and invite discussion on each one. I believe in "GenWeb 2000": that we can, in the next five years, put all previously computerized names of deceased persons on the Internet using the GenWeb format. My thanks to all who are helping to build the GenWeb. Gary *************************************************************************** *Gary B. Hoffman, Computer/Language Lab Director e-mail: ghoffman@ucsd.edu* *Graduate School of International Relations and Pacific Studies (IR/PS)* *University of California, San Diego (UCSD) voice: (619) 534-7733* *9500 Gilman Dr., La Jolla, CA 92093-0519 USA fax: (619) 534-5727* *************************************************************************** Tuesday, May 9, 1995 11:57:46 PM GenWeb Item From: Gary Hoffman,ghoffman@UCSD.EDU,Internet Subject: NGS Conference Report To: GenWeb Dear GenWebbers: I promised a report following last week's National Genealogical Society's Conference in the States here in San Diego. I was on the schedule to give a presentation on GenWeb the first day of the conference which was Wednesday. With a telephone link back to UCSD, I was able to mount an introduction to the Internet using Netscape as my presentation program driving an overhead projection panel from my PowerBook 540c. (Actually, the PPP connection was a bit flaky, so I resorted to a backup copy of my "slides" on my hard drive until near the end, when I went online live.) Attendance exceeded the room's seating capacity and people sat on the floor in the aisles to see this demo. The conference chairman was so impressed with this response that he asked me to make an encore presentation and cleared a larger room the next day. I had again as many in attendance at the second event. (I was the only lecturer to be asked to repeat.) On Friday, I was scheduled to speak on "Surfing the Internet" which topic I modified to cover some of the experimental work being done by others inspired by the GenWeb idea. What I found, however, was that there were many new people in the audience, so I had to go back over the Internet basics before linking to various GenWeb databases. The connection was a little better that day and I demonstrated some good GenWeb pages. Thanks to all who have been putting good stuff together. I also assisted Brian Mavrogeorge and George Archer with their demonstations of other genealogy resources on the Internet. Brian had both prepared slides and a live on-line presentation. George showed how to use WWW without a GUI browser or even an Internet account. (You'll have to ask him how to do it.) Prodigy had a booth in the exhibit hall as did AOL. I got a chance to see Prodigy's WWW browser, but AOL did not have a live demo. Also, Silicon Valley PAF User's Group had a booth and so did Everton, which is getting its own WWW server very soon now. The conference was especially good for the chance to "network" face to face with others who are working on related projects. I was approached by a representative of a major online service who offered to host major components of the GenWeb service. I hope to finalize these arrangements and make an announcement very soon. Please stay tuned. As a result of a series of discussions, I have reformulated and revised some aspects of the GenWeb proposal. For the sake of threading the discussions, I will introduce them in separate messages and invite discussion on each one. I believe in "GenWeb 2000": that we can, in the next five years, put all previously computerized names of deceased persons on the Internet using the GenWeb format. My thanks to all who are helping to build the GenWeb. Gary *************************************************************************** *Gary B. Hoffman, Computer/Language Lab Director e-mail: ghoffman@ucsd.edu* *Graduate School of International Relations and Pacific Studies (IR/PS)* *University of California, San Diego (UCSD) voice: (619) 534-7733* *9500 Gilman Dr., La Jolla, CA 92093-0519 USA fax: (619) 534-5727* *************************************************************************** Wednesday, May 10, 1995 3:34:42 AM GenWeb Item From: Gene Stark,gene@starkhome.cs.sunysb.edu,Internet Subject: Indexing and then linking To: GenWeb >I would like to renew a call for a unified index format. Some have Yes, I think we cannot make much progress until we agree on such a format, and people with GenWeb data create these indexes. >suggested that we piggyback on the Domain Name Service hostname lookup >service. However, I continue to advocate a separate indexing system that >relies on HTML as the linking syntax. I thought about this a little bit, and I tend to agree that whereas DNS definitely has its uses in locating hosts with GenWeb data, and probably also for obtaining URL "entry points" for various databases on those hosts, it would probably be best for the moment not to overload DNS with the task of indexing individual records within databases. An HTML file would serve the present purposes just fine, I think. As the index files for some databases can reach several MB, I think the standard would have to permit a hierarchical index format. Information on each individual should of course include names, but probably also birth/death dates and places. What else should be in there? If too much information is in the indexes, aren't we really talking about a standardized GenWeb data presentation format, rather than an indexing format? In the interests of flexibility, I think it would be good to take advantage of the capabilities of DNS to avoid having to assign a standard name such as "gendex.html" to the index files. We can also avoid having to specify a standard location for it, which may be inconvenient or incompatible with administrative policies on some servers. Rather, standard TXT records in the subdomain "databasename.version0.genweb.org" would specify the name and URL of the index file for the database "databasename". This would also permit database maintainers to retain their Version 0 index files when "Version 1" GenWeb decides on a different index file format. - Gene Stark Wednesday, May 10, 1995 6:54:48 AM GenWeb Item From: Scott McGee,smcgee@microware.com,Internet Subject: Re: Ownership and updating To: GenWeb With the advent of some of the new 3.0.3 features Tom has talked about in LifeLines, and a release of gengine with those features, I don't see any trouble doing all that Gary suggests will be needed with a little clever programming of cgi scripts and such. In fact, given gengine, I think a www browser and a little clever cgi scripting would make a perfect, multi-platform User Interface for LifeLines. I suspect that a proper interface form could make gengine look to a user very much like PAF (in terms of usage, not necessarily in actual looks) or most any other genealogy program. I have given some minor thought myself to the prospects of updating the database through a genweb interface. While I have not attempted to actually code a solution, I feel there is a LOT we can do right now given just the current LifeLines 3.0.1. The major dificulties I see have to do with interactive functions where it is difficult beforehand to determine the needed input. Gengine would solve that. One problem I see in updating a record via genweb is the actual transfer of data. For instance, do we have LL generate a gedcom for the given person, transmit that to the web browser where the user edits it and submits it back (how to return it is an interesting question too), or do we provide a form with the fields filled in with current data and then let the user modify or add to any field and submit the form for processing. I guess the latter method is much like data entry/modification on other genealogy programs (I have never used any others) and would be good for the average genweb user, but I don't know if we want to limit things that much. If the form method were used, I would think that we could easily add a field that lets the submitter add an optionial password. If the password is correct, we could assume the data is valid and enter it right into the database. If not, or if no password is sent, the data should be processed and sent to the owners mailbox or whatever for checking. In other words, one form does all, but had different results depending on the validity of the password field. This would let the owner update the database live, and also test the usability of the user data submission form. (You are a lot more likely to spot inadequacies in the submission form if you have to use it yourself!) Scott If at first, you don't succeed, | smcgee@microware.com (Scott McGee) go fry a hen. After all, fried | ----------------------------------------- chicken beats failure any time. | I was paid $5.00 to express these views! -------------> http://www.cc.utah.edu/~sam8644/homepage.html <------------- Wednesday, May 10, 1995 9:48:00 AM GenWeb Item From: Bill Minnick,svpafug@rahul.net,Internet Subject: Re: Ownership and updating To: GenWeb >With the advent of some of the new 3.0.3 features Tom has talked about in >LifeLines, and a release of gengine with those features, I don't see any >trouble doing all that Gary suggests will be needed with a little clever >programming of cgi scripts and such. > > . . . . > >One problem I see in updating a record via genweb is the actual transfer of >data. For instance, do we have LL generate a gedcom for the given person, >transmit that to the web browser where the user edits it and submits it back >(how to return it is an interesting question too), or do we provide a form >with the fields filled in with current data and then let the user modify or >add to any field and submit the form for processing. I guess the latter method >is much like data entry/modification on other genealogy programs (I have never >used any others) and would be good for the average genweb user, but I don't >know if we want to limit things that much. SCOTT: I really like your thinking here. The password conncept is excellent, especially for large family groups where people around the world will be working in organized teams together on genealogy data bases (i.e., our Austin AFAOA Group). I do have a suggestion about the no-password situation. I'd like to avoid good information piling up in mail boxes, waiting for some overloaded person like me to act. How about building in a way to put the updated page "below" the current, "official" page, and placing a link(s) in the official page to the updated submission(s). This would let the public look at the material while its disposition is under consideration by the "decision maker(s)". So if it takes six months to research the new material, the public is not deprived of the potential value of the information. I look at this concept as adding a "depth" dimension to individual pages to accommodate cases where new information has come to light. This "dimension" really represents the on-going research situations - and conflicts - which I'd like the public to be able to participate in effectively via the WEB. I believe the added disk storage required for such a feature will be well worth it. Regards, Bill Minnick