On Sun, 29 May 2011 17:05:26 +0100, "Harrison Genealogy" <[email protected]> wrote: >Steve > >Yes it will ... I give all those persons I've identified a Personal >Reference No and then just do a search for that unique number. But a person is not the same thing as an event. You are not your best friend's 21st birthday party, even if you were present at it. -- Steve Hayes from Tshwane, South Africa Web: http://hayesfam.bravehost.com/stevesig.htm Blog: http://methodius.blogspot.com E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 29 May 2011 16:23, Ian Goddard ([email protected]) opined: > Bob Melson wrote: >> On Sunday 29 May 2011 09:57, Ian Goddard ([email protected]) >> opined: >> >>> Bob Melson wrote: >>>> Y'all'd have to check the archives for the down'n'dirty, but Wes and I >>>> and I don't remember who all else had a discussion of this very thing >>>> (_UID, >>>> _UUID, _GUID) some time back. I contended then that UUID (Universal >>>> Unique ID) and it's close kin, UID and GUID, meant that the number >>>> assigned to Cousin Mortimer should be the same universally - here, >>>> there, >>>> wherever it appears. Not so. The "universe" is the machine where the >> >> My original (erroneous?) contention was that identical data should >> result in identical UUIDs irrespective of where generated, so that >> Cousin Mortimer's record will produce the same UUID whether done on your >> machine >> or mine or somebody else's. As Wes pointed out, this effectively >> describes a checksum and, in honesty, I have to admit that that's very >> much how I conceptualized *IDs. >> >> It appears, however, that Cousin Mortimer's record will result in a >> unique ID on every machine on which a *ID is generated, so for N copies >> of the >> record on N machines there will be N unique identifiers. And that >> raises a question about the utility of those identifiers - if every one >> is unique, how do/can we know that they refer to the same record? >> >> The other component of my now thoroughly beaten-down original belief was >> that the *IDs were somehow akin to a digital signature, on the order >> of "none genuine without this ID". Assuming _that_ and that I've >> published my public key, anybody coming across ol' Mort's record >> anywhere could verify (1) that it came from me and (2) whether it's >> identical with >> the original. That obviously won't work with *IDs as they are at >> present. (Still, I find the idea of a per record digital signature >> attractive, tho' that's an entirely different topic for discussion). >> > > So someone transcribes a record of ol' Mort & writes out his surname > with a capitalised initial because that's what's in the original and > someone else transcribes the same record exactly except that they give > the surname in upper case because that's the convention they adopt. > Oops! Different checksums. > > Another example. Older church registers tend to have headings for year > and month (or a page heading for year with intermediate headings for > month) and just the day of month on a per record. So the transcriber > has to make up his own way of representing dates which might differ from > transcriber to transcriber so again ol' Mort could get his name > transcribed using the same convention but get the dates represented > differently. Again, different checksums. > > So the checksumming depends not only on the data but also on the way it > was transcribed. And of course, different representations could be > imposed by the S/W which might insist on upper-case surnames or > different date formats. You're quite right and that's why I early on, well early, well abandoned the idea that the *IDs were in some way a super-checksum. > > I think there are two separate issues. One is the unambiguous > identification of the same publication and the other is its > authentication. And, indeed, they are. Recognizing that, however, took a bit of time because of my failure to grasp the *ID "concept". I knew what I wanted and expected *IDs to be and that was not at all what they are in the real world. > > The latter is the more difficult. Not only are there the sort of > problems I've outlined above but also the problem of maintaining a PKI > (public key infrastructure). The PKI is already there, as just about everybody who uses SSH will tell you. The problem is not the PKI but the chain of trust involved. Ideally, my key will have been validated as to its trustworthiness by somebody who already has a trusted key and who knows me, this before I submit my key to the "registry". Finding somebody to sign your newly generated key with his already signed/trusted key can be a real PITA. > > When I suggested what was, in effect, a distributed database using > exchanges of UUID-labeled XML records I considered the possibility of > digital signing. On balance I decided to leave it out as: > > 1. XML introduces even more variations. Consider, for example; > > <EmptyTag></EmptyTag> > <EmptyTag/> > > both of which are equivalent but will checksum differently. And so? I don't see a problem here WRT digital signatures. > > 2. The PKI would also have to be distributed. Moot. See above. > > 3. If someone did decide to massage a record they could simply re-sign > it with their own private key so the advantages could be illusory. Yep. But with that signed record you'd be able to determine who it was who made the modification - or merely re-signed the record. There's no doubt that there are problems with the idea of digitally signing a record/persona, not least how you'd go about handling the person who can't be bothered to obtain the appropriate software, generate and validate a key pair, or out of pure don't-give-a-damn contrariness signs nothing he throws into the genealogy pool. Those we'll always have with us, I suspect. The advantage of digital signing, as I see it, is that if I sign a record and either publish it or send it directly to you, you can easily verify that it _did_ come from me and, based on whether you trust my research and conclusions can decide whether to accept it or not. Conversely, if you receive or find something purporting to come from me but the signature check fails, you have reason to question the data - it's been changed in some unknown way. What can't be controlled is the case in which Snively Whiplash copies my information, deletes the signature and resigns the otherwise unchanged information with his own key, claiming it as his own. That's already a problem, of course, for which there's no ready solution. Bob - -- Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas - ----- The greatest tyrannies are always perpetrated in the name of the noblest causes -- Thomas Paine -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iEYEARECAAYFAk3i0/4ACgkQGX60pjRVDrPl2wCfbLGOaQHuIP7hc4Tf9G45fnRn rTkAn3Jqq0x6KMz/bWOixbhn+dNV9blQ =DRW+ -----END PGP SIGNATURE-----

