BetterGedcom - Person entity

Person entity suggested name: Nominal Record

Questions: What is a person? What elements does each person have that are mandatory? What are the optional elements? What elements may belong to a person or may be better defined elsewhere?

Definition and Issues

This is the entity type for an individual human being. There are two types of Person entity types sometimes discussed. The first is a Person entity type that records only the information about a person that can be taken from a single item of evidence. This usually includes the person's name and one or two (sometimes no) other information. This kind of Person entity is sometimes called an evidence entity since its information is derived from evidence. Some proposed names for this entity type include Person, Persona, Nominal. The second kind of Person entity holds all the information that can deduced about a person, at that stage. This may include name, vital information from whatever sources have been found, residence information that might come from census records, and so on, to produce an entity that is as complete as possible. This second kind of entity can be referred to as a conclusion entity, because it contains all a researcher has found out about the person. Note that "conclusion" may give a misleading impression of finality - the term "current working hypothesis person" has also been suggested. Some names that have been proposed for this type of entity are Person and Individual.

The evidence and conclusion / working hypothesis model is designed to support the process of Analysis, which uses Evidence as input to the Analysis process and outputs Conclusions (a.k.a. working hypotheses). This model enables the permanent recording of Evidence input and Conclusions output from each process of Analysis. Note further that the output conclusions from one analysis process could form the input evidence to a further iteration of analysis, and that therefore one entity can be both evidence and conclusion, since they are evidence and conclusion to different iterations of analysis. (c.f. Elizabeth Shown Mills' statement, "SOURCES provide INFORMATION from which we select EVIDENCE for ANALYSIS. A sound conclusion may then be considered "PROOF" from "Evidence Analysis: A Research Process Map.")

Questions being considered about Person entities include:

Which concept(s) of Person entity should the BetterGEDCOM model support? Most current data models and genealogy programs support a conclusion-only version, since this is the most obvious and meaningful for general users. It is difficult to envisage a conversion process that could split an existing conclusion (a.k.a. working hypothesis) only file into a file containing both evidence and working hypothesis persons, suggesting that the BetterGEDCOM data model must support, at least, working-hypothesis-only data. However the evidence and conclusion / working hypothesis version provides the kind of support a researcher needs into order to gather evidence and then infer the set of individuals mentioned. It is therefore suggested that the BetterGEDCOM model supports both evidence and conclusion / working hypothesis person concepts, while also allowing for working-hypothesis-only data.
If the BetterGEDCOM model supports both evidence and conclusion / working hypothesis person concepts, can they both be based on the same Person entity type and can they both be used simultaneously? Or would there have to be two separate kinds of Person entities? Consideration of the real-world genealogical attributes and relationships for a working hypothesis person suggest that they have all come from an evidence person, and that therefore the attributes and relationships are identical on the two. Further, the iterative nature of analysis referred to above suggests that an entity can be, at the same time, a working hypothesis and an evidence entity. This suggests strongly that the entity type is the same for both uses. Note that some optional minor attributes and relationships might differ between the two uses.

Analysis of attributes and relationships

Attributes and relationships can be categorised in at least two ways. Firstly:

Attributes and relationships derived from, and known to, the real-world, such as name(s), dates of birth, occupations, marriages, etc.
Attributes and relationships used internally by the processes and software of genealogy / family history, such as UUIDs, Ahnentafel numbers, privacy flags, keys, etc. These are crucial to the processes and software but unlikely to be meaningful to the person in the street.

Another way to categorise is to split a person's attributes by type. This distinction is probably meaningful only to genealogists and software people but needs to be considered here. The original GEDCOM format split (most of) a person's real-world data into "events" and "attributes". Note that the GEDCOM use of the term "attribute" must not be confused with the use of the term attribute in data modelling. The distinction between "events" and "attributes" in GEDCOM was never, in the author's view, very clear, and some software using GEDCOM just referred to both as "facts". In the BetterGEDCOM model, there is an argument for extending the concept of "event" so that it may apply to more than one person. For instance, a birth event typically (but not always) involves three people - the child and two biological parents - but in GEDCOM applies only to the child, with the parents being implied by whatever the contemporary family is. A marriage can involve four people - bride, groom and two (sometimes) witnesses. A natural disaster can involve numerous people in the area. Residence can involve several people living as one household. In none of these cases, does the current GEDCOM structure allow easy, consistent and machine-readable recording of all participants in the event. If BetterGEDCOM does extend the "event" to allow participation by multiple persons, what about what GEDCOM refers to as "attributes"? The author can see no justification for extending "attributes", which I shall now call Characteristics, to apply to multiple people. A physical description only makes sense if it applies to one person only - the same words may be used elsewhere, but the phrase describes one person only. A name applies to one person only - again, the words may be used elsewhere, but the name applies only to one. Further, the difference between Characteristics and (multi-person) Events is not just one of number of people involved - but in the case of the Characteristics, if the Characteristic is entered, there is always a value of the Characteristic, e.g. the name, the actual physical description, a list of possessions or the occupation. It may be useful to have a descriptive text for an event but in many cases it is simply unnecessary as the event can be sufficiently "described" from its own attributes. The second way to categorise attributes and relationships of Persons is therefore:

Characteristics - describe the current information known about a certain characteristic of a single person and, if present, require a mandatory value of some sort;
Events - describe an event that may affect multiple people and need not have a mandatory value.

Questions to be asked about attributes of Person:

Should Events in BetterGEDCOM apply to one or multiple persons (rather than always just one)? (An alternative could be to create a Group entity for this event and apply the Event to the single Group, then trace through the Group to the Persons concerned)
Does the definition of a Characteristic make sense?
Is the categorisation into Characteristics and Events useful? Or should both concepts simply be referred to as Facts? (If the answer to the first two questions is "yes", then referring to both as Facts will obscure the applicability of a Characteristic to a single Person only).

(Please respond to Questions on Discussion pages)

See "Event entity" for detailed consideration of Events.
See "Characteristic entity" for detailed consideration of Characteristics.

Attributes of Person entity attached directly to that entity, i.e. not to Events or Characteristics:

An optional UUID (Universally Unique Identifier).
Flags for privacy and security

Potential facts about people to be stored as Characteristic entities (assuming it is part of the model)

Note that all of these Characteristics may occur multiple times - e.g. a Person may have several names over the course of their life, each to be recorded on one Characteristic entity.
All these are optional.
Names (names should have date elements) - including nicknames, alternate names, married names, etc. Consider name templates: examples could include Western European, Patronymic, Matronymic, Medieval, geographical-titular noble [see below])
Title(s) - prefix/suffix; Nobility
Gender (male, female, unknown [intersex? should this element have a date sub-element?])
Award (e.g. medal, etc. Description is name of the award.)
Caste
Educational qualification (description is name of the qualification)
Military service (description is name of unit or service served in)
National ID number / SSN, etc
National or tribal origin
Nationality
Occupation (entity to include further attribute for employers, etc.)
Patent or trademark (description is short description of patent / tradmark)
Physical description
Possessions
Religious affiliation
(Many of the above have been extracted from GEDCOM 5.5 and their exact meaning is not always clear. This may, or may not, be an issue)

