From list-relay@UCSD.EDU Thu Nov 2 02:56:35 1995 Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id CAA15039 for ; Thu, 2 Nov 1995 02:56:34 -0800 Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.2.45]) by UCSD.EDU (8.6.12/8.6.9) with ESMTP id CAA11247 for ; Thu, 2 Nov 1995 02:48:55 -0800 Received: from immd8.informatik.uni-erlangen.de (root@faui80.informatik.uni-erlangen.de [131.188.38.1]) by uni-erlangen.de with SMTP id KAA17370 (8.6.12/7.4f-FAU); for ; Thu, 2 Nov 1995 10:58:31 +0100 Received: from faui8c by immd8.informatik.uni-erlangen.de; id AA09638 (5.x/7.3w-FAU); Thu, 2 Nov 1995 10:58:23 +0100 From: Herbert Stoyan Message-Id: <9511020958.AA09638@immd8.informatik.uni-erlangen.de> Date: Thu, 2 Nov 1995 10:58:21 +0100 To: genweb@UCSD.EDU Subject: interdatabse linking X-Sun-Charset: US-ASCII Scott doubts that the urls like http://www8.informatik.uni-erlangen.de/cgi-bin/ll/BASE=stoyan/LANG=engl/F=Herbert/N=Stoyan/?Lookup are not unique. They are, because there is an additional entry (an there could be even more): /Q=.... you may add: birth dates or death dates: /Q=B:5.8.1943 For the William Ward, born at 5th of October 1833 use: http://.../F=William/N=Ward/Q=B:5.10.1833 As you may note there is a problem: how to write data. A notation like 10/5/1833 is not fine because of the slashes. A french notation 5-10-1833, a german notation 5.10.1833, a scientific notation 1833-10-5 or one as I proposed some weeks ago would work. From list-relay@UCSD.EDU Thu Nov 2 05:50:37 1995 Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id FAA15179 for ; Thu, 2 Nov 1995 05:50:37 -0800 Received: from Mizar.DoCS.UU.SE (Mizar.DoCS.UU.SE [130.238.11.21]) by UCSD.EDU (8.6.12/8.6.9) with SMTP id FAA13357 for ; Thu, 2 Nov 1995 05:41:23 -0800 Received: by Mizar.DoCS.UU.SE (Sun-4/260, SunOS 4.0) with sendmail 5.61-bind 1.5+ida/ICU/DoCS/mizar id AA18621; Thu, 2 Nov 95 14:39:20 +0100 Date: Thu, 2 Nov 95 14:39:20 +0100 From: Anders Andersson Message-Id: <9511021339.AA18621@Mizar.DoCS.UU.SE> To: genweb@UCSD.EDU Subject: Re: interdatabse linking Cc: Herbert.Stoyan@informatik.uni-erlangen.de [GenWeb project group: Resource Identifiers] Herbert Stoyan writes: >Scott doubts that the urls like >http://www8.informatik.uni-erlangen.de/cgi-bin/ll/BASE=stoyan/LANG=engl/F=Herbert/N=Stoyan/?Lookup >are not unique. >They are, because there is an additional entry (an there could be even more): >/Q=.... you may add: birth dates or death dates: >/Q=B:5.8.1943 You can meet the uniqueness criteria by adding as much arbitrary data about the person to the URL as you like (say, place of birth, sex, or name of parent), but then you risk the URL having to change as your research progresses and you discover that your initial information was wrong (or simply missing). >For the William Ward, born at 5th of October 1833 use: >http://.../F=William/N=Ward/Q=B:5.10.1833 What if William Ward had been born in a country where the Julian calendar was still in effect (Russia switched to Gregorian only in 1918), and it turned out the researcher reading the primary source overlooked this fact? Dates can be uncertain for a number of reasons, and the same holds for just about any piece of "real data". I think someone already mentioned variant spelling of names. If you change the URL to match your current information about the person, then links will break as you go along and update your database, even though there is little doubt about the identity of the person - we are talking about the same William Ward, not a different one who happened to be born 12 days later. If you retain your initial URL for each person forever, then the links will stay intact, but you may have to store two birthdates: The actual birthdate, and the "birthdate" used in the URL for purely historical reasons. Unnecessarily complicated and confusing, I'd say. Finally, for some persons you may not find enough suitable data to make up a unique URL, such as "infant girl who died before baptism". The point of allocating an arbitrary (probably serial) for each person you encounter during your research is that you can give that person a stable identifier immediately, without having to establish any reliable information about the person's full name, birthdate or the like (which may take more than a few days). Since it doesn't depend on "real data", it can remain the same forever, and it won't confuse anyone by looking like factual information about the person. Links may still break when you have mistakenly mixed substantial amounts of data about two individuals making up a fictious person in your records, and other researchers have linked their records to yours on different grounds. You would then have to "split" this guy and ask the other researchers to reexamine their records. However, that's a complicated problem which anyway isn't solved by using a name and birthdate in place of an integer number. -- 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 From list-relay@UCSD.EDU Thu Nov 2 13:20:43 1995 Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id NAA16108 for ; Thu, 2 Nov 1995 13:20:42 -0800 Received: from dragon.ti.com (dragon.ti.com [192.94.94.61]) by UCSD.EDU (8.6.12/8.6.9) with ESMTP id MAA27581 for ; Thu, 2 Nov 1995 12:35:12 -0800 Received: from tilde.csc.ti.com ([128.247.160.56]) by dragon.ti.com (8.6.12/) with ESMTP id OAA27243; Thu, 2 Nov 1995 14:34:33 -0600 Received: from ticipa.Works.Ti.Com (ticipa.works.ti.com [128.247.112.8]) by tilde.csc.ti.com (8.6.12/8.6.12) with SMTP id OAA03335; Thu, 2 Nov 1995 14:34:33 -0600 Received: from census.works.ti.com by ticipa.Works.Ti.Com with SMTP id AA24849 (5.65c/IDA-1.4.4); Thu, 2 Nov 1995 14:34:13 -0600 Received: by census.Works.Ti.Com (5.x/SMI-SVR4) id AA07467; Thu, 2 Nov 1995 14:34:13 -0600 Date: Thu, 2 Nov 1995 14:34:13 -0600 From: steele@ticipa.Works.ti.com (Jeri Steele) Message-Id: <9511022034.AA07467@census.Works.Ti.Com> To: GEDCOM-L@vm1.nodak.edu, GENWEB@UCSD.EDU Subject: MARC based source information Reply-To: steele@census.works.ti.com GENWEB-L & GEDCOM-L readers might want to take a look at the FINLEY database (see website below). In correspondence with Carmen Finley, I discovered that she footed the bill to have the Sonoma State University make changes to the MARC formats and to support her project! (she also did ALL the data entry herself) [MARC is the database language used by lots of the libraries for their catalogs.] This is primarily a sources database but since MARC had come up before as an alternative to GEDCOM, I was very excited to see someone actually get a project on the WWW using the MARC format. If others start to do such projects, we may well see software programs output MARC format files too! I would love to hear if anyone else has had success convincing a library to support such a project! Jeri Steele __________________________________________________ Date: Tue, 31 Oct 1995 19:01:46 -0700 From: Carmen Finley Subject: FINLEY and MC FARLING/MC FARLAND database FINLEY and MC FARLING/MC FARLAND researchers may be interested in knowing about the young and developing database of Finley and McFarling information which is now available through Sonoma State University at Rohnert Park, California. A year in the design and development, there are now about 120 citations to documents involving early Finleys in Virginia now available through SSU Special Collections. These documents, all in transcribed form and many with copies of the original document, include deeds, court records, tax records, probate records, abstracts taken from standard early Virginia sources, census records and others taken from the personal files of Carmen J. Finley. Of those records now in the database, the vast majority come from Augusta County, Virginia, but there are also other Virginia documents from Albemarle, Amhurst, Bedford, Botetourt, Fincastle, Montgomery, Prince Edward, Rockbridge, Washington, and Wythe Counties. Within the next year or two, plans include the addition of another 500 or so citations and documents on Finleys in Kentucky, Tennessee, North and South Carolina, Indiana, Illinois, Missouri, Texas, and California. TheMcFarling/McFarland line contained withinin the Finley database currently has about 175 citations on McFarlings in Scotland, Virginia, Ohio, and California. Anyone with a modem and access to Internet can search this database much as you would any library catalog. Citations can be searched on author, title, subject, and keywords. If you find something you would like to see, it can be requested through the Ruben Salazar Library, Special Collections, Sonoma State University, Rohnert Park, California 94928. At the present time there is no charge for this service, although there may be a limit on the number of documents that can be requested at any given time. To access the Finley database at SSU you can use one of two methods. Method One - Telnet Telnet vax.sonoma.edu At Username type: OPAC >From the main menu select: SSU collections (option 1) >From the next menu select: FIND >From the FIND menu select: CHOOSE DATABASE >From the CHOOSE DATABASE menu select: FINLEY FAMILY HISTORY (If not shown on list, use down arrow key to scroll) Once you are in the FINLEY FAMILY HISTORY database select: FIND At this point you can search on author, title, subject, or keyword and follow the directions on the screen. Method Two - World Wide Web To access SSU World Wide Web: http://WWW.sonoma.edu/library/ Go to: SALAZAR LIBRARY COLLECTIONS Go to: LOCAL DATABASES Select: FINLEY DATABASE (If not shown on list, use down arrow key to scroll) At the present time, the SSU WWW is still in its infancy and it is best to search mainly on subject. You have the option of entering one or two terms on which to search. When you have specified these terms, click on the SUBMIT QUERY box. A little experimentation may be necessary to find your way around this system until it is developed further. __________________________________________________ From list-relay@UCSD.EDU Fri Nov 3 06:02:58 1995 Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id GAA18984 for ; Fri, 3 Nov 1995 06:02:56 -0800 Received: from doit.com (just.doit.com [204.214.7.1]) by UCSD.EDU (8.6.12/8.6.9) with ESMTP id GAA26912 for ; Fri, 3 Nov 1995 06:00:22 -0800 Received: (from tdoyle@localhost) by doit.com (8.6.9/8.6.9) id HAA29660; Fri, 3 Nov 1995 07:58:02 -0600 Date: Fri, 3 Nov 1995 07:58:01 -0600 From: Tim Doyle Subject: Re: interdatabse linking To: genweb@UCSD.EDU In-Reply-To: <9511021339.AA18621@Mizar.DoCS.UU.SE> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 2 Nov 1995, Anders Andersson wrote: > The point of allocating an arbitrary (probably serial) for each > person you encounter during your research is that you can give that > person a stable identifier immediately, without having to establish > any reliable information about the person's full name, birthdate or > the like (which may take more than a few days). Since it doesn't > depend on "real data", it can remain the same forever, and it won't > confuse anyone by looking like factual information about the person. This is exactly what I have been working on. Each person in my database (TMG) is internally assigned a number when added. An option on the GEDCOM export allows this ID number to be exported in the NUMB tag. While my IGM scripts were previously using the seek position in the GEDCOM for each person's URL, they have been enhanced to now use this ID number, prefixed with 'ID' to distinguish between the old seek URLs, which are still accepted for databases which do not yet have the NUMB tags. Since each person in my GenWeb database now has a permanent ID number, I have implemented linking. Each person's page now includes a 'Links' section. Any links to other databases are currently listed, and a button to 'Add a Link' is included. To add a link to any database at my site, anyone in the world can now simply click a button, enter the other database name and the URL to the individual in that database and save the link. To see a person with links already added, see Thomas Hurlburt (b. 1610) and/or Samuel Jennison (b. 1645). Thomas Hurlburt is linked to the Hurlburt database, also on my system. Samuel Jennison is linked to the Everingham database, not on my system. If you would like to add a test link yourself, please add it to John Hooker (b. 1770), ID100. I'll know to delete these periodically for him. I'd be interested to hear any thoughts or suggestions about this. Tim Doyle / tdoyle@doit.com / tdoyle@netcom.com / 73267.260@compuserve.com WWW homepage: http://www.doit.com/tdoyle/ ftp directory: ftp.doit.com pub/tdoyle From list-relay@UCSD.EDU Fri Nov 3 09:08:16 1995 Received: from UCSD.EDU (mailbox2.ucsd.edu [132.239.1.54]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id JAA19266 for ; Fri, 3 Nov 1995 09:08:15 -0800 Received: from apple.com (apple.com [130.43.2.2]) by UCSD.EDU (8.6.12/8.6.9) with SMTP id JAA00813 for ; Fri, 3 Nov 1995 09:10:05 -0800 Received: from [17.255.39.182] by apple.com with SMTP (5.61/8-Oct-1993-eef) id AA16547; Fri, 3 Nov 95 09:09:45 -0800 for genweb@ucsd.edu Message-Id: <9511031709.AA16547@apple.com> X-Sender: tesler@130.43.2.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 3 Nov 1995 09:10:05 -0800 To: genweb@UCSD.EDU From: tesler@apple.com (Larry Tesler) Subject: Re: interdatabse linking At 7:58 AM 11/3/95 -0600, Tim Doyle wrote: >Since each person in my GenWeb database now has a permanent ID number, I >have implemented linking. Each person's page now includes a 'Links' >section. Any links to other databases are currently listed, and a button >to 'Add a Link' is included. To add a link to any database at my site, >anyone in the world can now simply click a button, enter the other >database name and the URL to the individual in that database and save the >link. Tim, That is an excellent solution to the problem at hand. I think it likely that the following two well-known problems will be encountered next: (1) someone will change the URL of a database to which you have a link; (2) someone will link one of your person pages to the wrong place, either by mistyping the URL or by exercising poor genealogical judgement. Let's call your GenWeb site "A" and the other GenWeb site "B". If the links are bidirectional, problem (1) can be addressed with automation on site B. That is, a script could change all links out of site B, and also send messages out to revise links from sites such as A that reference it. This solution is esthetically clean, but very unlikely to be successful for a host of practical reasons. Problem (1) can be addressed better, I think, if each interdatabase link indirects through one (or one of a few) well-publicized central site(s). The central site (let's call it "C") would maintain a URL for each individual on any GenWeb site that is referenced from any different GenWeb site. 'Add a Link' would not install the individual's URL at site B onto the page at site A, but would instead install the individual's URL at site C onto the page at site A, and would (if not yet there) install the URL at site B onto a page at the central site C. Central site C would also maintain a database of GenWeb sites, storing for each site some identifying information such as distinguishing commentary (surnames, place names, owner's email address, etc.). The disadvantage of relying on centralized sites is that it is not a fully distributed scheme. But there can be several centralized sites to provide redundancy and a semi-distributed architecture. And there are several advantages, as will be seen in a moment. If site B's URL changes, ideally the owner would run a script that notifies the central site C, which makes one small change to each B-URL it has, and all is well. If site B's owner forgets to or can't notify site C that its URL is changing, it is still possible for site C, when it tries to follow a link to site B and repeatedly fails, to run a script that searches a GenWeb subset of a WWW full-text catalog (Lycos or similar) for the identifying information that it retained, in hopes of finding the new URL. Doing this search and the subsequent revision is more efficient and practical to do on a central site than on each GenWeb site. If a central site's URL changed, or if it went away (both rare events), a script could consult any other central site, becase each would maintain a list of all other central sites. When a user clicked a link at site A, their web browser could either: (i) show the central site C entry, or (ii) skip it and go directly to the URL at site B. The advantage of (ii) is that the user would get to the linked person sooner. Site A could even cache the URL at site B and only go to C if the cached link fails. The main advantage of (i) is that the user can see important info such as comments by other people about the credibility of the link. It is also the way the web naturally works. Problem (2) is also addressed by this scheme because a user can see those comments and consider them in establishing his or her own opinion. The comments can eventually be signed using validated electronic signatures (e.g., Verisign). Is this scheme one that has already been discussed here, or seen in use elsewhere? In thinking of how Apple could help out on this project, one idea I've discussed with Gary is hosting a central site. Larry *************************************************************************** * Larry Tesler, Chief Scientist, Apple Computer, Inc. * * USMail..1 Infinite Loop, M/S 81-M, Cupertino, CA, 95014 * * EMail...Internet: tesler@apple.com; AppleLink: TESLER * * Phone...(408) 974-2219, Fax: (408) 974-1794 * *************************************************************************** From list-relay@UCSD.EDU Fri Nov 3 10:23:32 1995 Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id KAA19444 for ; Fri, 3 Nov 1995 10:23:31 -0800 Received: from atc.ameritel.net (atc.ameritel.net [204.183.96.100]) by UCSD.EDU (8.6.12/8.6.9) with ESMTP id KAA06357 for ; Fri, 3 Nov 1995 10:25:07 -0800 Received: from richard.atc.ameritel.net (pt5.an1.ameritel.net [204.183.100.5]) by atc.ameritel.net (8.6.11/8.6.9) with SMTP id NAA22982 for ; Fri, 3 Nov 1995 13:19:35 -0500 Date: Fri, 3 Nov 1995 13:19:35 -0500 Message-Id: <199511031819.NAA22982@atc.ameritel.net> X-Sender: richard@atc.ameritel.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: GENWEB@UCSD.EDU From: "Richard A. Everett" Subject: Dreifuerst Family Looking for any and all information on the Dreifuerst Family Line. Richard A. Everett The true beauty of any tree lies not in it's roots but in it's BRANCHES From list-relay@UCSD.EDU Fri Nov 3 14:53:02 1995 Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id OAA20087 for ; Fri, 3 Nov 1995 14:53:01 -0800 Received: from relay-4.mail.demon.net (relay-4.mail.demon.net [158.152.1.64]) by UCSD.EDU (8.6.12/8.6.9) with SMTP id OAA18684 for ; Fri, 3 Nov 1995 14:54:52 -0800 Received: by relay-4.mail.demon.net id sg.aa03085; 3 Nov 95 22:53 GMT Received: from post.demon.co.uk by relay-4.mail.demon.net id sg.af28438; 3 Nov 95 22:19 GMT Received: from relay-4.mail.demon.net by relay-3.mail.demon.net id aa26968; 3 Nov 95 22:14 GMT From: Trevor Jenkins Organisation: Don't put it down; put it away! To: Jeri Steele , GEDCOM-L@vm1.nodak.edu, GENWEB@UCSD.EDU Date: Fri, 3 Nov 1995 21:56:09 +0000 Message-ID: <4636.tfj@apusapus.demon.co.uk> Subject: Re: MARC based source information Reply-To: tfj@apusapus.demon.co.uk Priority: normal X-mailer: Pegasus Mail for Windows (v2.01) via wpkGate v2.01 On 2 Nov 95 at 14:34, Jeri Steele wrote: > If others start to do such projects, we may well see software > programs output MARC format files too! Oh I hope not. :-| MARC is one of the most perversely defined machine readable formats there is. As it is machine readable I reckon machines defined it and machines should be made to use it. I have had to write several MARC conversion programs in the last few years and the thought of anyone replacing GEDCOM with MARC is enough to make me give up. GEDCOM's virtue, if it has any, is that is is humanly readable. You can pull a GEDCOM file into your favourite text editor and view as it is and, if necessary, amend it. With MARC you have to write a specific viewing program to look at the data and to modify the data. Regards, Trevor. -- From list-relay@UCSD.EDU Sun Nov 5 13:52:54 1995 Received: from UCSD.EDU (mailbox2.ucsd.edu [132.239.1.54]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id NAA27061 for ; Sun, 5 Nov 1995 13:52:53 -0800 Received: from yeti.polarnet.fnsb.ak.us (yeti.polarnet.fnsb.ak.us [204.119.24.10]) by UCSD.EDU (8.6.12/8.6.9) with SMTP id NAA26036 for ; Sun, 5 Nov 1995 13:51:38 -0800 Message-Id: <199511052151.NAA26036@UCSD.EDU> Received: from nb1-du7.polarnet.com by yeti.polarnet.fnsb.ak.us id aa025439 at Sun, 5 Nov 95 12:51:21 Alaskan Standard Time+0000 X-Sender: thebert@mail.polarnet.com (Unverified) X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "genweb@ucsd.edu"@yeti.polarnet.com From: "TODD G. HEBERT" Subject: help Date: Sun, 5 Nov 95 12:51:21 Alaskan Standard Time+0000 X-Mailedby: NT SMTP/LISTSERVER v2.10 (ntmail@net-shopper.co.uk) To whom it may concern. We need help tracing my indian ancestry with the Cherokee nation. If you could supply any useful information reguarding this subject please notify us by our email address. thebert@polarnet.com thanks, Todd. From list-relay@UCSD.EDU Mon Nov 6 02:45:48 1995 Received: from UCSD.EDU (mailbox2.ucsd.edu [132.239.1.54]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id CAA29774 for ; Mon, 6 Nov 1995 02:45:47 -0800 Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.2.45]) by UCSD.EDU (8.6.12/8.6.9) with ESMTP id CAA08381 for ; Mon, 6 Nov 1995 02:46:18 -0800 Received: from immd8.informatik.uni-erlangen.de (root@faui80.informatik.uni-erlangen.de [131.188.38.1]) by uni-erlangen.de with SMTP id JAA02112 (8.6.12/7.4f-FAU); for ; Mon, 6 Nov 1995 09:58:41 +0100 Received: from faui8c by immd8.informatik.uni-erlangen.de; id AA27705 (5.x/7.3w-FAU); Mon, 6 Nov 1995 09:58:39 +0100 From: Herbert Stoyan Message-Id: <9511060858.AA27705@immd8.informatik.uni-erlangen.de> Date: Mon, 6 Nov 1995 09:58:37 +0100 To: genweb@UCSD.EDU Subject: Interdatabase linking X-Sun-Charset: US-ASCII The reasons for a special link identifier are convincing. Everybody who has some knowledge in data processing know that speaking keys (encoding information in keys as I had proposed) breaks sometimes. Anders made his points. Well, if we take this way, we should try to agree how we encode the links in Gedcom. Tim's proposal seems to be: After the IND record a NUMB record? 0 @I...@ INDI 1 NUMB id-number Should we encode in the id-number a database identification? It would be nice if lifelines would support searching for id-numbers. At present, it has an acceptable way to search for keys (internal identification which may change by each new release of a database) and a not acceptable way to search for names (which is fine if you use lifelines directly). I fear, searching for id-numbers by a forindi-loop would not be fast enough. From list-relay@UCSD.EDU Mon Nov 6 05:50:07 1995 Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id FAA29899 for ; Mon, 6 Nov 1995 05:50:06 -0800 Received: from mail.fonorola.net (mail.fonorola.net [198.53.64.8]) by UCSD.EDU (8.6.12/8.6.9) with SMTP id FAA20285 for ; Mon, 6 Nov 1995 05:46:41 -0800 Received: from infoweb.magi.com by mail.fonorola.net with SMTP (5.65/25-eef) id AA18411; Mon, 6 Nov 95 08:38:41 -0500 Received: from hpurdy (magi03p20.magi.com) by magi.com (5.x/SMI-SVR4) id AA00914; Mon, 6 Nov 1995 08:46:19 -0500 Date: Mon, 6 Nov 1995 08:46:18 -0500 Message-Id: <9511061346.AA00914@magi.com> X-Sender: hpurdy@magi.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: genweb@UCSD.EDU From: Herbert Stoyan (by way of hpurdy@magi.com (Harry Purdy)) Subject: Interdatabase linking This ended up in my mail box and I am redirecting it to you Harry Purdy hpurdy@magi.com ------ The reasons for a special link identifier are convincing. Everybody who has some knowledge in data processing know that speaking keys (encoding information in keys as I had proposed) breaks sometimes. Anders made his points. Well, if we take this way, we should try to agree how we encode the links in Gedcom. Tim's proposal seems to be: After the IND record a NUMB record? 0 @I...@ INDI 1 NUMB id-number Should we encode in the id-number a database identification? It would be nice if lifelines would support searching for id-numbers. At present, it has an acceptable way to search for keys (internal identification which may change by each new release of a database) and a not acceptable way to search for names (which is fine if you use lifelines directly). I fear, searching for id-numbers by a forindi-loop would not be fast enough. From list-relay@UCSD.EDU Mon Nov 6 08:20:45 1995 Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id IAA00235 for ; Mon, 6 Nov 1995 08:20:45 -0800 Received: from Mizar.DoCS.UU.SE (Mizar.DoCS.UU.SE [130.238.11.21]) by UCSD.EDU (8.6.12/8.6.9) with SMTP id IAA24120 for ; Mon, 6 Nov 1995 08:23:14 -0800 Received: by Mizar.DoCS.UU.SE (Sun-4/260, SunOS 4.0) with sendmail 5.61-bind 1.5+ida/ICU/DoCS/mizar id AA01104; Mon, 6 Nov 95 17:23:10 +0100 Date: Mon, 6 Nov 95 17:23:10 +0100 From: Anders Andersson Message-Id: <9511061623.AA01104@Mizar.DoCS.UU.SE> To: genweb@UCSD.EDU Subject: Re: interdatabse linking Cc: tdoyle@just.doit.com [GenWeb project groups: Resource Identifiers, Engineering] Tim Doyle writes: >This is exactly what I have been working on. Each person in my database >(TMG) is internally assigned a number when added. An option on the GEDCOM >export allows this ID number to be exported in the NUMB tag. While my IGM >scripts were previously using the seek position in the GEDCOM for each >person's URL, they have been enhanced to now use this ID number, prefixed >with 'ID' to distinguish between the old seek URLs, which are still >accepted for databases which do not yet have the NUMB tags. Is the NUMB tag defined in any version of the GEDCOM standard? If so, does it have a stated purpose? Is there a reason for not using this internally assigned number as the identifier with the INDI tag (and forgetting about the NUMB tag)? Since there is a 1-1 relationship between GEDCOM INDI records and persons in the source database, I don't see why we would have to assign two arbitrary identifiers separately. -- 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 From list-relay@UCSD.EDU Mon Nov 6 09:56:33 1995 Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id JAA00430 for ; Mon, 6 Nov 1995 09:56:33 -0800 Received: from sbstark.cs.sunysb.edu (sbstark.cs.sunysb.edu [130.245.1.47]) by UCSD.EDU (8.6.12/8.6.9) with ESMTP id JAA28023 for ; Mon, 6 Nov 1995 09:58:47 -0800 Received: (from root@localhost) by sbstark.cs.sunysb.edu (8.6.12/8.6.9) with UUCP id MAA08983; Mon, 6 Nov 1995 12:56:47 -0500 Received: (from gene@localhost) by starkhome.cs.sunysb.edu (8.6.11/8.6.9) id MAA03368; Mon, 6 Nov 1995 12:58:20 -0500 Date: Mon, 6 Nov 1995 12:58:20 -0500 From: Gene Stark Message-Id: <199511061758.MAA03368@starkhome.cs.sunysb.edu> To: Anders Andersson Cc: genweb@UCSD.EDU In-reply-to: Anders Andersson's message of Mon, 6 Nov 95 17:23:10 +0100 Subject: Re: interdatabse linking References: <47lefc$35b@starkhome.cs.sunysb.edu> Anders Andersson writes: > Tim Doyle writes: > >This is exactly what I have been working on. Each person in my database > >(TMG) is internally assigned a number when added. An option on the GEDCOM > >export allows this ID number to be exported in the NUMB tag. While my IGM > >scripts were previously using the seek position in the GEDCOM for each > >person's URL, they have been enhanced to now use this ID number, prefixed > >with 'ID' to distinguish between the old seek URLs, which are still > >accepted for databases which do not yet have the NUMB tags. > > Is the NUMB tag defined in any version of the GEDCOM standard? > If so, does it have a stated purpose? I agree with Anders. We should feel free to set GenWeb standards and formats, but we should not gratuitously introduce additional GEDCOM tags that are not part of some quasi-official standard. There are too many such tags already. There are three reference number tags already in the GEDCOM 5.3 draft standard: +1 RFN {0:M} +1 REFN {0:M} +1 AFN {0:1} Obviously we cannot use the AFN, since the LDS Ancestral file is using that. It would be a bad idea to use the internal cross reference ID's, ("I1011" and the like), because genealogical software feels free to assign these. However, we still have REFN and RFN. What is wrong with REFN? - Gene Stark From list-relay@UCSD.EDU Mon Nov 6 10:59:12 1995 Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id KAA00601 for ; Mon, 6 Nov 1995 10:59:12 -0800 Received: from gate.microware.com (gate.microware.com [198.17.151.51]) by UCSD.EDU (8.6.12/8.6.9) with SMTP id KAA00870 for ; Mon, 6 Nov 1995 10:58:52 -0800 Received: by gate.microware.com; id AA06240; Mon, 6 Nov 95 12:56:50 CST Received: from mcrware.microware.com(192.52.109.32) by gate.microware via smap (g3.0.1) id xma006235; Mon, 6 Nov 95 12:56:45 -0600 Received: from wales (wales.microware.com) by mcrware.microware.com with SMTP id AA27540 (5.67a8/IDA-1.5 for ); Mon, 6 Nov 1995 12:58:29 -0600 From: Scott McGee Received: by wales id ; Mon, 6 Nov 95 12:58:28 CST Date: Mon, 6 Nov 95 12:58:28 CST Message-Id: <9511061858.AA21520@wales> To: genweb@UCSD.EDU Subject: Re: interdatabse linking Anders comments remind me of another thing that can be important in having unique URLs for each person in a database. Lets take the case of the wife of this same William Ward I used before. I had listed three spouses, one named Hannah Brigham, one named Hannah Brigham Eams, and one named Hannah Johnson. All three are have the same marriage date to William Ward. Now, looking at the other database, I see that Hannah Brigham was previously married to a Gershom Eames. Now, looking, it becomes obvious that Hannah Brigham Eams is the same person as Hannah Brigham (I suspect Hannah Johnson is too, but have found no evidence other than first name and marriage date). Now, if someone else had a link to one of these two, and someone else a link to the other, and I combine the two, this should not invalidate either link. For simplisity sake, lets assume I use some integer for making a permanant unique ID. Lets assign Hannah Brigham 47 and Hannah Brigham Eams 52. Now, (however I implement this) if I combine the two, the resultant entry in my database should contain two such IDs, both 47 and 52. Thus either URL remains premanantly correct. On the other hand, if I were to find a person in my database who was fictitious, I would assume that the entry would be changed to show this along with some documentation, and that the ID would be left there, so that someone who might have linked to this person would get a valid link and find out what I had discovered. If, in resolving this fictious person, I find it is really two people, I should give each a brand new ID and create a link from the fictious entry to each of them. Does this sound right to the rest of you? I had once though of using the Ancestoral Family's AFN (since most of my database entries have them) but ran into problems with what to do with those entries that don't have one. Currently, I am thinking I should have some master database somewhere that keeps track of which ID's have been assigned, and some utility to assign new ID's and update the database. In a simplistic case, the database could perhaps be reduced to a simple counter, but I am not yet sure. Since I use LifeLines, I have no problem creating a new GEDCOM tag to hold the ID, and coding my GenWeb software to use it. I can even write a report that will remove, modify, or coment this ID tag when exporting GEDCOM for sharing with others. I just want to make sure I have it figured out right before I start it. Oh, one more thing on a slightly different topic. I have added code to my GenWeb programs to allow viewing of the GEDCOM for any person. There are currently no automaticly generated URLs that will give this to you, and I am not sure if it is something I should do or not. To try it, take any URL for someone in one of my databases, and change the final path element (the command, one of LookupInternal, PedigreeInternal, or DescendantInternal) and replace it with GEDCOM. (be sure to leave the '?' there!) Thus, my own entry is: http://www.emcee.com/~smcgee/cgi-bin/genweb.cgi/DB=mcgee/INDEX=I9/?LookupInternal and my gedcom could be obtained from: http://www.emcee.com/~smcgee/cgi-bin/genweb.cgi/DB=mcgee/INDEX=I9/?GEDCOM Comments invited. thanks 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 <------------- From list-relay@UCSD.EDU Mon Nov 6 11:32:48 1995 Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id LAA00680 for ; Mon, 6 Nov 1995 11:32:47 -0800 Received: from gate.microware.com (gate.microware.com [198.17.151.51]) by UCSD.EDU (8.6.12/8.6.9) with SMTP id LAA02486 for ; Mon, 6 Nov 1995 11:35:08 -0800 Received: by gate.microware.com; id AA06711; Mon, 6 Nov 95 13:32:54 CST Received: from mcrware.microware.com(192.52.109.32) by gate.microware via smap (g3.0.1) id xma006709; Mon, 6 Nov 95 13:32:51 -0600 Received: from wales (wales.microware.com) by mcrware.microware.com with SMTP id AA28780 (5.67a8/IDA-1.5); Mon, 6 Nov 1995 13:34:34 -0600 From: Scott McGee Received: by wales id ; Mon, 6 Nov 95 13:34:33 CST Date: Mon, 6 Nov 95 13:34:33 CST Message-Id: <9511061934.AA21587@wales> To: andersa@mizar.docs.uu.se, gene@starkhome.cs.sunysb.edu Subject: Re: interdatabse linking Cc: genweb@UCSD.EDU Gene asks what is wrong with using REFN. I posted a message on this. Maybe I accidently sent it to an individual instead of the list. I said that one problem I saw was that I though that only one REFN was allowed, but I may have been mistaken on that. If multiple REFN tags are allowed, REFN is a very good candidate as it can be used by LifeLines (which is one of the more common genweb programs) to directly access a person just as the internal indi specifier (key) can. On the other hand, if only one instance is allowed, what of those who already use REFN tags in their database. In my opinion, more important than how to code the unique id in the database (something that will be important to Gene and I since we both are providing genweb software - but we can worry about that later) is the question of how to assign them. Especially with Gene's ged2html program (and equivalant LL base programs of mine), if you have updated your database (which may not allow putting a REFN [or whatefer] tag into the database) and want to update your web site, you must export a new GEDCOM and then run something which will add the same unique ID to the same persons who may now have a different INDI reference number. If each time a user does this, they get new unique id's, no benefit is obtained over using the native INDI reference. Yes, old URLs will not take you to the wrong person, but they won't take you to ANY person! In fact, if you change one bit data on one person, and regenereate the database with something like that, you invalidate every URL while each of them was still correct! This can be improved with LifeLines and other programs that will allow you put the indexing tag into the database and export it in the GEDCOM, but is this a restriction on genealogy programs we have to make? Scott When in danger, | If it has my name on it, it must be MY opinion! or in doubt, |______________________________________________________ run in circles, | Email: smcgee@microware.com (Scott McGee) scream and shout! | Web: http://www.cc.utah.edu/~sam8644/homepage.html From list-relay@UCSD.EDU Mon Nov 6 12:15:45 1995 Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id MAA00877 for ; Mon, 6 Nov 1995 12:15:45 -0800 Received: from sbstark.cs.sunysb.edu (sbstark.cs.sunysb.edu [130.245.1.47]) by UCSD.EDU (8.6.12/8.6.9) with ESMTP id MAA04212 for ; Mon, 6 Nov 1995 12:18:08 -0800 Received: (from root@localhost) by sbstark.cs.sunysb.edu (8.6.12/8.6.9) with UUCP id PAA09077; Mon, 6 Nov 1995 15:16:02 -0500 Received: (from gene@localhost) by starkhome.cs.sunysb.edu (8.6.11/8.6.9) id PAA03615; Mon, 6 Nov 1995 15:06:15 -0500 Date: Mon, 6 Nov 1995 15:06:15 -0500 From: Gene Stark Message-Id: <199511062006.PAA03615@starkhome.cs.sunysb.edu> To: smcgee@microware.com CC: andersa@mizar.docs.uu.se, genweb@UCSD.EDU In-reply-to: <9511061934.AA21587@wales> (message from Scott McGee on Mon, 6 Nov 95 13:34:33 CST) Subject: Re: interdatabse linking Regarding REFN: Another possibility is to use a NOTE record with a standard, easily identifiable sequence at the beginning to specify the numbers. - Gene From list-relay@UCSD.EDU Mon Nov 6 12:17:54 1995 Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id MAA00885 for ; Mon, 6 Nov 1995 12:17:53 -0800 Received: from Mizar.DoCS.UU.SE (Mizar.DoCS.UU.SE [130.238.11.21]) by UCSD.EDU (8.6.12/8.6.9) with SMTP id MAA04304 for ; Mon, 6 Nov 1995 12:21:05 -0800 Received: by Mizar.DoCS.UU.SE (Sun-4/260, SunOS 4.0) with sendmail 5.61-bind 1.5+ida/ICU/DoCS/mizar id AA04086; Mon, 6 Nov 95 21:20:49 +0100 Date: Mon, 6 Nov 95 21:20:49 +0100 From: Anders Andersson Message-Id: <9511062020.AA04086@Mizar.DoCS.UU.SE> To: genweb@UCSD.EDU Subject: Re: interdatabse linking Cc: gene@starkhome.cs.sunysb.edu [GenWeb project groups: Resource Identifiers, Engineering] Gene Stark writes: >There are three reference number tags already in the GEDCOM 5.3 draft >standard: My copy of that draft is dated 4 November 1993. Does anyone know what the status of that draft is today? > +1 RFN {0:M} > +1 REFN {0:M} > +1 AFN {0:1} >Obviously we cannot use the AFN, since the LDS Ancestral file is using that. Agreed. >It would be a bad idea to use the internal cross reference ID's, ("I1011" >and the like), because genealogical software feels free to assign these. I don't quite buy this argument, but I'll defer judgement until I have more facts. It will obviously take time before off-the-shelf software can be expected to automatically assign whatever unique identifiers we come up with here (I don't plan to manually enumerate the individuals in my database, but I rather expect that to be done in an automated fashion), so how would we go about using them today? In the cases when genealogical software assigns cross reference ID's in any manner, can't they be used as ID's for external cross references as well? >However, we still have REFN and RFN. What is wrong with REFN? I wasn't aware of them, but they seem relevant now that I have checked the draft. The REFN tag can occur in Family, Individual, and Source records, providing some kind of a reference string in a user-defined format. The RFN tag, on the other hand, occurs only in Individual records, and has a more restricted syntax (it reserves the colon as a delimiter between the identifiers for the database and for the record within that database). It appears to me that RFN is more to the point of what we are discussing, but it may be that we want to have stable identifiers also for other records than those of individual persons. However, I feel that the REFN tag isn't too well defined, and that it might be used for other purposes simultaneously with our usage. Can we deal with that? Anyway, I don't think GEDCOM is our primary concern here. When we discuss GenWeb linking in general, we should anticipate databases with an internal (unknown) format and an HTML interface without any GEDCOM involved. Thus we need to define the concept of a stable person (or record) identifier, and then allow database designers to implement it in any way they like. When GEDCOM is present, it's a good idea to map this identifier to a specific GEDCOM tag, but we should not depend on its existance. -- 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 From list-relay@UCSD.EDU Mon Nov 6 13:31:40 1995 Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id NAA01027 for ; Mon, 6 Nov 1995 13:31:39 -0800 Received: from doit.com (just.doit.com [204.214.7.1]) by UCSD.EDU (8.6.12/8.6.9) with ESMTP id NAA07180 for ; Mon, 6 Nov 1995 13:33:06 -0800 Received: from tdoyle.doit.com (fred.doit.com [204.214.7.114]) by doit.com (8.6.9/8.6.9) with SMTP id PAA14677; Mon, 6 Nov 1995 15:16:07 -0600 Date: Mon, 6 Nov 1995 15:16:07 -0600 Message-Id: <199511062116.PAA14677@doit.com> X-Sender: tdoyle@204.214.7.1 X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: genweb@UCSD.EDU From: "Timothy B. Doyle" Subject: Re: interdatabse linking Cc: tdoyle@just.doit.com At 05:23 PM 11/6/95 +0100, Anders Andersson wrote: >Is the NUMB tag defined in any version of the GEDCOM standard? >If so, does it have a stated purpose? According to Bob Velke, author of The Master Genealogist, the NUMB tag is defined in the current GEDCOM standard (4.0). I do not have a copy of the 4.0 standard so I can't quote it's stated purpose. Perhaps someone else can help out here. I checked the GEDCOM 5.3 DRAFT and did not see the NUMB tag listed, perhaps it is slated to be removed. Although many programs are now using 5.1, 5.2, 5.3, and/or 5.4 DRAFTS, we must remember that they are just that, DRAFTS (i.e. proposals) and, in my opinion, should not yet be used by any reputable genealogical program. >Is there a reason for not using this internally assigned number as >the identifier with the INDI tag (and forgetting about the NUMB tag)? >Since there is a 1-1 relationship between GEDCOM INDI records and >persons in the source database, I don't see why we would have to >assign two arbitrary identifiers separately. I'd love to be able to do so, but according to Bob, the INDI numbers do not necessarily correspond to the identification numbers used in the database of origin in any of the GEDCOM specifications. The GEDCOM 5.3 Draft states: "The opt_xref_id [referring to the @###@ field] is formed by any arbitrary combination of characters from the pointer_char set. The first character must be an alpha or a digit. The opt_xref_id is not retained in the receiving system, and may therefore be formed from any convenient combination of identifiers from the sending system. No meaning is attributed by the receiver to any part of the opt_xref_id, other than its unique association with the associated record." While it may be true that the GEDCOM export for the program you are using does use its internal numbers for the INDI numbers, this can not be assumed to be true for all programs. -------------------------------------------------- Tim Doyle tdoyle@doit.com / tdoyle@netcom.com WWW homepage: ftp://www.doit.com/tdoyle/ ftp directory: doit.com pub/tdoyle From list-relay@UCSD.EDU Mon Nov 6 13:36:22 1995 Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id NAA01034 for ; Mon, 6 Nov 1995 13:36:21 -0800 Received: from gate.microware.com (gate.microware.com [198.17.151.51]) by UCSD.EDU (8.6.12/8.6.9) with SMTP id NAA07406 for ; Mon, 6 Nov 1995 13:39:18 -0800 Received: by gate.microware.com; id AA07941; Mon, 6 Nov 95 15:37:06 CST Received: from mcrware.microware.com(192.52.109.32) by gate.microware via smap (g3.0.1) id xma007939; Mon, 6 Nov 95 15:36:49 -0600 Received: from wales (wales.microware.com) by mcrware.microware.com with SMTP id AA02218 (5.67a8/IDA-1.5); Mon, 6 Nov 1995 15:38:31 -0600 From: Scott McGee Received: by wales id ; Mon, 6 Nov 95 15:38:29 CST Date: Mon, 6 Nov 95 15:38:29 CST Message-Id: <9511062138.AA21692@wales> To: gene@starkhome.cs.sunysb.edu, smcgee@microware.com Subject: Re: interdatabse linking Cc: andersa@mizar.docs.uu.se, genweb@UCSD.EDU Gene writes: >Regarding REFN: Another possibility is to use a NOTE record with a standard, >easily identifiable sequence at the beginning to specify the numbers. Yes, I could make that work, but I hate to think of the time hit a LifeLines database would take with that. I think I would be tempted to require a special database for the genweb stuff where I had converted all REFN's to notes or some other special tag, and then put the ID into a REFN tag, but then again, that is just a technical side issue. Scott When in danger, | If it has my name on it, it must be MY opinion! or in doubt, |______________________________________________________ run in circles, | Email: smcgee@microware.com (Scott McGee) scream and shout! | Web: http://www.cc.utah.edu/~sam8644/homepage.html From list-relay@UCSD.EDU Mon Nov 6 13:51:02 1995 Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id NAA01062 for ; Mon, 6 Nov 1995 13:51:02 -0800 Received: from gate.microware.com (gate.microware.com [198.17.151.51]) by UCSD.EDU (8.6.12/8.6.9) with SMTP id NAA07944 for ; Mon, 6 Nov 1995 13:53:23 -0800 Received: by gate.microware.com; id AA08075; Mon, 6 Nov 95 15:51:07 CST Received: from mcrware.microware.com(192.52.109.32) by gate.microware via smap (g3.0.1) id xma008072; Mon, 6 Nov 95 15:50:43 -0600 Received: from wales (wales.microware.com) by mcrware.microware.com with SMTP id AA02524 (5.67a8/IDA-1.5); Mon, 6 Nov 1995 15:52:26 -0600 From: Scott McGee Received: by wales id ; Mon, 6 Nov 95 15:52:25 CST Date: Mon, 6 Nov 95 15:52:25 CST Message-Id: <9511062152.AA21705@wales> To: andersa@mizar.docs.uu.se, genweb@UCSD.EDU Subject: Re: interdatabse linking Cc: gene@starkhome.cs.sunysb.edu Anders Andersson writes: > >[GenWeb project groups: Resource Identifiers, Engineering] > >Gene Stark writes: >>There are three reference number tags already in the GEDCOM 5.3 draft >>standard: >> +1 RFN {0:M} >> +1 REFN {0:M} >> +1 AFN {0:1} > >>Obviously we cannot use the AFN, since the LDS Ancestral file is using that. > >Agreed. I concure too. >>It would be a bad idea to use the internal cross reference ID's, ("I1011" >>and the like), because genealogical software feels free to assign these. > >I don't quite buy this argument, but I'll defer judgement until I have >more facts. It will obviously take time before off-the-shelf software >can be expected to automatically assign whatever unique identifiers we >come up with here (I don't plan to manually enumerate the individuals >in my database, but I rather expect that to be done in an automated >fashion), so how would we go about using them today? In the cases when >genealogical software assigns cross reference ID's in any manner, can't >they be used as ID's for external cross references as well? The real problem with internal cross reference ID's is that they belong to the genealogy program which is free to change them. Thus, if I save my database to GEDCOM and reload it, internal references may have different values. Also, if I join two people and then add a new person, this person will potentially (and quite likely) end up with the previously used reference ID used by one of the two joined records. >>However, we still have REFN and RFN. What is wrong with REFN? For a number of reasons, I prefer REFN to RFN but as I said in my last post, this is just a technical side issue. If this was all that concerned me, I would have done something by now. >Anyway, I don't think GEDCOM is our primary concern here. When we >discuss GenWeb linking in general, we should anticipate databases >with an internal (unknown) format and an HTML interface without any >GEDCOM involved. Thus we need to define the concept of a stable >person (or record) identifier, and then allow database designers to >implement it in any way they like. When GEDCOM is present, it's a >good idea to map this identifier to a specific GEDCOM tag, but we >should not depend on its existance. Exactly, we need to define within what prameters an ID is unique and what its lifetime is. I think we need to also address the problem of reassigning the same ID's to the same database a second (or more) time around when changes have been made to the database including things like joined individual, deleted individual, new individuals, and modified data for an individual (same for events). Until wide support for genweb ID's is availible in genealogy programs, this will be a big concern! Scott When in danger, | If it has my name on it, it must be MY opinion! or in doubt, |______________________________________________________ run in circles, | Email: smcgee@microware.com (Scott McGee) scream and shout! | Web: http://www.cc.utah.edu/~sam8644/homepage.html From list-relay@UCSD.EDU Mon Nov 6 18:46:05 1995 Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id SAA01786 for ; Mon, 6 Nov 1995 18:46:05 -0800 Received: from yeti.polarnet.fnsb.ak.us (yeti.polarnet.fnsb.ak.us [204.119.24.10]) by UCSD.EDU (8.6.12/8.6.9) with SMTP id SAA04586 for ; Mon, 6 Nov 1995 18:47:53 -0800 Received: from feenix.metronet.com by yeti.polarnet.fnsb.ak.us id aa025891 at Mon, 6 Nov 95 17:47:38 Alaskan Standard Time+0000 Received: from feenix.metronet.com.metronet.com (net222.metronet.com) by metronet.com with SMTP id AA18852 (5.67a/IDA1.5hp); Mon, 6 Nov 1995 20:46:46 -0600 Message-Id: <309EB835.CCC@metronet.com> Date: Mon, 06 Nov 1995 19:36:53 -0600 From: Greg Keller X-Mailer: Mozilla 2.0b1J (Windows; I; 32bit) Mime-Version: 1.0 To: "TODD G. HEBERT" Cc: "genweb@ucsd.edu"@yeti.polarnet.com Subject: Re: help References: <199511052151.NAA26036@UCSD.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailedby: NT SMTP/LISTSERVER v2.10 (ntmail@net-shopper.co.uk) TODD G. HEBERT wrote: > > To whom it may concern. > We need help tracing my indian ancestry with the Cherokee nation. > If you could supply any useful information reguarding this subject please > notify us by our email address. thebert@polarnet.com thanks, > Todd. > Todd, I am also interested in researching my Cherokee ancestors but have no idea where to begin. Let me know if you find any useful info. Thanks, Greg Keller From list-relay@UCSD.EDU Mon Nov 6 19:16:59 1995 Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id TAA01849 for ; Mon, 6 Nov 1995 19:16:59 -0800 Received: from solar.sky.net (solar.sky.net [198.70.175.2]) by UCSD.EDU (8.6.12/8.6.9) with ESMTP id TAA05309 for ; Mon, 6 Nov 1995 19:19:29 -0800 Received: (from jacq@localhost) by solar.sky.net (8.6.12/8.6.12) id VAA09931; Mon, 6 Nov 1995 21:17:42 -0600 Date: Mon, 6 Nov 1995 21:17:41 -0600 (CST) From: Jacques Tucker To: Scott McGee cc: genweb@UCSD.EDU Subject: Re: interdatabse linking In-Reply-To: <9511061858.AA21520@wales> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII What do you do, Scott, when an individual has more than one AFN? From list-relay@UCSD.EDU Mon Nov 6 19:20:44 1995 Received: from UCSD.EDU (mailbox2.ucsd.edu [132.239.1.54]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id TAA01857 for ; Mon, 6 Nov 1995 19:20:44 -0800 Received: from solar.sky.net (solar.sky.net [198.70.175.2]) by UCSD.EDU (8.6.12/8.6.9) with ESMTP id TAA12491 for ; Mon, 6 Nov 1995 19:23:01 -0800 Received: (from jacq@localhost) by solar.sky.net (8.6.12/8.6.12) id VAA10237; Mon, 6 Nov 1995 21:19:46 -0600 Date: Mon, 6 Nov 1995 21:19:45 -0600 (CST) From: Jacques Tucker To: Jack Waller cc: genweb@UCSD.EDU Subject: Re: Forwarded mail.... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII >Can you do something to stop this? No, but the people trying to unsubscribe can. The requests to unsubscribe should be sent to listserv@ucsd.edu, not to genweb. The body of the message should say: unsub genweb In between these two words the e-mail address used to subscribe to genweb should be added if it is different from the "from" address in the message. >---------- Forwarded message ---------- >Date: Mon, 6 Nov 1995 13:57:24 -0400 >From: RLuigi@aol.com >To: GENWEB@ucsd.edu >Subject: Notices >Can someone please tell me why I keep getting copies of other people >subscribing and unsubscribing. Elaine RLUIGI@AOL.COM Yes, people are sending the messages to the mailing list itself instead of to the robot that handles subscribing and unsubscribing, which is listserv@ucsd.edu. Forwarding these messages means they hit the list twice, adding insult t Although unsubscribing is difficult, there is evidence that it is not impossible. A jogger was recently sited on the shores of Mission Bay in San Diego wearing a T-shirt that said: I SUCCESSFULLY UNSUBSCRIBED GENWEB So don't give up. Annelise From list-relay@UCSD.EDU Mon Nov 6 21:47:41 1995 Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id VAA02093 for ; Mon, 6 Nov 1995 21:47:40 -0800 Received: from gate.microware.com (gate.microware.com [198.17.151.51]) by UCSD.EDU (8.6.12/8.6.9) with SMTP id VAA09288 for ; Mon, 6 Nov 1995 21:50:23 -0800 Received: by gate.microware.com; id AA12175; Mon, 6 Nov 95 23:48:24 CST Received: from mcrware.microware.com(192.52.109.32) by gate.microware via smap (g3.0.1) id xma012173; Mon, 6 Nov 95 23:47:54 -0600 Received: from wales (wales.microware.com) by mcrware.microware.com with SMTP id AA14660 (5.67a8/IDA-1.5); Mon, 6 Nov 1995 23:49:37 -0600 From: Scott McGee Received: by wales id ; Mon, 6 Nov 95 23:49:35 CST Date: Mon, 6 Nov 95 23:49:35 CST Message-Id: <9511070549.AA21908@wales> To: jacq@sky.net, smcgee@microware.com Subject: Re: interdatabse linking Cc: genweb@UCSD.EDU Jacques Tucker asks: >What do you do, Scott, when an individual has more than one AFN? Well, I use LifeLines and it lets me do anything I want with the GEDCOM, as long as it is synatatically correct, so I just leave multiple AFN's as is. I beleive this is a violation of the GEDCOM specs (semantics, not syntax) but if I decide I have sufficient cause to merge two individuals with different AFN's, then BOTH AFN's represent the same person. I leave them in to demark slight differences in the data. If you go through my GenWeb stuff, you will find a few people with as many as three AFN's and at least one with five! My GenWeb software should report ALL AFN AFN's for an individual in my database. 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 <------------- From list-relay@UCSD.EDU Tue Nov 7 03:35:32 1995 Received: from UCSD.EDU (mailbox2.ucsd.edu [132.239.1.54]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id DAA04120 for ; Tue, 7 Nov 1995 03:35:31 -0800 Received: from mail.ucsd.edu (ucsd.edu [132.239.1.1]) by UCSD.EDU (8.6.12/8.6.9) with ESMTP id DAA24572 for ; Tue, 7 Nov 1995 03:36:14 -0800 Received: from gw1.att.com by mail.ucsd.edu; id DAA04161 sendmail 8.6.12/UCSD-2.2-sun via SMTP Tue, 7 Nov 1995 03:36:12 -0800 for From: ttw@beltway.att.com (T.T.Wetmore) Received: from beltway (beltway.mv.att.com) by ig1.att.att.com id AA07370; Mon, 6 Nov 95 21:48:44 EST Received: by beltway (4.1/SMI-4.0) id AA19519; Mon, 6 Nov 95 21:49:45 EST Date: Mon, 6 Nov 95 21:49:45 EST Original-From: beltway!ttw (T.T.Wetmore) Message-Id: <9511070249.AA19519@beltway> To: genweb@UCSD.EDU Subject: interdatabase linking Since there has been so much mail on this subject lately I wanted to review the LifeLines approach. LifeLines indexes its databases three ways: 1. By internal key values -- those strings between the @-signs on the INDI, FAM, EVEN, SOUR and other record 0 lines. 2. By all the 1 NAME values found in INDI records. 3. By the values on the 1 REFN lines found on any records. LifeLines treats internal key values as its own. When importing a GEDCOM files LL will change the keys as found on the GEDCOM file to values that LL wants them to have. LifeLines WILL NOT HONOR your internal key values. And even more, LL will not even honor its own internal key values when you export one LifeLines database and import it into another. To put it plainly, the internal keys belong to the genealogical software system, not to the user. On the other hand, LifeLines allows you to put a REFN line in any of your records. The value of this line can be any string at all, with any characters, or any length. It's your personal key for that record. You can then use that value for browsing. LifeLines creates indexes based on these REFN values, so you can search and browse using them very quickly. Unfortunately LL has a few bugs in its REFN handling code now; fixes to those bugs are a number one priority for the next LL version. LifeLines indexes all persons by all their names. The indexing scheme is very good and very fast, and LifeLines users know how convenient the scheme is. You can add other keying conventions to your LifeLines databases. And you can write programs to use those keys anyway you want. However, LifeLines does not provide any way to creates indexes based on these keys, so you have to write your own brute force searching methods using the LifeLines programming language. Someday I may allow you to specificy to LifeLines which tag values you may want to use as keys, but that day is yet to come. Someday I may automatically index all dates and places in a LifeLines database, but that time has not yet come either. Tom Wetmore From list-relay@UCSD.EDU Tue Nov 7 03:36:32 1995 Received: from UCSD.EDU (mailbox2.ucsd.edu [132.239.1.54]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id DAA04126 for ; Tue, 7 Nov 1995 03:36:31 -0800 Received: from wrcd1.urz.uni-wuppertal.de (wrcd1.urz.Uni-Wuppertal.DE [132.195.20.13]) by UCSD.EDU (8.6.12/8.6.9) with SMTP id DAA24601 for ; Tue, 7 Nov 1995 03:37:13 -0800 Received: from wspo04.site.uni-wuppertal.de by wrcd1.urz.uni-wuppertal.de (5.61/1.34) id AA13749; Tue, 7 Nov 95 12:37:29 +0100 Date: Tue, 7 Nov 95 12:37:29 +0100 Message-Id: <9511071137.AA13749@wrcd1.urz.uni-wuppertal.de> X-Sender: wieneke2@wrcd1 X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: genweb@UCSD.EDU From: "Dipl.-Chem. A. Wieneke" Subject: URL's automated Hello there, how do you e.g. T. Doyle or S. McGee generate your URL's ? I'm using "Ancestral Quest (Win)" can I use this Database ? I think it's possible to export the Database as a PAF-File. hopefully A. Wieneke -------------------------------------------------------------------------- Dipl.-Chem. A. Wieneke d.: BUGH-Wuppertal p.:=20 Gausstrasse 20 Corellistrasse 36 D-42119 Wuppertal D-40593 D=FCsseldorf =20 Tel. +49 - 202 - 439 - 32 22 +49 - 211 - 7 39 49 68 FAX +49 - 202 - 439 - 20 68 +49 - 211 - 7 39 49 68 e-mail: wieneke2@wrcs3.urz.uni-wuppertal.de homepage: http://www.uni-wuppertal.de/fachbereiche/FB14/pohl/potitel.html. From list-relay@UCSD.EDU Tue Nov 7 04:08:10 1995 Received: from UCSD.EDU (mailbox2.ucsd.edu [132.239.1.54]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id EAA04159 for ; Tue, 7 Nov 1995 04:08:09 -0800 Received: from faui45.informatik.uni-erlangen.de (faui45.informatik.uni-erlangen.de [131.188.2.45]) by UCSD.EDU (8.6.12/8.6.9) with ESMTP id EAA25336 for ; Tue, 7 Nov 1995 04:10:24 -0800 Received: from immd8.informatik.uni-erlangen.de (root@faui80.informatik.uni-erlangen.de [131.188.38.1]) by uni-erlangen.de with SMTP id NAA19484 (8.6.12/7.4f-FAU); for ; Tue, 7 Nov 1995 13:09:06 +0100 Received: from faui8c by immd8.informatik.uni-erlangen.de; id AA04804 (5.x/7.3w-FAU); Tue, 7 Nov 1995 13:09:04 +0100 From: Herbert Stoyan Message-Id: <9511071209.AA04804@immd8.informatik.uni-erlangen.de> Date: Tue, 7 Nov 1995 13:09:03 +0100 To: genweb@UCSD.EDU Subject: LL and indices X-Sun-Charset: US-ASCII Tom wrote about his usage of records and indexes... Does that mean a person identified by a 1 REFN record is selected in reaction on a getindi-call? One has to know that the getindi-call results in a set of people if one presents a name (one has to select one of them via an interective "i"-response). How do you differentiale between name, key and 1-REFN-value? From list-relay@UCSD.EDU Tue Nov 7 04:11:05 1995 Received: from UCSD.EDU (mailbox2.ucsd.edu [132.239.1.54]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id EAA04165 for ; Tue, 7 Nov 1995 04:11:04 -0800 Received: from misc.twics.com (misc.twics.com [192.135.222.5]) by UCSD.EDU (8.6.12/8.6.9) with ESMTP id EAA25418; Tue, 7 Nov 1995 04:13:57 -0800 Received: from [202.237.148.22] (a22.dial.twics.com) by misc.twics.com with SMTP (1.37.109.16/16.2) id AA171066848; Tue, 7 Nov 1995 21:20:48 +0900 Date: Tue, 7 Nov 1995 21:20:48 +0900 X-Sender: fiorella@twics.com (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Listserv@UCSD.EDU, GENWEB@UCSD.EDU From: fiorella@twics.com (Mike Fiorella) Unsubscribe Mike Fiorella * Japan Market Consulting E-mail: fiorella@twics.com * Multimedia Production Tel/Fax: 81-3-3401-1059 * J-E Translating/Copywriting From list-relay@UCSD.EDU Tue Nov 7 06:37:01 1995 Received: from UCSD.EDU (mailbox2.ucsd.edu [132.239.1.54]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id GAA04307 for ; Tue, 7 Nov 1995 06:37:00 -0800 Received: from gate.microware.com (gate.microware.com [198.17.151.51]) by UCSD.EDU (8.6.12/8.6.9) with SMTP id GAA00231 for ; Tue, 7 Nov 1995 06:38:45 -0800 Received: by gate.microware.com; id AA14384; Tue, 7 Nov 95 08:35:27 CST Received: from mcrware.microware.com(192.52.109.32) by gate.microware via smap (g3.0.1) id xma014382; Tue, 7 Nov 95 08:35:20 -0600 Received: from wales (wales.microware.com) by mcrware.microware.com with SMTP id AA23752 (5.67a8/IDA-1.5); Tue, 7 Nov 1995 08:37:03 -0600 From: Scott McGee Received: by wales id ; Tue, 7 Nov 95 08:37:01 CST Date: Tue, 7 Nov 95 08:37:01 CST Message-Id: <9511071437.AA22088@wales> To: genweb@UCSD.EDU, wieneke2@wrcs3.urz.uni-wuppertal.de Subject: Re: URL's automated "Dipl.-Chem. A. Wieneke" writes: >how do you e.g. T. Doyle or S. McGee generate your URL's ? >I'm using "Ancestral Quest (Win)" can I use this Database ? I think it's >possible to export the Database as a PAF-File. In my case, I load a GEDCOM (if that is how data is supplied) into a LifeLines database (some people already have it that way). This is on a UNIX system with an HTTP server that allows me CGI access (the ability to install my own CGI scripts and programs that the server will run). Basically, my URL's look like: http://www.emcee.com/~smcgee/cgi-bin/DB=/INDEX=/? where is the name of one of my databases, is (currently) the internal key number of a person in that database, and is one of the supported commands which are: LookupInternal - returns indi page based on internal refernce number PedigreeInternal - returns pedigree chart based on internal refernce number DescendantInternal - returns descendant chart based on internal refernce number GEDCOM - return the GEDCOM entry for the person GENDEX - return a GENDEX.txt file for Gene's indexing site (The GENDEX command doesn't use the INDEX= parameter, but I guess you could pass it anyway.) Since all of this works by having the CGI script (genweb.cgi) run LifeLines with a specified report program, and LifeLines isn't generally availible on Windows, I guess it probably wouldn't help you a lot. There IS a version of LifeLines out there that will run on DOS, but I don't know how it would work for this sort of activity. One other way to do it (which I used before this method) is to use Gene Stark's ged2html program to convert a GEDCOM file into numerous HTML files that you can then serve on the web. I have a LifeLines program that will create similar HTML files directly from a LifeLines database. 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 <------------- From list-relay@UCSD.EDU Tue Nov 7 10:52:44 1995 Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id KAA04938 for ; Tue, 7 Nov 1995 10:52:43 -0800 Received: from hoover.stanford.edu (hoover.Stanford.EDU [36.33.0.99]) by UCSD.EDU (8.6.12/8.6.9) with ESMTP id KAA07924 for ; Tue, 7 Nov 1995 10:50:41 -0800 Received: from HOOVER.STANFORD.EDU by HOOVER.STANFORD.EDU (PMDF V4.3-10 #13307) id <01HXCXRGJUXC0031WH@HOOVER.STANFORD.EDU>; Tue, 07 Nov 1995 10:50:09 -0800 (PST) Date: Tue, 07 Nov 1995 10:50:09 -0800 (PST) From: Annelise Anderson Subject: Unsubscribing Genweb To: AlbionSeed@aol.com Cc: genweb@UCSD.EDU Message-id: <01HXCXRGNLYQ0031WH@HOOVER.STANFORD.EDU> X-VMS-To: IN%"AlbionSeed@aol.com" X-VMS-Cc: IN%"genweb@ucsd.edu",ANDRSN MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Here's a copy of a message from Gary Hoffman, who runs this list, on how to unsubscribe: Subj:You are tuned to GenWeb .... The purpose of this list is to facilitate the development of a linked, worldwide distributed genealogy database. If this topic is not of interest to you ...Here is how to unsubscribe: Send an e-mail message to listserv@ucsd.edu In the body of the message put the words: UNSUB GENWEB Do not reply to this message. Do not send these commands to genweb@ucsd.edu. Do not send me a message about unsubscribing. Just do it as outlined above. If you still want to read about the GenWeb, please point your WWW browser to the URL http://demo.genweb.org/genweblist/genweblist.html All current and archived messages are there for your perusal without cluttering your mailbox. Thanks, 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* *************************************************************************** From list-relay@UCSD.EDU Tue Nov 7 13:51:01 1995 Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id NAA05325 for ; Tue, 7 Nov 1995 13:51:01 -0800 Received: from emout06.mail.aol.com (emout06.mail.aol.com [198.81.10.43]) by UCSD.EDU (8.6.12/8.6.9) with ESMTP id NAA00628 for ; Tue, 7 Nov 1995 13:53:58 -0800 From: JohnR238@aol.com Received: by emout06.mail.aol.com (8.6.12/8.6.12) id QAA03676 for genweb@ucsd.edu; Tue, 7 Nov 1995 16:53:55 -0500 Date: Tue, 7 Nov 1995 16:53:55 -0500 Message-ID: <951107165346_81948659@emout06.mail.aol.com> To: genweb@UCSD.EDU Subject: Fwd: interdatabse linking Subj: Re: interdatabse linking Date: 95-11-07 09:48:35 EST From: smcgee@microware.com From: smcgee@microware.com (Scott McGee) To: JohnR238@aol.com First, I would guess that your post was meant for the whole list, but the header makes it look like it was sent to me alone. I did this recently too so I'll include the post at the bottom in case you want to repost to genweb. My reply: The big problem with AFN is that it doesn't belong to us. Meaning that we would be using something that we know beforehand is considered to contain values assigned only by the LDS FHD. For instance, we have absolutely no garuntee that if we assing 47 (for instance) to a given person, that the FHD will not use 47 as an AFN number. It also presents a bad problem if we ever export a database containing these self assigned AFN values. That database may be syntactically incorrect to some software (PAF) which seems to use them for internal refernce values, and would certainly present a problem is such data was submitted back to the FHD with these "AFN"'s in it. Personally, of the tags suggested, REFN looks like it serves best. Like I said though, the actual GEDCOM encoding of these database identifiers is far less important than other issues such as how to reload your site from unencoded source and get the same ID values for the same people. Scott The family that prays together stays together | Scott McGee ---------------------------------------------------+--------------------- email: smcgee@microware.com | What? Me speak web: http://www.cc.utah.edu/~sam8644/homepage.html | for someone else? ---------------------------------------------------+--------------------- The ZION list archives are easily read from the ZION homepage! The URL is http://www.cc.utah.edu/~sam8644/zion.html or http://www.grfn.org/~smcgee/zion.html >From JohnR238@aol.com Tue Nov 7 13:05:22 1995 Date: Tue, 7 Nov 1995 08:05:22 -0500 From: JohnR238@aol.com To: smcgee@microware.com Subject: Re: interdatabse linking As one of the lurkers who read this list religiously, I'd like to jump in here. I've been giving this numbering a lot of thought, but felt I had nothing to contribute til now. I propose that we rally around the AFN and discuss "why it won't work" for our purposes. It seems to me that it is the best that we have to work with, is widely recognized, works with a great number of current records - it beats a YANS (yet another numbering system) hands down. The case of multiple keys identifying a single person can be handled if we plan for it - and we certainly can't avoid the same thing occurring again with YANS due to the nature of our data. John Rigdon Subj: Re: interdatabse linking Date: 95-11-07 09:48:35 EST From: smcgee@microware.com From: smcgee@microware.com (Scott McGee) To: JohnR238@aol.com First, I would guess that your post was meant for the whole list, but the header makes it look like it was sent to me alone. I did this recently too so I'll include the post at the bottom in case you want to repost to genweb. My reply: The big problem with AFN is that it doesn't belong to us. Meaning that we would be using something that we know beforehand is considered to contain values assigned only by the LDS FHD. For instance, we have absolutely no garuntee that if we assing 47 (for instance) to a given person, that the FHD will not use 47 as an AFN number. It also presents a bad problem if we ever export a database containing these self assigned AFN values. That database may be syntactically incorrect to some software (PAF) which seems to use them for internal refernce values, and would certainly present a problem is such data was submitted back to the FHD with these "AFN"'s in it. Personally, of the tags suggested, REFN looks like it serves best. Like I said though, the actual GEDCOM encoding of these database identifiers is far less important than other issues such as how to reload your site from unencoded source and get the same ID values for the same people. Scott The family that prays together stays together | Scott McGee ---------------------------------------------------+--------------------- email: smcgee@microware.com | What? Me speak web: http://www.cc.utah.edu/~sam8644/homepage.html | for someone else? ---------------------------------------------------+--------------------- The ZION list archives are easily read from the ZION homepage! The URL is http://www.cc.utah.edu/~sam8644/zion.html or http://www.grfn.org/~smcgee/zion.html >From JohnR238@aol.com Tue Nov 7 13:05:22 1995 Date: Tue, 7 Nov 1995 08:05:22 -0500 From: JohnR238@aol.com To: smcgee@microware.com Subject: Re: interdatabse linking As one of the lurkers who read this list religiously, I'd like to jump in here. I've been giving this numbering a lot of thought, but felt I had nothing to contribute til now. I propose that we rally around the AFN and discuss "why it won't work" for our purposes. It seems to me that it is the best that we have to work with, is widely recognized, works with a great number of current records - it beats a YANS (yet another numbering system) hands down. The case of multiple keys identifying a single person can be handled if we plan for it - and we certainly can't avoid the same thing occurring again with YANS due to the nature of our data. John Rigdon --------------------- Forwarded message: From: smcgee@microware.com (Scott McGee) To: JohnR238@aol.com Date: 95-11-07 09:48:35 EST First, I would guess that your post was meant for the whole list, but the header makes it look like it was sent to me alone. I did this recently too so I'll include the post at the bottom in case you want to repost to genweb. My reply: The big problem with AFN is that it doesn't belong to us. Meaning that we would be using something that we know beforehand is considered to contain values assigned only by the LDS FHD. For instance, we have absolutely no garuntee that if we assing 47 (for instance) to a given person, that the FHD will not use 47 as an AFN number. It also presents a bad problem if we ever export a database containing these self assigned AFN values. That database may be syntactically incorrect to some software (PAF) which seems to use them for internal refernce values, and would certainly present a problem is such data was submitted back to the FHD with these "AFN"'s in it. Personally, of the tags suggested, REFN looks like it serves best. Like I said though, the actual GEDCOM encoding of these database identifiers is far less important than other issues such as how to reload your site from unencoded source and get the same ID values for the same people. Scott The family that prays together stays together | Scott McGee ---------------------------------------------------+--------------------- email: smcgee@microware.com | What? Me speak web: http://www.cc.utah.edu/~sam8644/homepage.html | for someone else? ---------------------------------------------------+--------------------- The ZION list archives are easily read from the ZION homepage! The URL is http://www.cc.utah.edu/~sam8644/zion.html or http://www.grfn.org/~smcgee/zion.html >From JohnR238@aol.com Tue Nov 7 13:05:22 1995 Date: Tue, 7 Nov 1995 08:05:22 -0500 From: JohnR238@aol.com To: smcgee@microware.com Subject: Re: interdatabse linking As one of the lurkers who read this list religiously, I'd like to jump in here. I've been giving this numbering a lot of thought, but felt I had nothing to contribute til now. I propose that we rally around the AFN and discuss "why it won't work" for our purposes. It seems to me that it is the best that we have to work with, is widely recognized, works with a great number of current records - it beats a YANS (yet another numbering system) hands down. The case of multiple keys identifying a single person can be handled if we plan for it - and we certainly can't avoid the same thing occurring again with YANS due to the nature of our data. John Rigdon From list-relay@UCSD.EDU Tue Nov 7 13:59:35 1995 Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id NAA05362 for ; Tue, 7 Nov 1995 13:59:34 -0800 Received: from mail04.mail.aol.com (mail04.mail.aol.com [152.163.172.53]) by UCSD.EDU (8.6.12/8.6.9) with ESMTP id NAA14848 for ; Tue, 7 Nov 1995 13:33:38 -0800 From: KIMZZZ@aol.com Received: by mail04.mail.aol.com (8.6.12/8.6.12) id QAA03628; Tue, 7 Nov 1995 16:32:19 -0500 Date: Tue, 7 Nov 1995 16:32:19 -0500 Message-ID: <951107163218_15529128@mail04.mail.aol.com> To: mmm@inlink.com, genweb@UCSD.EDU Subject: Re: unsubscribe I agree with Mike. Your subsrcibers should NOT be getting your unscribe mail addressed to genweb. From list-relay@UCSD.EDU Tue Nov 7 16:11:08 1995 Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id QAA05665 for ; Tue, 7 Nov 1995 16:11:07 -0800 Received: from dragon.ti.com (dragon.ti.com [192.94.94.61]) by UCSD.EDU (8.6.12/8.6.9) with ESMTP id QAA07289 for ; Tue, 7 Nov 1995 16:13:49 -0800 Received: from dad_sun.dadd.ti.com ([156.117.138.45]) by dragon.ti.com (8.6.12/) with ESMTP id SAA28767; Tue, 7 Nov 1995 18:13:19 -0600 Received: from mbr (mbr.dadd.ti.com [156.117.138.61]) by dad_sun.dadd.ti.com (8.6.10/8.6.10) with SMTP id SAA03220; Tue, 7 Nov 1995 18:10:12 -0600 Message-Id: <199511080010.SAA03220@dad_sun.dadd.ti.com> Date: Tue, 07 Nov 95 17:10:09 -0500 From: Martin Roberts Organization: Design Automation X-Mailer: Mozilla 1.1 (Windows; U; 16bit) MIME-Version: 1.0 To: jrothgteb@q.continuum.net, genweb@UCSD.EDU Subject: (no subject) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Jim, I looked at your surnames, and just for fun, clicked on the ones I recognize. All of them showed one female with no dates, i.e. Cora Parsons. I don't know the ralation of Cora to you, but if your database is like mine, you show siblings in every generation and who they married if you know it. I have a general question about this with respect to Genweb: Should we make available every name we have in our DB's, or only those we have some confirmation for? I hate to think of all the people who might ask questions about these connections by marriage when I really don't know anything about the person except the name. I have more names like this in my DB than I have names in the direct lines by about a factor of 4! Martin Roberts From list-relay@UCSD.EDU Tue Nov 7 22:16:01 1995 Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id WAA06395 for ; Tue, 7 Nov 1995 22:16:00 -0800 Received: from gate.microware.com (gate.microware.com [198.17.151.51]) by UCSD.EDU (8.6.12/8.6.9) with SMTP id WAA20240 for ; Tue, 7 Nov 1995 22:17:15 -0800 Received: by gate.microware.com; id AA23501; Wed, 8 Nov 95 00:15:10 CST Received: from mcrware.microware.com(192.52.109.32) by gate.microware via smap (g3.0.1) id xma023497; Wed, 8 Nov 95 00:15:02 -0600 Received: from wales (wales.microware.com) by mcrware.microware.com with SMTP id AA19483 (5.67a8/IDA-1.5); Wed, 8 Nov 1995 00:16:45 -0600 From: Scott McGee Received: by wales id ; Wed, 8 Nov 95 00:16:44 CST Date: Wed, 8 Nov 95 00:16:44 CST Message-Id: <9511080616.AA00379@wales> To: genweb@UCSD.EDU, jrothgteb@q.continuum.net, mbr@dadd.ti.com Subject: Re: (no subject) Martin, I would say, yes, show everyone in your datebase on your genweb site. Why, because you should be able to tell by looking at a person if it is one that the DB owner knows much about. If there are 67 Parkers, and one is married to the only Olsen in the database and that person is listed with just a name, there is a VERY GOOD CHANCE that the name is all the owner has. On the other hand, if you have this Olson in your database, the Olsen info isn't enough to tie them together, but the marriage might when you would never have looked without the Olsen being listed. For instance, I have several somewhat extended lines of people who have married a relative of one of my ancestors. I excluded such at first then thought that while someone might share an ancestor, they are more likely to have an ancestor who is related by marriage to my ancestors but we'll never know unless I include them. Scott Scott McGee | I do NOT want to be wo'd unto! -----------------------+--------------------------------------------------- I speak for myself. | email: smcgee@microware.com Your milage may vary! | web: http://www.cc.utah.edu/~sam8644/homepage.html -----------------------+--------------------------------------------------- Visit the ZION list homepage at http://www.cc.utah.edu/~sam8644/zion.html or at the shadow site: http://www.grfn.org/~smcgee/zion.html From list-relay@UCSD.EDU Tue Nov 7 22:30:03 1995 Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id WAA06407 for ; Tue, 7 Nov 1995 22:30:03 -0800 Received: from crash.cts.com (crash.cts.com [192.188.72.17]) by UCSD.EDU (8.6.12/8.6.9) with SMTP id WAA21071 for ; Tue, 7 Nov 1995 22:33:13 -0800 Received: by crash.cts.com (Smail3.1.29.1 #5) id m0tD44I-00008IC; Tue, 7 Nov 95 22:33 PST Date: Tue, 7 Nov 1995 22:33:06 -0800 (PST) From: "V. Turner" To: RLuigi@aol.com cc: GENWEB@UCSD.EDU Subject: Re: Notices In-Reply-To: <951106125724_99256842@emout06.mail.aol.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 6 Nov 1995 RLuigi@aol.com wrote: > Can someone please tell me why I keep getting copies of other people > subscribing and unsubscribing. Elaine RLUIGI@AOL.COM It's the forces way of telling you that you have too much free time. Fondest Woofers, * /\ -V * o---O~ \ / wizards@cts.com * >---/ \ ----------\/~~~~ "Be Resourceful. * * \ \ Be Resiliant. | * //( )____________|| You Are Brilliant." ____|__*|_____//_| |_______ //__||_____ * | * ___|_|____________||__*____|_ | * =====================|========= "In the Fall, Puppies Are Skiing In The Dandilions" From list-relay@UCSD.EDU Tue Nov 7 23:31:58 1995 Received: from UCSD.EDU (mailbox2.ucsd.edu [132.239.1.54]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id XAA06475 for ; Tue, 7 Nov 1995 23:31:57 -0800 Received: from crash.cts.com (crash.cts.com [192.188.72.17]) by UCSD.EDU (8.6.12/8.6.9) with SMTP id XAA07973 for ; Tue, 7 Nov 1995 23:31:20 -0800 Received: by crash.cts.com (Smail3.1.29.1 #5) id m0tD4yD-0000D7C; Tue, 7 Nov 95 23:30 PST Date: Tue, 7 Nov 1995 23:30:52 -0800 (PST) From: "V. Turner" To: Jacques Tucker cc: Jack Waller , genweb@UCSD.EDU Subject: Re: Forwarded mail.... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 6 Nov 1995, Jacques Tucker wrote: > On Mon, 6 Nov 1995, Jack Waller wrote: > > Another one! > > ---------- Forwarded message ---------- > > Date: Mon, 6 Nov 1995 12:37:40 -0400 > > From: BILL C HARRISON > > To: genweb@ucsd.edu > > Subject: > > unsubscribe > Com'on, Jack!?! It's bad enough I must delete the original ignorant > unsubscribe message. There's no need to propagate 'em. . > I believe these unsubscribe messages self-clone, like worms. Incidentally, I also believe it is possible to set up a screen on the server to catch the "unsubscribe" word and reflect the message back to the sender, along with instructions on how to do the thing correctly. But where would be the fun in *that*? Love from a lurker... Fondest Woofers, * /\ -V * o---O~ \ / wizards@cts.com * >---/ \ ----------\/~~~~ "Be Resourceful. * * \ \ Be Resiliant. | * //( )____________|| You Are Brilliant." ____|__*|_____//_| |_______ //__||_____ * | * ___|_|____________||__*____|_ | * =====================|========= "In the Fall, Puppies Are Skiing In The Dandilions" From list-relay@UCSD.EDU Wed Nov 8 02:42:08 1995 Received: from UCSD.EDU (mailbox2.ucsd.edu [132.239.1.54]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id CAA08379 for ; Wed, 8 Nov 1995 02:42:07 -0800 Received: from Mizar.DoCS.UU.SE (Mizar.DoCS.UU.SE [130.238.11.21]) by UCSD.EDU (8.6.12/8.6.9) with SMTP id CAA12293 for ; Wed, 8 Nov 1995 02:44:43 -0800 Received: by Mizar.DoCS.UU.SE (Sun-4/260, SunOS 4.0) with sendmail 5.61-bind 1.5+ida/ICU/DoCS/mizar id AA01373; Wed, 8 Nov 95 11:44:39 +0100 Date: Wed, 8 Nov 95 11:44:39 +0100 From: Anders Andersson Message-Id: <9511081044.AA01373@Mizar.DoCS.UU.SE> To: genweb@UCSD.EDU Subject: Re: (no subject) Cc: jrothgteb@q.continuum.net, mbr@dadd.ti.com [GenWeb project groups: Information Quality, User Interfaces] Martin Roberts writes: >Should we make available every name we have in our DB's, or only those we >have some confirmation for? I hate to think of all the people who might >ask questions about these connections by marriage when I really don't >know anything about the person except the name. I have more names like >this in my DB than I have names in the direct lines by about a factor >of 4! Scenario #1: I have 4,711 persons in my database, but for various reasons (such as lack of reasonable confirmation) I leave out maybe 100 of them from what I make available on the WWW. I state this fact clearly in the introductory description of the database. Probable result: Just about every user who fails to find the information they suspect that I might have will send me a message asking me to check for a match *manually*. I'll have to hire a secretary to answer my mail. Scenario #2: I have 4,711 persons in my database, but for various reasons (such as lack of reasonable confirmation) I leave out maybe 100 of them from what I make available on the WWW. I make no mention of this, but rather pretend that I only know about 4,611 persons. Probable result: Just about every user who fails to find the information they suspect that I might have will send me a message asking me to check for a match *manually*, since they have learned elsewhere that people have a habit of not making all their information available on the WWW, but hiding part of it in their digital closet. Either way, I'll lose... ;-) Actually, I'm not speaking from my own experience, but from that of others. You may want to learn what Rob Hartill thinks about answering movie trivia questions. Seriously: I think the best way is to make available any and all information you have that you wouldn't hesitate to provide upon a direct request. Just like it's a bad idea to teach people that they can send robot commands to a mailing list, it's a bad idea to teach them that as a general rule they can obtain additional information by sending mail to somebody who just may have a 1 MB daily intake of junk mail. -- 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 From list-relay@UCSD.EDU Wed Nov 8 12:26:09 1995 Received: from UCSD.EDU (mailbox2.ucsd.edu [132.239.1.54]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id MAA09229 for ; Wed, 8 Nov 1995 12:26:09 -0800 Received: from dragon.ti.com (dragon.ti.com [192.94.94.61]) by UCSD.EDU (8.6.12/8.6.9) with ESMTP id LAA27198 for ; Wed, 8 Nov 1995 11:57:04 -0800 Received: from tilde.csc.ti.com ([128.247.160.56]) by dragon.ti.com (8.6.12/) with ESMTP id NAA04701; Wed, 8 Nov 1995 13:56:25 -0600 Received: from ticipa.Works.Ti.Com (ticipa.works.ti.com [128.247.112.8]) by tilde.csc.ti.com (8.7.1/8.7.1) with SMTP id NAA01427; Wed, 8 Nov 1995 13:56:18 -0600 (CST) Received: from census.works.ti.com by ticipa.Works.Ti.Com with SMTP id AA13045 (5.65c/IDA-1.4.4); Wed, 8 Nov 1995 13:55:52 -0600 Received: by census.Works.Ti.Com (5.x/SMI-SVR4) id AA08353; Wed, 8 Nov 1995 13:55:51 -0600 Date: Wed, 8 Nov 1995 13:55:51 -0600 From: steele@ticipa.Works.ti.com (Jeri Steele) Message-Id: <9511081955.AA08353@census.Works.Ti.Com> To: GEDCOM-L@vm1.nodak.edu, GENWEB@UCSD.EDU Cc: finleyc@sonoma.edu, steele@census.works.ti.com Subject: more about MARC Reply-To: steele@census.works.ti.com >On 2 Nov 95 at 14:34, Jeri Steele wrote: > >> If others start to do such projects, we may well see software >> programs output MARC format files too! > >Trevor wrote: > >Oh I hope not. :-| MARC is one of the most perversely defined >machine readable formats there is. As it is machine readable I reckon >machines defined it and machines should be made to use it. I have >had to write several MARC conversion programs in the last few years >and the thought of anyone replacing GEDCOM with MARC is enough to >make me give up. > >GEDCOM's virtue, if it has any, is that is is humanly readable. You >can pull a GEDCOM file into your favorite text editor and view as >it is and, if necessary, amend it. With MARC you have to write a >specific viewing program to look at the data and to modify the data. > > I agree its nice to have the ascii form to edit and view if we have to go into a GEDCOM file and modify the information. However, I brought up MARC not as a perfect example but one that presents a new way of handling information. Here's a couple of the problems I have had with GEDCOM as a format: 1) By expressing all information in terms of people, dates, and relationships we are showing the RESULTS of our genealogy research. 2) There is no complete way to exchange source level information via GEDCOM. (Not just a footnote or bibliographic citation, but complete source analysis!) I brought up the MARC format as an example of how to get SOURCE information into a form that can be shared with others and viewed on the WWW. For example, take a copy of the Probate Minutes on a specific case: The 'core' information can be abstracted, notes made about the readability and accuracy of the information and its recorder. Then we can infer additional information when we analyze this information in conjunction with previous research AND in light of a particular research goal. We will probably extract death and relationship information from the probate document. But are you trying to prove a parent relationship, the marriage event, or the death event? With GEDCOM we are automatically thinking in terms of people, dates and places. With some system like MARC we would be emphasizing the abstraction of the sources first. (Then recording notes, drawing conclusions, and finally recording the actual and inferred information to be charted and displayed.) If we exchange source information, notes, AND conclusions this is recording more of the genealogy research process. If we were to start over designing an exchange format today with the premise that abstracting and analyzing source information is the MOST important part of the process, would it look like GEDCOM ? Should we think about source information analysis data exchange as a different problem covered by different exchange formats rather than using GEDCOM to express this information? I currently use genealogy software to record the above information. However, I find myself having to attach source analysis information in notes, having to pull reports on all events utilizing one source, and attaching research tasks to sources in order to take this 'source analysis' view. In reality, I am only viewing the information from an event that I have concluded occurred at a particular place, time and with certain people participating. I am not recording pure source information that can be passed on so that others can draw their own conclusions. This isn't a limitation of of the program but in how GEDCOM and genealogy programs are 'slanted' right now. Yes, I can attach files that transcribe the documents or record my abstraction notes. I want more. If I examine and abstract 20 deeds in order to solve one of my genealogy problems, how do I exchange that information with others? They may want to use the same abstracts to make a different conclusion (They maybe looking at a different family for instance). Is this a different genealogy application that doesn't exist in the software market? Maybe a different view on the source data recorded in GEDCOM is a solution? Carmen Finley's example of using MARC gives the GEDCOM and GENWEB community some exposure and exploration at dissseminating source information. I can't be the only 'serious' genealogist that has been frustrated by a lack of a 'standard' way to share this source information! Jeri Steele (steele@metronet.com evenings & weekends) From list-relay@UCSD.EDU Wed Nov 8 14:04:10 1995 Received: from UCSD.EDU (mailbox2.ucsd.edu [132.239.1.54]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id OAA09528 for ; Wed, 8 Nov 1995 14:04:08 -0800 Received: from dragon.ti.com (dragon.ti.com [192.94.94.61]) by UCSD.EDU (8.6.12/8.6.9) with ESMTP id NAA02433 for ; Wed, 8 Nov 1995 13:58:26 -0800 Received: from dad_sun.dadd.ti.com ([156.117.138.45]) by dragon.ti.com (8.6.12/) with ESMTP id PAA04172; Wed, 8 Nov 1995 15:57:57 -0600 Received: from 156.117.138.61 (mbr.dadd.ti.com [156.117.138.61]) by dad_sun.dadd.ti.com (8.6.10/8.6.10) with SMTP id PAA03087; Wed, 8 Nov 1995 15:54:43 -0600 To: Scott McGee From: mbr@dadd.ti.com (Martin Roberts) Subject: Re: (no subject) Date: Wed, 8 Nov 1995 14:54:46 cc: genweb@UCSD.EDU Message-ID: In article Scott McGee writes: >Martin, >I would say, yes, show everyone in your datebase on your genweb site. Why, >because you should be able to tell by looking at a person if it is one >that the DB owner knows much about. If there are 67 Parkers, and one is >married to the only Olsen in the database and that person is listed with >just a name, there is a VERY GOOD CHANCE that the name is all the owner >has. On the other hand, if you have this Olson in your database, the Olsen >info isn't enough to tie them together, but the marriage might when you >would never have looked without the Olsen being listed. >For instance, I have several somewhat extended lines of people who have >married a relative of one of my ancestors. I excluded such at first then >thought that while someone might share an ancestor, they are more likely >to have an ancestor who is related by marriage to my ancestors but we'll >never know unless I include them. Scott, what worries me is all you clever programmers. When you have all the web connected, you or someone else will offer an automated name search. Next there would be automated email questions. Thats the time that worries me. If I have a Smith in my DB without dates (because I don't know them) and there is an automated mail submitting search, then I would expect one request per Smith genealogist ww that I would have to individually respond to. Maybe if someone provides an automated answerer for automated questions, it would be safe. But I think automating the question is a lot easier that automating an answer. Yesterday I posted something elsewhere that had the surname Mather in it. Today I got a question from someone in England asking me about Mathers. Anders has 4000 names. Currently there are 3-4 million people on Usenet. Suppose 10% of them lurk in genealogy groups. What are the odds of getting a reply to a name post for Anders today? How will the demand grow in the future if there are automated search programs? Maybe you guys have more time than I to answer email, but it look like a problem to me. Technology is wonderful, but we need to forecast how it will be used, not just invent it. Martin From list-relay@UCSD.EDU Wed Nov 8 17:10:30 1995 Received: from UCSD.EDU (mailbox2.ucsd.edu [132.239.1.54]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id RAA09819 for ; Wed, 8 Nov 1995 17:10:30 -0800 Received: from UConnVM.UConn.Edu (uconnvm.uconn.edu [137.99.26.3]) by UCSD.EDU (8.6.12/8.6.9) with SMTP id RAA11108 for ; Wed, 8 Nov 1995 17:09:47 -0800 Message-Id: <199511090109.RAA11108@UCSD.EDU> Received: from ppp02p05.ucc.uconn.edu by UConnVM.UConn.Edu (IBM VM SMTP V2R2) with TCP; Wed, 08 Nov 95 20:09:31 EST Comments: Authenticated sender is From: "George Waller" To: genweb@UCSD.EDU Date: Wed, 8 Nov 1995 20:10:35 -0400 Subject: Technology is wonderful Reply-to: gwaller@lib.uconn.edu Priority: normal X-mailer: Pegasus Mail for Windows (v2.01) On 8 Nov 95 at 14:54, Martin Roberts wrote: (snip) > Maybe you guys have more time than I to answer email, but it look like > a problem to me. Technology is wonderful, but we need to forecast how it > will be used, not just invent it. Those darn "you guys" ... aren't they the root of all our problems ? Seriously, those darn you guys are intelligent enough to handle the simple problems you mentioned. --George * George Waller, Univ of Connecticut, hbladm1@uconnvm.uconn.edu From list-relay@UCSD.EDU Wed Nov 8 17:55:51 1995 Received: from UCSD.EDU (mailbox1.ucsd.edu [132.239.1.53]) by fuji.ucsd.edu (8.6.9/8.6.9) with ESMTP id RAA09909 for ; Wed, 8 Nov 1995 17:55:50 -0800 Received: from Mizar.DoCS.UU.SE (Mizar.DoCS.UU.SE [130.238.11.21]) by UCSD.EDU (8.6.12/8.6.9) with SMTP id RAA28070 for ; Wed, 8 Nov 1995 17:57:12 -0800 Received: by Mizar.DoCS.UU.SE (Sun-4/260, SunOS 4.0) with sendmail 5.61-bind 1.5+ida/ICU/DoCS/mizar id AA13058; Thu, 9 Nov 95 02:57:07 +0100 Date: Thu, 9 Nov 95 02:57:07 +0100 From: Anders Andersson Message-Id: <9511090157.AA13058@Mizar.DoCS.UU.SE> To: mbr@dadd.ti.com Subject: Re: (no subject) Cc: genweb@UCSD.EDU Martin Roberts writes: >Yesterday I posted something elsewhere that had the surname Mather in it. >Today I got a question from someone in England asking me about Mathers. >Anders has 4000 names. Currently there are 3-4 million people on Usenet. Let me clarify that the figure I mentioned was an entirely hypothetical example, for the purpose of outlining two possible scenarios. I have no database of 4,000 names. >Suppose 10% of them lurk in genealogy groups. What are the odds of getting >a reply to a name post for Anders today? How will the demand grow in the >future if there are automated search programs? Maybe you are familiar with the ROOTS Surname List, where people doing research on the same family names can get in contact with each other? I have only submitted two surnames to that list, and none of them is "Andersson", for precisely the reason you mention. Statistically speaking, I'd say there may be some 250,000 people in Sweden bearing this name, but I estimate that at most 200 of them have inherited the name from my great-great grandfather. I'm no more related to the other Andersson's than to anyone else. I believe it's like "Smith" in the English-speaking world. Thus, I'd not be particularly interested in people sending me mail just to check whether I'm related to some other Andersson. Fortunately, this has happened only 2-3 times so far. >Maybe you guys have more time than I to answer email, but it look like >a problem to me. Technology is wonderful, but we need to forecast how it >will be used, not just invent it. I'm a Unix system manager receiving on the average 50-100 messages per day; a lot of it is easily deleted as junk, though. I certainly don't have the time needed to answer every message I'd like to, so I do share your conservatism in this respect. However, it's interesting that we arrive at entirely different conclusions, given our similar reasoning. I say "publish everything" because I want to send the message that either the information is available on the net, or it isn't available at all. You say "publish only reliable information", but I fail to see how this is going to prevent you from getting numerous questions about your non-published stuff (by "publish" I here of course refer to the act of making the information available on the Internet, not to the sale of printed books). I don't think the size of your "published" database makes that much of a difference. The key to a jammed mailbox is getting your material indexed in a popular index, which means that the number of *unique* names is probably a significant factor. You may want to exclude from the index records which are too easy to match, such as a truckload of Smith's. However, not making the data about the Smith's available to the net at all seems contradictory to the GenWeb idea. We agree on the risk of human (and perhaps network) overload, but we appearantly disagree on the best way to counter it. -- 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