Steve Yes it will ... I give all those persons I've identified a Personal Reference No and then just do a search for that unique number. Also you can search and select on any one or as many fields as you want to. I suggest you download and use the demo version and see for yourself its capabilities. Regards Bill -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Steve Hayes Sent: 28 May 2011 06:31 To: [email protected] Subject: Re: Event-based database software for historians, biographers and genealogists - redux On Fri, 27 May 2011 18:15:36 +0100, "Harrison Genealogy" <[email protected]> wrote: >Steve > >Also the following has appeared in the Custodian Forum.... > ><Snip> > >Currently, Custodian builds Indexes for Name and Place. I use User Field 1 >to keep my paper filing reference in. But will it produce a list of EVENTS sorted by date? And a list of the events that a particular person was involved in in ant capacity? Or the events related to a particular organisation? -- Steve Hayes from Tshwane, South Africa Web: http://hayesfam.bravehost.com/stevesig.htm Blog: http://methodius.blogspot.com E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk ------------------------------- To unsubscribe from the list, please send an email to [email protected] with the word 'unsubscribe' without the quotes in the subject and the body of the message

Bob Melson wrote: > Y'all'd have to check the archives for the down'n'dirty, but Wes and I and > I don't remember who all else had a discussion of this very thing (_UID, > _UUID, _GUID) some time back. I contended then that UUID (Universal > Unique ID) and it's close kin, UID and GUID, meant that the number > assigned to Cousin Mortimer should be the same universally - here, there, > wherever it appears. Not so. The "universe" is the machine where the > data appears and on which the software resides by which the UUID is > generated and it's only there that it's guaranteed to be unique. I think you were right the first time providing the relevant standards are being followed. See the discussion at http://en.wikipedia.org/wiki/Universally_Unique_Identifier Clearly any use of UUIDs would have to mandate the most recent standard, listed there, ITU-T Rec. X.667 | ISO/IEC 9834-8, or its successors. -- Ian The Hotmail address is my spam-bin. Real mail address is iang at austonley org uk