Potential facts about people to be stored as Event entities (assuming it is part of the model)

All these are optional.
Adoption
Annulment of marriage
Baptism / Christening
Bar Mitzvah
Bas Mitzvah
Birth
Blessing
Burial
Census
Confirmation
Cremation
Criminal conviction
Death
Divorce, divorce filing
Draft Registration
Education (attendance at school, college, etc)
Emigration
Engagement
First communion
Funeral
Guardianship
Graduation (but see Educational Qualification)
Immigration
Marriage, marriage banns, marriage license, marriage contract / prenuptial agreement, marriage settlement, etc
Naturalisation
Ordination
Probate granted
Property
Residence at a location
Retirement
Will (making of)
(Many of the above have been extracted from GEDCOM 5.5 and their exact meaning is not always clear (e.g. the difference between baptism and christening). This may, or may not, be an issue)

Question - Do we add the LDS events (e.g. sealing in a temple) that are listed in current GEDCOM as standard BetterGEDCOM events, or do we specify that the software convert such facts as user defined extensions to BetterGEDCOM? (Respond on Discussion pages, please)

The following sentences and phrases are text left over from a previous version of this page and not included above for one reason or another:

"All records should also have a set of UUIDs for which it is known that this record represents" - the author is not clear on the meaning of this phrase;
"Heraldry" This was a proposed event / characteristic - the author is unclear what is meant by this as it is a hugely complex topic;
"Membership" This was a proposed event / characteristic - I suggest this belongs to the relationship between a Person and a Group.
"Certification" This was a proposed event / characteristic - its meaning is not clear enough to decide whether it is an event or characteristic;
"Surety / bonding" This was a proposed event / characteristic - its meaning is not wholly clear to me. I know of its use in marriage licences - what is the generic case?
"Sample Media oriented Events: Likeness ..." This was a proposed event / characteristic - is this not simply the same as Physical Description but with added media?

