PERSON
This entity type represents an individual person. In my world view the person is the central object of the model. Most every other entity exists to serve the PERSON.
I'm copying Adrain's description here:
"When a person is first entered into a BetterGEDCOM (BG) file, using the data from a single source, the person entity will clearly contain just the information extracted from that single source. When a second source, apparently for the same person, is obtained and entered to the BG file, the user can then proceed in one of two ways:
Add the new information to the existing PERSON entity, so that the single PERSON entity always contains the current working hypothesis about an individual;
Create a second PERSON entity, using only the data from the second source. The first and second entities can be referred to as "evidence" entities. Then, assuming analysis justifies this, create a third PERSON entity containing the complete working hypothesis for this individual, manually selecting those accepted pieces of information from the first two "evidence" entities to put into the third PERSON, which we can refer to as a "hypothesis" person (or "conclusion" person providing we understand that these conclusions will probably be updated later)."
Attributes:
UUID - required - a universally unique identifier. (I'm not entirely sure any UUID will be truly unique across many systems. But that's the general consensus)
PersonKey - optional - a unique identifier which can be assigned by the researcher. By default it will start at 1 and increment for each new person. This gives a more user-friendly way of tracking a PERSON, than the UUID.
Gender - optional -
(M/F/U).
Class - optional - A limited choice field
(Conclusion/Evidence).
Description - optional
.
Surety - optional - a value on a scale indicating how certain the data is.
Relationships:
A PERSON may have 1 or more NAMEs.
A PERSON may be found at 1 or more LOCATIONs.
A PERSON may have 1 or more CHARACTERISTICs.
A PERSON may have 1 or more pending or completed TASKs.
A PERSON may own 1 or more OBJECTs.
A PERSON may share evidence (ROLE, EVENT, LOCATION, GROUP, OBJECT, SOURCE) with 1 or more PERSONs.
A PERSON may share 1 or more RESEARCHERs.
A PERSON may be involved in 1 or more EVENTs.
- A PERSON can have 1 or more ROLES which are subordinate to 1 or more EVENTs.
A PERSON may belong to 1 or more GROUPs
- A PERSON may have 1 or more ROLES which are subordinate to 1 or more GROUPs.
1. Feel free to have an optional UUID - obviously some people desire it, so let's the possibility.
2. Can any hardware and software platform generate a UUID? Could a Smartphone version of BG compatible software do it? An iPad? If not, it cannot be mandatory (here or anywhere).
3. I really can't see its value. What am I missing?
If I create a Person record for John Bruce, married to Annie Bruce in Scotland, with a UUID, and someone else creates another Person record for John Bruce, married to Annie Bruce in Scotland, with a UUID of its own, the UUIDs don't help me decide whether he is the same John B or not.
If I export my Person record for John Bruce, with its UUID, and eventually get a BG format file back with a John Bruce having the same UUID, what use is this to me? While I know where the Person record started (me), I still need to look at all the data that's been added because what's changed since it left me could be sheer garbage. Or sheer brilliance. Assessing that doesn't seem to be help by the UUID.
Except... On innumerable occasions, I have needed to check when doing a merge that I've got the right John Smith - to do this, I use the Id and checking whether I've got John Smith I4472 is a sight easier than checking the full length of a UUID.
So I still prefer ordinary numbers to UUIDs
A UUID is almost certainly nothing a user would ever see.
This is a great example of an issue that doesn't matter really at all, and if developers/vendors have a problem with it, it's easily changed.
In the meantime, I suggest we keep using it simply to have some sort of shorthand for "record identifier." The UUID is not supposed to be analogous to the personID (or whatver) that a user is familiar with in their database. I would expect there to be other allowance for ID numbers that an application assigns or that apply to things like AFN entries or other such things.
I have seen the problem where user info is entered in the person area. when the merge takes place the data mashes.
However to use a UUID your john 878 and my john as 920. you can import all the events I have cataloged, to your events lists without over writing your data.
Johns 878 info which you set him up to be displayed as. What would happen, is say you have 12 listings describing events of your Johns life. You see I have 6 that you do not have. Your choose all or just the ones you want.
Your app side takes all my person evidence as is, and the link source data. The only thing is the UUID for John 920 is changed to 878. on all imports.
BONUS:
None of your John preferred display name is altered, none of your work is altered or over written. Just additions that you can add or delete at any time or relabel class and type of event and source.
My opinion is that the old style formats make decisions "Thought Process of match and elimination" left up to a computer using predefined hard tags in the db structure. That is where many user defined data is lost because it does not conform to those hard tags identifiers like BIRT or birth and not the UUID alone.
Your other point is well taken, I neglected to add a user friendly unique key. But this is something that really isn't necessary for the data. A "nice" program could automatically create these when a user wants a display, doing so might introduce other issues. I'll add the field, and make that one optional. The users aren't going to see the UUIDs. But we want to index these tables, regardless of whatever implementation. These are there for the developers. Every table needs a key. Keys are fast, whole text searches are slow. Fast and correct is good. Yes? ;')