singhals wrote: > > WHY would I want to keep them separate once I've decided they're the > same person? My bc, my mc, and my son's bc all refer to ME as ME; what > would be the POINT of keeping ME in there 3 times? This is the crux of the problem. Your certs all have a /name/ on them. Those or just that, names. The names are not /you/. They point to you but they are an entirely different type of entity (or object or thing or whatever term you wish to use) in reality and therefore really should be represented by different types of entity in a database. So you don't have /you/ in there three times, you have /you/ in there once, each of the /names/ from the three certs in there once each and three /links/ between the names and you. Now you might think this is overkill because the names are all the same (assuming the name on your son's bc is your maiden name because if not you have two variants there already). But if so this is just one possibility. At the other extreme I have an ancestor whose surname was, in the current dominant spelling hereabouts, Dearnley but in the past varied quite a bit and whose first name was rendered so variably that I have no idea what it was supposed to be as it goes from Hammond to Amon and most points in between. So it makes a lot of sense to have a single point where you can standardise the name and link all the variants to it. It also makes a lot of sense to be able to attach some sort of epithet to disambiguate people of the same name such as my run of 4 William Goddards. -- Ian The Hotmail address is my spam-bin. Real mail address is iang at austonley org uk

On Sunday 29 May 2011 09:57, Ian Goddard ([email protected]) opined: > Bob Melson wrote: >> Y'all'd have to check the archives for the down'n'dirty, but Wes and I >> and I don't remember who all else had a discussion of this very thing >> (_UID, >> _UUID, _GUID) some time back. I contended then that UUID (Universal >> Unique ID) and it's close kin, UID and GUID, meant that the number >> assigned to Cousin Mortimer should be the same universally - here, >> there, >> wherever it appears. Not so. The "universe" is the machine where the My original (erroneous?) contention was that identical data should result in identical UUIDs irrespective of where generated, so that Cousin Mortimer's record will produce the same UUID whether done on your machine or mine or somebody else's. As Wes pointed out, this effectively describes a checksum and, in honesty, I have to admit that that's very much how I conceptualized *IDs. It appears, however, that Cousin Mortimer's record will result in a unique ID on every machine on which a *ID is generated, so for N copies of the record on N machines there will be N unique identifiers. And that raises a question about the utility of those identifiers - if every one is unique, how do/can we know that they refer to the same record? The other component of my now thoroughly beaten-down original belief was that the *IDs were somehow akin to a digital signature, on the order of "none genuine without this ID". Assuming _that_ and that I've published my public key, anybody coming across ol' Mort's record anywhere could verify (1) that it came from me and (2) whether it's identical with the original. That obviously won't work with *IDs as they are at present. (Still, I find the idea of a per record digital signature attractive, tho' that's an entirely different topic for discussion). >> data appears and on which the software resides by which the UUID is >> generated and it's only there that it's guaranteed to be unique. > > I think you were right the first time providing the relevant standards > are being followed. See the discussion at > http://en.wikipedia.org/wiki/Universally_Unique_Identifier > > Clearly any use of UUIDs would have to mandate the most recent standard, > listed there, ITU-T Rec. X.667 | ISO/IEC 9834-8, or its successors. > Steamin' Ol' Bob (115 days without precip) -- Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas ----- The greatest tyrannies are always perpetrated in the name of the noblest causes -- Thomas Paine

Tom > > Cheryl > > I should think we are all always in the realm of person-based genealogy... You may need to review what is meant by record-based genealogy. I described it quite well in the intro post. > it seems to me that more-than-one of the participants is suggesting > we can NEVER be certain that recordA about Tom Wetmore > refers to the same Tom Wetmore as recordB. How the > researcher stores, organizes, accesses, or displays either > record won't change that. That makes HOW to store, > organize, access, or display sort of like nailing Jello to > the wall: certainly do-able if you work hard enough, but > just as certainly futile in the long run. I don't understand how the inherent uncertainty of genealogical records has any bearing on the need to record information or on how to construct with gelatin. > As someone famous once said, now there you go again. ALL genealogy is > record-based ... Again, it would be helpful if you learned what the terms mean. > It's very difficult to follow about persona vs person > sometimes. Evidence does not exist in a vacuum any more > than people do. IF there's people, there's evidence; one > can always remove references to evidence if one can > conclusively prove it's irrelevant. IME, though, if I don't > SAY I looked hither, thither and yon, someone will suggest I > missed thither. So putting it in and then debunking it is > easier on my nerves. To debunk it, I need to attach it to > who it might but doesn't concern. You are describing an awkward way to handle a record-based problem in a person-based paradigm. Are you suggesting that your persons records should contain information about every record you have considered and decided wasn't that person? As a way of remembering that you have considered that record? Why not let that record stand on its own as a persona record that has yet to be attached to a person? > > Wouldn't you want all that evidence information codified somehow inside > > your genealogy program so you can search for names, search for dates, > > search for > > places, see the relationships mentioned in the evidence, > > and so on? How would you want your genealogy application to support you > > after you have "crossed the chasm?" > No. I want all that evidence raw if I need to re-evaluate > it. I don't want it filtered, as it will be by extracting > bits of it to codify. As someone mentioned, the bit you > don't extract may be the only important bit in there. And > creating a database for the purpose of comparing documents > when the documents to be compared are NOT identical in > content is going to drag AI into it; I'm not up to speed on > the current state of AI, but I know as recently as Y2K, it > couldn't make the same sort of judgments a people can > because people STILL use unconscious, subconscious, and even > subliminal info in analysis. Did you think about the example of having 100s of records that might apply to people you are looking for, and you haven't been able to decide who they are yet (this IS record-based genealogy by the way)? Eventually you will reach that point in your own work, and when you do you will need to take some steps to help you better organize, access, and understand the evidence you have collected. Only by having that data in some codified form will you be able to work effectively. The whole point of this thread is to try to get people who have reached this point to describe how they handle the situation now, and how they might like a genealogical program to help them. There have now been many posts on this thread by people who have reached that point and have given some very good advice as to how to handle it. If you think you must refer back to the original evidence every time you need to reconsider a fact from any of those 100s of records you will have great difficulty getting anything done. Tom

On 05-28-2011 16:16, Bob Melson wrote: > As matters stand, I'll likely continue to let pGV create _UUIDs by default > and continue to piss'n'moan (c) about their utility or lack thereof. I set it so that they aren't shown to non-admins. Then I finally turned them off completely. No new ones, but the old ones are still there. I also switched to webtrees. It's faster. -- Wes Groleau There are two types of people in the world … http://Ideas.Lang-Learn.us/barrett?itemid=1157

On 05-28-2011 00:57, Bob Melson wrote: >> (me): >> > new UUID when the item ceases to be a copy of the other. That, in my >>>>>>_opinion_makes_them_useless_for_genealogy_. But they were never intended >> > to be some magic way of automatically identifying independently >> > generated records as being representations of the same entity. > Then why bother with 'em? I don't know. Why? -- Wes Groleau There are two types of people in the world … http://Ideas.Lang-Learn.us/barrett?itemid=1157

Richard Smith wrote: > On May 28, 3:51 pm, singhals<[email protected]> wrote: > >> AIUI at the time -- they were intended to be used in a >> multi-person data-entry/research project which has a >> master/main/official database. The database "keeper" to use >> Legacy's term, shares the GED from that database with all >> researchers, who can modify or extend the data as they see >> fit before returning it to the "keeper". The "keeper" then >> uses the UIDs to find who changed or added what, without >> having to plod line by line through either the GED or the >> database. > > That may have been the intention, but there's no reason to suppose it > will actually work in practice. The _UID GEDCOM tag is not Seems to have worked for more than one person in the past; if all parties are using the SAME genie program which is designed to do what I've quoted, there's no reason it wouldn't work in practice. Can't say I've tested it because I'm a selfish little blonde and I don't give away my work anymore. I got tired of passing on 8 generations and getting ONE birthdate in return. > standardised. There may be a convention among programs understanding > _UID that they should changed the UID whenever they change the > associated data. But there's no reason to suppose an application that > does not understand _UID will do that. When confronted with a GEDCOM > tag it doesn't understand, some applications will simply preserve it > intact. Any such application will then permit the modification of the > data without changing the value of the corresponding _UID tag. Well, no, but then there's no supposing an app that doesn't understand them will advocate using them, either, anymore than there's a reason to suppose an app that doesn't understand the concept of "born to X clan for Y clan" will do a good job of recording it...or that a genie app that doesn't admit that hermaphrodites exist will handle those persons properly. Nothing is perfect. Cheryl

On Saturday 28 May 2011 13:40, Wes Groleau ([email protected]) opined: > On 05-28-2011 00:57, Bob Melson wrote: > >> (me): >>> > new UUID when the item ceases to be a copy of the other. That, in >>> > my >>>>>>>_opinion_makes_them_useless_for_genealogy_. But they were never >>>>>>>intended >>> > to be some magic way of automatically identifying independently >>> > generated records as being representations of the same entity. >> Then why bother with 'em? > > I don't know. Why? Sounds like one of the unanswered questions of the Universe, kinda like "how many uses ARE there for Velveeta?" or "is there ALWAYS room for Jell-o?" (You remember the Tim Kazurinski (sp?) bit on SNL where he played Avnugoodtime Vishnuverehere?) As matters stand, I'll likely continue to let pGV create _UUIDs by default and continue to piss'n'moan (c) about their utility or lack thereof. Scorchin' Ol' Bob 114 days with no precip -- Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas ----- The greatest tyrannies are always perpetrated in the name of the noblest causes -- Thomas Paine

Tom Wetmore wrote: > This thread is an offshoot from the Linux thread that is going off on a number of tangentsl. > > How should we store evidence in genealogical databases? > > You get a marriage record in the mail; you find an image of a census record at Ancestry.com; you find the record of an event on a page in a book you found on Google books. What are you going to do with those three records? Here are some possible answers. > > First, if you are careful genealogists, you're going to record the source of the records in your database as source records. Got that out of the way. > > Second, as far as the "physical records" are concerned, let's say you carefully file the paper marriage record away in your paper filing system, and you go to your big ancestry folder area on your computer and keep copies of those two images. Dandy. > > Now, what are you going to do with the information in those three physical records (let's say we can call those image files "physical" for sake of argument). > > Here's the "normal" answer in my opinion. You look at the physical records, you decide who the persons were who are mentioned in those records, you go you your genealogy program and you find the appropriate person records, creating them if need be, and you edit in the new information. In other words you extract information from the physical records and you add that information directly to person records. Note that the information from the physical records only enters into your database as items inside person records. > > Here's another possibility advocated by some genealogists. After you create the source records for where the physical records came from, you edit those source records, adding to them the information that you got from those sources that you believe is important. You probably have to do this as "unstructured notes." Then you link persons to those sources and you also "copy up" from the stuff you added to the source records into the person records. > > Here's another possibility advocated by programs like Gramps for Family Tree Maker. You first create event records from information in the physical records, say a birth or death or marriage events, and then you add a link from some person in your database, creating that person record if need be, to that event record. The events really don't stand alone; you have to link person records to them. > > All these techniques work fine while you are in the realm of "person-based genealogy" or "conclusion-based genealogy". When in this realm you either already know whom the people are that you are researching, or you have such a solid vital record and other record trail back to them that you can be sure whom you are researching. You know whether any particular record belongs to a person you are researching or not; you ignore the records that don't, and you simply copy information out of the records that do. In my opinion 98% of the genealogical software is devoted to people working in this mode. > I should think we are all always in the realm of person-based genealogy; otherwise, we could fill in our pedigree charts with position-titles (great-grandmother, great-great-grandfather, etc) instead of names of people who hold that position/title. That we each HAVE 8th great-grandparents doesn't need further proving; mathematics does that for us. > Eventually every genealogist reaches the point when he or she has delved far enough back in time that the solid, firm trail of records has dried up. When we reach this point our task changes from one of simply elaborating persons we know or can learn about easily, to one of true historical research. We embark on the chore of trying to find whatever sources we can, from whatever creative recesses of our minds or experience takes us. From the sources we manage to find, we have to keep whatever information that mentions people that might eventually be of interest to us, and we must record that information somehow so we can continually be able to refer to it. We have faith that at some time in the future we will have found enough records that we'll be able to figure out who all those people are and how they are related. At that time, maybe far in the future, maybe after many serendipities in our record searching, we'll be able to finally create new persons in our database and ad! > d the hard fought information to them. > If I've understood parts of the discussion so far, it seems to me that more-than-one of the participants is suggesting we can NEVER be certain that recordA about Tom Wetmore refers to the same Tom Wetmore as recordB. How the researcher stores, organizes, accesses, or displays either record won't change that. That makes HOW to store, organize, access, or display sort of like nailing Jello to the wall: certainly do-able if you work hard enough, but just as certainly futile in the long run. > When we reach this point we are in the realm of "record-based genealogy." This has been described as "crossing a chasm." We are now true historians. We must collect lots of records, but we don't know yet whom they belong to. > As someone famous once said, now there you go again. ALL genealogy is record-based, if one uses the word record as a synonym for the word source. As someone else famous keeps saying, genealogy without sources is myth. HOW one organizes, stores, accesses or displays those source-records doesn't change the fact that we all need them to de-myth our genealogy. > What are you going to do with this evidence? If you use some of the approaches above you're kind of stuck. You can add paper copies to your files, or images files to your computer, but what else are you going to do? There are no people records around to stick them to. You can bloat source records with notes, but how can you find any of that unstructured info in the future? > It's very difficult to follow about persona vs person sometimes. Evidence does not exist in a vacuum any more than people do. IF there's people, there's evidence; one can always remove references to evidence if one can conclusively prove it's irrelevant. IME, though, if I don't SAY I looked hither, thither and yon, someone will suggest I missed thither. So putting it in and then debunking it is easier on my nerves. To debunk it, I need to attach it to who it might but doesn't concern. > To do your research effectively, to be able to reason about the data you've collected, you have to have some way of finding the information and arranging it. Are you going to do this by spreading sheets of paper on your desk, keeping lots of windows to image files open on your computer, taking lots of notes on 3x5 cards, sketching out possible family groups with paper and pencil? > Yes. > Wouldn't you want all that evidence information codified somehow inside your genealogy program so you can search for names, search for dates, search for places, see the relationships mentioned in the evidence, and so on? How would you want your genealogy application to support you after you have "crossed the chasm?" No. I want all that evidence raw if I need to re-evaluate it. I don't want it filtered, as it will be by extracting bits of it to codify. As someone mentioned, the bit you don't extract may be the only important bit in there. And creating a database for the purpose of comparing documents when the documents to be compared are NOT identical in content is going to drag AI into it; I'm not up to speed on the current state of AI, but I know as recently as Y2K, it couldn't make the same sort of judgments a people can because people STILL use unconscious, subconscious, and even subliminal info in analysis. Cheryl

Steve Hayes wrote: > On Thu, 26 May 2011 15:03:39 -0400, singhals<[email protected]> wrote: > >> Steve Hayes wrote: >>> On Wed, 25 May 2011 21:36:21 -0400, in soc.genealogy.computing you wrote: >>> >>>> singhals wrote: >>>>> PAF produces a UID for each entry; I'm pretty certain other >>>>> programs do to, particularly the ones that allow >>>>> synchronization of multiple databases. >>>> >>>> Well color me surprised. >>>> >>>> PAF and Legacy both assign a UID, which one can see in the GED. >>>> >>>> Oddly enough, and despite what I've heard said, when I >>>> imported the PAF file into a LEGACY file (direct import, not >>>> GED), the UIDs changed. Seems to me that's a bit awkward >>>> for someone trying to use those UIDs for anything. >>> >>> What is a UID, and where can I find it? >>> >> >> Unique IDentifier -- new with PAF4 as I recall, and I think >> inspired by another program that used them. As I recall, we >> were told that if two people used two computers to enter the >> same data each computer would generate a different UID for >> that person. I don't /think/ you can see them anywhere but >> the GED. The computer can, and in PAF when you run the >> match/merge routine, it asks if you want to use UID. > > When I do that it asks me if I want to us the Ancestral File Number. > In PAF 5 the UID is immediately below the AFN on that screen. > Thatr works quite well if the person has an Ancestral File Number, but those > numbers have now been discontinued, and no new ones are being generated. > GED is your friend. (G) If you can see it in a GED, you can edit it. Copy/paste the UID into a field you can see/sort on. Cheryl >> >>> I regularly export my data from FHS to Legacy. >>> >>> FHS assigns an RID, which Legacy callas a RIN, but if it imports them from the >>> GEDCOM file, Legacy scrambles them. >>> >>> So what I do is import the exported records to PAF 4, and import them directly >>> from PAF to Legacy. Then the Legacy RINs correspond to the FHS ones. >>> >>> But what is the UID? >> >> The UID is not a RID/RIN; it is specifically assigned to an >> individual record and does not mutate when moved around. > > I'll have to look at some recent Gedcom files to see if I can find them. > >

Bob Melson wrote: > On Friday 27 May 2011 22:03, Wes Groleau ([email protected]) > opined: > >> On 05-27-2011 22:28, Bob Melson wrote: >>> So, will SOMEbody please 'splain me this thing called a >>> globally/universally unique ID and its place in the grand scheme of >>> things? >> > > Thanks. It's about what I expected - and took away from the previous > exchange. > >> UUID / GUID were not created by genealogists to identify multiple >> definitions of a person. They were created by computer types to >> distinguish between two things that can't be told apart any other way. >> Kind of like a serial number. > >> >> A checksum on the other hand, is a way to be almost certain that >> two items have or don't have identical contents without actually >> comparing byte by byte. Or to verify that the item has or hasn't >> changed since the checksum was generated. > > And here you have it. My mind insists that *IDs _should_ be like some sort > of super checksum, with the same "record" resulting in the same *ID no > matter _where_ the record might be found. Dunno if it'd be any more > useful than a *ID, but it certainly couldn't be any _less_ useful. (And > the pesky critter - my mind, that is - insists there's gotta be a > reasonable use for *IDs beyond taking up space in a database.) > >> >> If a record on your machine and one on my machine have identical >> UUIDs, then either one of them was copied from the other (NOT >> independently generated) or one of us (or our software) was naughty and >> altered a UUID. If the UUIDs match and the items do not, then >> either someone changed the UUID on another record, or changed the record >> without giving it a new UUID. Well-behaved software will not >> gratuitously change a UUID. But lots of programs will fail to create a >> new UUID when the item ceases to be a copy of the other. That, in my >> opinion makes them useless for genealogy. But they were never intended >> to be some magic way of automatically identifying independently >> generated records as being representations of the same entity. > > Then why bother with 'em? > AIUI at the time -- they were intended to be used in a multi-person data-entry/research project which has a master/main/official database. The database "keeper" to use Legacy's term, shares the GED from that database with all researchers, who can modify or extend the data as they see fit before returning it to the "keeper". The "keeper" then uses the UIDs to find who changed or added what, without having to plod line by line through either the GED or the database. > I won't further belabor the point. Kinda like the Kipling poem "East is > East and West is West, and never the twain shall meet, 'til earth and sky > meet presently at God's great Judgement Seat", except here we have GUID > and UUID and ... (G) Cheryl

Wes Groleau wrote: > On 05-27-2011 03:55, Tom Wetmore wrote: >> You were right and should have stuck by your guns!! > > I may be misremembering, but I think the disagreement was that someone, > perhaps Bob, thought that the UID would be a universal ID for a _person_ > which could be used for that person in all databases. Others stated, > no, it distinguihses a _record_ from other records that otherwise might > seem identical. > >> I don't know where the others got the interpretation that a UID should >> be unique only within one database. This is certainly not a GEDCOM rule > > I don't recall seeing that interpretation. > PAF's help files specifically state that; Legacy's help files /imply/ it. From PAF's help file: PAF 5.0 assigns each record in the .paf file a unique record serial number. Like a record identification number (RIN), a Unique record serial number identifies each individual in a .paf file. Unlike a RIN, a unique record serial number is unique worldwide. This mean that each individual in each of the .paf files has a different number than all the other individuals in all other .paf files that are made worldwide. (para) The number does not change if you export a GEDCOM... Legacy's help file mentioned (UIDs) indirectly under Intellishare: One person in the group is designated the "Keeper of the Records" (Keeper for short). This person keeps the master Family File. Legacy automatically marks all the individual records in the Master Family File with a serial number that uniquely identifies each person ... Note that both refer to it not as an ID but as a record serial number.* That distinction virtually guarantees it has to be within a single database; as an analogy, Xcel and QPro wouldn't know whether line 564 in "Monthly Expenses" came before line 564 in "Appliance Repair", so why should and how would PAF/Legacy/whatever know whether RIN 534 in "McCOY.paf" came before or after RID 534 in "Hatfield.fdb"? Cheryl *Which, yes, inspires one to wonder why they didn't CALL it a URN or USRN or USN ...

On 2011-05-28 05:03, Wes Groleau wrote: > On 05-27-2011 22:28, Bob Melson wrote: >> So, will SOMEbody please 'splain me this thing called a >> globally/universally unique ID and its place in the grand scheme of >> things? > > UUID / GUID were not created by genealogists to identify multiple > definitions of a person. They were created by computer types to > distinguish between two things that can't be told apart any other way. > ..... But lots of programs will fail to create a > new UUID when the item ceases to be a copy of the other. That, in my > opinion makes them useless for genealogy. But they were never intended > to be some magic way of automatically identifying independently > generated records as being representations of the same entity. ..... I have never used UUIDs (which are not the same as mere gedcom ids) but I have always regarded them as a sort of Export Id so that for instance you can send a bunch of records all marked with UUIDs, let the recipient edit them as they see fit, and then send them back to you. The point is that they can edit anything they like except the UUIDs, so that data-wise the returned records could be difficult to identify except that you have those unique ids matching those in your original records. So basically the ids let you recognise records that you had generated, and also recognise records that were not generated by you. And also records that, although data-wise are now different, started out as the same record. It does not matter if programs mess around with gedcom ids as long as the uuids are unaltered. The uuids are not for identifying different instances of the same person as such, although they may achieve this in practice. The idea that these ids are for uniquely identifying every individual throughout history seems to me pointless and unworkable. Probably the only way to obtain truely unique ids is to have them generated by one central worldwide server. Failing that, unique ids across a restricted community such as two individuals may be obtained by having some sort of computer or personal id incorporated into the unique id. You need this arrangement because that other person might also be similarly sending you records for attention. As I said I have never used them, but the above seems to cover the essential points. Peter

On May 28, 3:51 pm, singhals <[email protected]> wrote: > AIUI at the time -- they were intended to be used in a > multi-person data-entry/research project which has a > master/main/official database.  The database "keeper" to use > Legacy's term, shares the GED from that database with all > researchers, who can modify or extend the data as they see > fit before returning it to the "keeper".  The "keeper" then > uses the UIDs to find who changed or added what, without > having to plod line by line through either the GED or the > database. That may have been the intention, but there's no reason to suppose it will actually work in practice. The _UID GEDCOM tag is not standardised. There may be a convention among programs understanding _UID that they should changed the UID whenever they change the associated data. But there's no reason to suppose an application that does not understand _UID will do that. When confronted with a GEDCOM tag it doesn't understand, some applications will simply preserve it intact. Any such application will then permit the modification of the data without changing the value of the corresponding _UID tag. Richard

On Fri, 27 May 2011 18:15:36 +0100, "Harrison Genealogy" <[email protected]> wrote: >Steve > >Also the following has appeared in the Custodian Forum.... > ><Snip> > >Currently, Custodian builds Indexes for Name and Place. I use User Field 1 >to keep my paper filing reference in. But will it produce a list of EVENTS sorted by date? And a list of the events that a particular person was involved in in ant capacity? Or the events related to a particular organisation? -- Steve Hayes from Tshwane, South Africa Web: http://hayesfam.bravehost.com/stevesig.htm Blog: http://methodius.blogspot.com E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk

On May 28, 3:28 am, Bob Melson <[email protected]> wrote: > To start, I don't want to re-ignite the previous discussion regarding *IDs, > aside from saying that it seems to me that a {Globally|Universally} Unique > ID should indeed be unique everywhere; given the identical input even on > different machines; the resulting ID should, or so it seems to me, be > identical but unique to that input. No. A UUID (or GUID if you prefer) is a specific piece of existing technology. It is not a generic term that can be redefined at will. It may or may not have been given the best name, but we're stuck with the name now. We can argue all day about whether the phrase "universally unique" carries the expectation that given the same input, it will produce the same ID. But the standards defining UUIDs are quite specific: the sole guarantee that it provides is that every time you generate a new UUID, it will be different, even if the input is the same. For some applications that's useful; for others that may not be what you want, and if so, a UUID is probably the wrong piece technology to use. Richard

On 05-27-2011 22:28, Bob Melson wrote: > So, will SOMEbody please 'splain me this thing called a > globally/universally unique ID and its place in the grand scheme of > things? UUID / GUID were not created by genealogists to identify multiple definitions of a person. They were created by computer types to distinguish between two things that can't be told apart any other way. Kind of like a serial number. A checksum on the other hand, is a way to be almost certain that two items have or don't have identical contents without actually comparing byte by byte. Or to verify that the item has or hasn't changed since the checksum was generated. If a record on your machine and one on my machine have identical UUIDs, then either one of them was copied from the other (NOT independently generated) or one of us (or our software) was naughty and altered a UUID. If the UUIDs match and the items do not, then either someone changed the UUID on another record, or changed the record without giving it a new UUID. Well-behaved software will not gratuitously change a UUID. But lots of programs will fail to create a new UUID when the item ceases to be a copy of the other. That, in my opinion makes them useless for genealogy. But they were never intended to be some magic way of automatically identifying independently generated records as being representations of the same entity. -- Wes Groleau There are two types of people in the world … http://Ideas.Lang-Learn.us/barrett?itemid=1157