Comments

rwcrooks 2010-11-09T14:59:58-08:00

Alternate Name - Optional

Many people change their names, add a dit-name (Canada), change the spelling of names.

This is an integral part of a person and identified solely with that person.

Anybodybutme 2010-11-10T03:00:35-08:00

Person entity and relationsips between Person entities

Person entity represents a human being who was born.
Evidence for that birth is entered in Sources.
Elements on the Person entity record the information in the birth certificate/parish record/etc. where this exists.
- name at birth
- gender at birth
- date of birth
- place of birth
- date of death
These can only occur once per birth. ?Any more once-only data items?

Thinking about a Person from the perspective of Birth is most user friendly, so:

Each Person entity has an optional, many-to-one relationship to a Mother. Optional because the information is not always known when evidence for the birth is discovered. This is a special relationship, different from all other Person to Person realtionsips. ?technology effected birth?

Each Person entity has an optional, many-to-one relationship to a Father. ditto

Each Person entity has optional many-to-many relationships with other Person entities who are siblings. (my first design approach to implementing this many-to-many relationship would be to define a Family entity - too easy to resist, and oh so handy for other stuff).

Each Person entity has optional many-to-many relationships with other Person entities who are of the opposite gender and are the other biological parent. This would seem to lock down the Family entity, as a clear mechanism to resolve the various many relationships. It allows unknown Fathers to be lumped together if the user so wishes, then separated out when required.

Has this defined all the relationships that are essential between Person entities to define the Person's birth?

Sibling is not an essential relationship, but I find it an easier route to understanding the requiements for the Family entity.

Not ground breaking stuff, but of course it has already been ploughed many times.

Anybodybutme 2010-11-11T00:46:08-08:00

greglamberson wrote "In some cultures"
The first post of this thread is relevant to my culture. I do not presume to speak for others.

AdrianB38 wrote "a stream of quotes from sources that we rely on the application software to make sense of"
Not sure that I need the software to make sense of it, however I agree that is the reality for the recent past, the family memories - two or three generations, perhaps, for my culture. Then it is a matter of recording the documentary evidence. The documents in my culture are represented by my proposed data model. Quick and easy recording of the mass of people whom you believe may be your ancestors is a requirement. GEDCOM allows for that.

greglamberson wrote "I must admit being in a bit of a stupor" and "Yes, well, unfortunately" and "Quite so - but" The X of XML means Extensible. Straight migration of GEDCOM to XML would be a starting point. Once other cultures begin to add their inside knowledge, then the XML can be Xtended.

ttwetmore 2010-11-11T02:10:29-08:00

There are clearly two types of person entities necessary in a data model. The person entity that holds only and exactly what can be extracted about a person from a single piece of evidence, and the person entity that represents all your conclusions about a single real person, which should be some representation that includes the collection of the first kind of person entities the user/researcher decides refer to the same real person. This is fundamental, basic, obvious, absolute, and if we can't start here or somewhere close to it I can't see any way to continue.

It is not feasible to require any attributes to be required for person entities of the first kind. Say your evidence is this "John Smith's wife was 23 years old when they were married in 1844." If you required every person to have a name then you couldn't add John's wife to your database. But the fact that his wife as 23 in 1844 gives a lot of genealogical info. One. It says he had a wife; period; a critical bit of genealogical information. It says she was born some time around 1822; another critical bit of genealogical informaton. It says John and his wife were married in 1844.

My conclusion is that a person entity of the first (evidence) kind only needs one known attribute to be a candidate for inclusion in a database, and that really means any attribute. If you have a name, great, but if you don't have a name, you don't want to loose the information you do have.. If a person needed to have a name the only way that info about John's wife could be added to a database would be as a note in John's entity, and notes are notoriously hard to have genealogy programs look at and analyze and do anything meaningful with.

Tom Wetmore

ttwetmore 2010-11-11T02:18:50-08:00

Asking whether the data model should be person centric or event centric implies it must be one or the other. Why? My contention has always been that both persons and events are primary concepts.

If an event is not a primary entity then info about events must be subsumed somewhere else in the model, and the only reasonable other place is inside person entities. This is only appropriate for trivial cases like death events when other people are only involved in a most distant way.

Any event worth its salt includes/mentions multiple people in different important roles. If the event could not stand alone in a model, then either every person entity playing a role in the event would have to contain redundant information about the event, or one person would have to be chosen to be the primary holder of info about the event and all other persons (we are obviously talking about person entities of the evidence kind here) would have to refer to the person holding the event information.

I hope this is persuasive that least at the evidence level that person and event entities are both necessary and coequal in importance to the model.

Tom Wetmore

greglamberson 2010-11-11T02:45:04-08:00

Anybodybutme,

GEDCOM has in fact been ported to XML. This was done years ago. There are in fact several completed modifications of GEDCOM that have been developed using XML. The problem is these are not widely used. Why? In the case of direct ports of GEDCOM or slight modifications thereof, they frankly provide no significant benefit and so the developers have not committed development time to implementing them. In other cases, workable data models that have been developed have simply not caught on for a variety of reasons. However, one thing is sure: a simple port of GEDCOM provides no significant benefit to anyone.
The structural problems of GEDCOM do not allow it to be merely expanded to accommodate other, more advanced concepts. The underlying data syntax (i.e., the GEDCOM format as described in Chapter 1 of GEDCOM 5.5 standard release), and likewise a simple adoption of XML in its place, is irrelevant. We have to fix problems associated with more advanced genealogical practice to have any value to developers at all and thus get something actually adopted and available to users.

greglamberson 2010-11-11T03:01:27-08:00

Tom,

I am merely hoping to drive discussion. Some of these concepts may in fact be pretty basic, but it is far better to allow a great deal of the community to discuss, understand and come to these conclusions themselves than just adopt some largely finished conceptual data model and hope everyone knows what it means, or worse yet, just not worry about what nontechnical types think and drive home a particular point of view.

A great deal of this effort is about the process. We have intentionally started with a blank slate. I think we can very quickly gravitate to a data model concept and start adding significant detail to it. In my above comments, I haven't even really touched on the most critical aspects. For example, I don't think person or event concepts are the real points of contention. The question in my mind is how do we accommodate a proof process in a data model while working with conclusion-based data. However, I don't think jumping right to this is of benefit to everyone.
There are many levels of discussion around, and I think we can allow them all to go on at the same time. It's not necessary or even desirable to drag everyone right to the most difficult concepts before engaging in some more basic discussion.

joehcole 2010-11-11T03:07:09-08:00

While I agree that there will need to be a Person object as part of the data model, I think for all intents and purposes a successful model will be based around the Event.

The Person object should contain the UUID, and nothing else. We need this in order to link the same person across different events. The data model must avoid any duplication of data, any attribute stored against the Person object would inevitably be duplicated in an Event. For example, parents would be roles within a birth Event. Names may change, and require date ranges, so we would need a name Event.

We also end up with a much cleaner, hierarchical structure rather than having to define different schemas for different objects, i.e. something like...

<event>
<attribute>
<source>

...that way we don't get sidetracked working on different objects that then have to be made to work together, and all the tricky stuff that Greg mentions like proof and conclusion can be dealt with within that structure.

Remember, the way we think about genealogy, which is person-centric, is not necessarily the best way for computer systems to work with the data.

AdrianB38 2010-11-11T13:39:24-08:00

I also believe that the data model can accommodate both person entities and event entities. And the rules of data normalisation swiftly drive out things like Name from being attributes of the Person entity to being entities in their own right, leaving - as Joe suggests - probably very little against the Person entity.

However, I am unsure that the successful model would be based around the event. I like the idea of an event being related to several people - e.g. a census, a marriage, the San Francisco earthquake. I am less keen on the idea of a "Name event" - just what does that mean in English? Not a baptism or a birth registration because those might not take place. Another oddity would be a "Physical description event". This is the sort of thing that is referred to as an attribute in GEDCOM type software. (A term I hate for 2 reasons: firstly its confusion with attribute in data modelling, secondly because the difference between an attribute and an event in GEDCOM is pretty slim).

I initially envisaged a Person-Fact entity - one Person may have one or more Person-Facts known about them. These Person-Facts would have a "type" and also a date-range and this could accommodate a person's name(s).

My problem with this view is that the Event entity (which I like) and the Person-Fact entity then start to diverge, whereas many things could be viewed as either one thing or another (e.g. is military-service a fact or an event?)

I would really like there to be one entity type to cover both Person-Fact and Event - but I am rebelling against calling it an Event!

AdrianB38 2010-11-11T13:46:32-08:00

"...the truth has only one value..."

Yes Greg, I did mean it. A person can only be born once and there is a single specific date and time associated with that.

That the birth date and time can be disputed is a different and separate matter. Indeed by the very nature of reality, we can never be 100% certain that we have got the exact and single truth. We actually agree that it's important to accommodate (somehow) the different views on when but it's also important to remember that we are dimly grasping towards the truth.

(And it's another matter again when we think that even if we have only one conclusion about when someone was born, we could use several calendars to document it!)

testuser42 2010-11-12T15:37:21-08:00

I very much agree with Tom's reasoning. And I think what Joe said isn't so different at all from that.

From a user's perspective, a logical structure for me would be something like this:

Everything starts with a "source". Where does the following information come from? I could imagine defining "conclusion" or even "speculation" as a source (it should be shown who came up with it)

Then, what information is there? Just put down everything thats in the source. If a person is mentioned, make a "person" and attach to it only the bits of information that are in the source. If an event is mentioned, make an "event", describe it and the relevant person(s).

Every "person" is created for a "source", because only this is documented. To link the "persons" of different "sources" together, a kind of top-level "person-UUID" would be necessary. It should collect the different pieces of information, while keeping the integrity of the sources. Also, it must be possible to unlink information from the UUID.

re Adrian:
I think "person-facts" are fine and necessary. But events are something different. Events can have "facts", too. In your example of military service, I'd say it's an event (there are others at the same event - maybe that's a way to make the distinction?). But in the end, I guess it can be left to the developers of the programs what they consider an event and what a "person-fact".

Another thing: Maybe "fact" is already too confident? How sure are you that everything is a "fact"? Maybe something more neutral, like "info"?

This shows the need for a way to record "sureness"(?) or "confidence" for every "source" and every piece of information on it seperately. Maybe I believe what Aunty said at her 99th birthday about her childhood, but maybe she got the part about her great-grandma wrong...

just my 2c ;-)

greglamberson 2010-11-12T16:56:05-08:00

So far, keeping in mind I'm jumping from discussion to discussion at a frenetic pace without proper analysis, so far I totally agree and understand Joehcole's point of view. I'm not sure this is the right way to model data in this effort, but I think of genealogical data such that I too think a record that represents a person is essentially a container that has only a UUID and nothing else.

From Tom's discussions here and elsewhere, I see he considers two sorts of person entities as essential. I don't get this yet. To me, a person record can be placed in a role within a relationship record/entity. (This wades into the issue with regard to having a family record or merely using child/parent event-type records. Anyway...

Adrian, yes I suppose of course a person can only be born once, etc., but we are talking about documenting genealogical research, and for those purposes it seems we need to worry about accommodating multiple records for birth, not worrying about Platonic concepts that aren't part of the documentation process. Again, perhaps I just don't understand, so please don't take that the wrong way.

Now getting into testuser42's post of 50 minutes ago.. This concept of a "person-fact" may be what Tom was referring to. I'm not sure. This concept is interesting, and it may be part of exactly what my methodology friends are clamoring for. This isn't a concept that I can identify in my genealogy software (not that that means anything).

One thing I do have a problem with is combining several things about a "person-fact" into one item, because each item can have different veracity/surety, and if you just dump all the info about one person into one thing, how can you "rate" the information differently?

hrworth 2010-11-12T21:44:28-08:00

Greg,

Trying to figure out where some of this belongs. In the Software side or the transport side of the data entry.

I think, that the Identity of a Person needs to be unique and identifiable, Events that this person had, and the source of where this Person to Event was found.

There may be a number of attributes to an event, Date, Location, other details, depending of the event.

That individual will most likely have multiple Events, each with a Source.

That needs to get from one location to the other. How those links are assembled in the transmission of that record is what is important, I think.

I am not sure that the BetterGEDCOM should have anything to do with the "rating" of the data provided.

There might be an attribute assigned to the Source, but that information should be sent along. The End Application as to do two thing here, 1) have the ability to have an evaluation attribute and pass it along, and 2) see at evaluation attribute and present it, if one is present.

If the end application doesn't provide a rating attribute, its an I don't Care rating. The BetterGEDCOM just passes that information along. If the receiving application doesn't deal with a rating attribute, it 'drops that attribute on the floor' but should alert the user that an attribute was received, but "I" don't know what to do with it. (or, See Error Log)

Maybe I am missing some of the technical aspects of this subject, for that I am sorry. But I am trying to read and understand the discussions on this wiki from a User's point of view.

Russ

brianjd 2010-11-23T22:55:13-08:00

Ok. here's my take on the person entity.

One it should be called person. After all that is what we are seeking.

Two it needs the UUID. Name is optional.

A person has: a hair color, an eye color, a adult height, a weight (or many), a sex, possibly now a sex alteration, a DNA sequence (probably needs to be broken out into multiple fields - or possibly it's own entity), some would say a race (not me though, there is only one: HSS, unless someone has some HS Neanderthalensis genes).

I would, for convenience sake include a name, but this is better handled as a separate entity, as a researcher may change this many times and a person may wind up with multiple complete names.

Some fields I wouldn't include.

So:

+ = primary key

= required

F = foreign key

PERSON
+ *UUID
sex at birth
hair color
eye color
height - adult height
privacy

A PERSON can have events. places, notes, DNA, sources, researchers, conclusions, LDS. The privacy flag could be the key to control what is visible, and i the logical place to put it. This one field could control it all. The person is: private,restricted to family, restricted to granted users, dates restricted, birth restricted, death restricted, etc. Another way of course is every record has such a flag.

I'm sure more persaon haves can be thought up.

Person should be the central entity to the entire data model. It's worth taking the time to lock this one in.

So next entity would be Name. Every person has a name, but it may not be knowable.

NAME
+ *NameID
F *UUID
Prefix
First
Middle Names
Used Name
Patronymic
Matronymic
Last
Family
Clan (Tribe)
Suffix
Confidence - how positive are you of this record
F Source
F Event

I've added two foreign keys so that each name could be linked to the event and source from which it was derived. It may be that it would be better to pull those out into Name-Event and Name-Source tables. Which would simply look like:

Name-Event
*NameId
*EventID

This allows a many-to-many relationship. Which is probably preferable. But more work.

greglamberson 2010-11-10T05:16:35-08:00

Yes, well, unfortunately, many assumptions here are the very one which have been pointed out to me as being evidence that this model isn't adequate.

In some cultures, a child can have multiple names that are parallel and serve different purposes. More important, the dates and places of birth, death and about any other ones can be disputed and be different according to different sources or different analysis of the evidence. The same is true for the mother/father relationships, not to mention that there can be different types of mothers: biological, adopted, etc.

Thus the presentation you have given makes certain assumptions that probably will not sit well with everyone, particularly those who favor a more scholarly approach to research.

AdrianB38 2010-11-10T14:15:25-08:00

"the dates and places of birth, death and about any other ones can be disputed and be different"

Quite so - but the truth has only one value (possibly several names but that's another issue).

So the question arises - does the data model represent the conclusions? Or options? Or the raw evidence? Obviously, this applies across the board, not just for an individual.

If the conclusions, there should be only one birth event - albeit it might not say much beyond "Planet Earth" for birthplace.

If options, then there could be several birth attributes (using "attribute" in a data modelling sense).

If the raw evidence, then it's more like a stream of quotes from sources that we rely on the application software to make sense of.

So basically, this has teased out a query about the scope of our data model.

greglamberson 2010-11-10T15:38:20-08:00

"...the truth has only one value..."

I'm not sure if you're saying this to be provocative or you really man this.

You want to know whether the data model will be person based, event based, etc. Right?

Me too.

Frankly, I would love to see someone take on explaining what these concepts even mean and begin a discussion about which to adopt. Right now, I must admit being in a bit of a stupor, just glad we're finally discussing all this stuff out in the open.

I'm sure we'll quickly get to this, but for now, I think we're doing fine.

However, if you want to start building pages about the different major types of data models, what they accommodate, what their shortcomings are, etc., then go right ahead. I'll probably do it in about a week if it doesn't happen sooner.

AdrianB38 2010-11-25T09:41:12-08:00

Events and multiple persons?

In my update of the page I ask:
Should Events in BetterGEDCOM apply to multiple persons? An alternative could be to create a Group entity for this event and apply the Event to the single Group, then trace through the Group to the Persons concerned

This question can either be asked here or on the Event entity page but since it mentions Persons, I'll ask it here...

mstransky 2010-11-25T10:11:54-08:00

Could you consider that if there is an event (interpetation/reading/translation) from a source document.

Like 1910 fed census household

3 people live there

The Event or say INTR interpetation of the image/doc or story book
Can be captured by the genealogist like so

EventId3, SourceID78, INDI#12, Roll, Name,
EventId4, SourceID78, INDI#57, Roll, Name,
EventId5, SourceID78, INDI#87, Roll, Name,

What ever you want to call this geneologist translation of the sourcedoc.

There is one Sourcedoc, yet 3 seprate event/interpetations of the image to text.

event@13 Sour@15 Indi@85, Type,Clas,Roll,date...
event@15 Sour@15 Indi@45, Type,Clas,Roll,date...
event@19 Sour@15 Indi@22, Type,Clas,Roll,date...

event@19
Sour@15
Indi@22,
Census,
Type Clas,
Name John Smithy
Roll Head
...

This way you use the event/translate insert which links the INDI to a Sour. YET supplies all those various things people want like Altered birth date, or alt names aside what the actual INDI NAME says John Smith, the event name says John Smithy.

INDI Your Geneologist Choosen name
EVNT or INTERPET ID holds a single ref of information which points to a SOUR/DOC REF.

So all the EVNT tag interpetation can list under an individaul AND all various inforamtion can be seen for what it is regardless of matching or not!?

REASON if keeping one EVNT tag to ONE Person is if that info was mis read, a genealogist can correct that line without effect all the extra poeple it is attached to.

Maybe an EVENT is not a good tag to source info, maybe an observers observation of the Sour line pointing to a sour.

Would in be better if I just show an example? and how it eliminates many of the individual questions people pointed out before?

mstransky 2010-11-25T10:21:12-08:00

Real quick a Marriage cert. SOUR@142

your can have four event/interpitations

EVNT@34 INDI@65 marriage, cert, Bride, laura
EVNT@34 INDI@65 marriage, cert, Groom, paul
EVNT@34 INDI@65 marriage, cert, wintness, tom
EVNT@34 INDI@65 marriage, cert, witness, joe

Each line is for a sigle person but all point to ONE source doc, yet captures the observers interpetation of the dociments like age date place etc. Later if a name is miss read it can alway s look at the document and evalute if it needs to be updated as needed

When a person sees John Smith in the INDI area and John Smithy in the Event capture. They can make they own hypothosis or call it proof by misspelling or name change.

mstransky 2010-11-25T10:42:41-08:00

If you dont mind it is still a working db that I am modifing but I highlight this point in bright green http://www.stranskyfamilytree.net/SFTxmloutline.asp

If it is hard to follow the four seperate xml areas I can translate it into GEDCOM style format to better understand. The main thing is that it can take care of many of the "waht abouts that have been written and uses less kbs than alot ofthos gedcom foramts in xml styles.

hrworth 2010-11-25T10:57:28-08:00

mstransky,

You mentioned "the genealogist" a couple of times. The Genealogist won't be involved with pulling information our of a string of data. The Application will. Same goes the other way. The researcher will enter data, but the application will back up that data, into a data string, and send it to the BetterGEDCOM.

Russ

AdrianB38 2010-11-25T12:58:54-08:00

Russ (I think) mentioned in response to my question "Should Events in BetterGEDCOM apply to multiple persons? An alternative could be to create a Group entity for this event and apply the Event to the single Group, then trace through the Group to the Persons concerned" by:

1. Reminding us that there may be only one person in the file. Perfectly true - all references to "multiple persons" should be understood to include the possibility of ONE only.

2. He also said that the alternative (creation of a group) was "adding room for errors. At least that is my opinion". Personally, I agree with him.

hrworth 2010-11-25T13:21:09-08:00

Adrian,

Correctly stated.

Thank you,

Russ

mstransky 2010-11-25T16:02:43-08:00

"exactally" That is what I am afraid of by making a xml structure so complicated it almost becomes so complicated to make universal among everyone anyone and a burnded on itself and the end users of its structure.

GEDCOM styles have created all these kinds of event-types TAG as if they were the defacto source it self. when are they are is the interpetation of the TRUE source in hand.

1. "You can not put your hands on an event. But you can put your hands on a document source."
"IT IS THEE source document" which is what more then one persons is attached to.

But before we attach the source document we can have a (EVENT/TRANSCRIBED TAG <<what ever you want to call it) a genealogist or reasearch who interpeats the data FROM the image to a text data fields. Such like names, age, date note..and on this STRING we connect this data as the ""go between"" to INDI and the SOUR where the data came from.

2nd all the talk about defining diffrent types of source a out there is great!!!!, but dont make ALL these types actual STING TAG NAMES.

You guys are the cream of the crop, to make the gedcom universal and most transversable to everyone and every appication and users it can reach.

I could some it up in a 5-10 minute converstaion and you would go OH I get it, but trying to explain how make TAG STRINGS unique for every type of sourc document is shooting ourselves in the long run AND recreating that lauguage barrier to keep it univarsally functional among more than one group of users and application. NON FLEXIBLE but it would work, but as it grows you trap yourself stuck in a gedcom structure looking like gedcom.

It sounds great covering all the possiblities right know, but other discussions are starting to scream GEDCOM structure as a chunky xml because it can be done that way.

i think we are all better than that and just becarefull we are not reapting 3 steps forward but find ourself 2 steps back.

mstransky 2010-11-25T16:14:04-08:00

I will make an viewable example, it is worth a thousand wrods. I think comunicating via message we miss each other when we say event like di they mean a string, and label, an actual event of a sub string of something. You have to views of a seeing it your minds eye as a xml format or are we just talking of a definition of a technical manual perpective literally or funactionally.

ttwetmore 2010-11-26T02:37:40-08:00

Adrian asks: "Should Events in BetterGEDCOM apply to multiple persons? An alternative could be to create a Group entity for this event and apply the Event to the single Group, then trace through the Group to the Persons concerned"

My answers:

1.) Events must apply to multiple persons. That's because events apply to multiple persons.

2.) Using a group to apply to the persons with the event referring to the group. Interesting idea of a way to make the event only indirectly refer to the multiple persons, but why do it? If you did this you imply that the group entity could be an evidence entity. Again, interesting. I always think of a group as a conclusion object. Interesting rethink. I have always thought that a group would refer to events for their evidence. But with this idea, groups could be like events and persons in the DeadEnds model: they could be roots of trees of other group records representing a decision tree of inferences, conclusions and hypotheses. But again, why add a new object into the part of the model where the records will be the most numerous? I assume that any software that supports evidence will end up with a database in which there are more evidence person and event records than any other, and this idea assumes there will be as many evidence group records as evidence event records. What benefit does one get by complexifying the model and implementation in this case?

Tom Wetmore