Hi From BetterGEDCOM; and Methodology Questions
Locked
12
12
Hi From BetterGEDCOM; and Methodology Questions
 
|
Hi all,
I am one of the organizers behind BetterGEDCOM, and I actually have been trying to join this list for around a month. For some reason my join requests weren't doing anything, even though I was watching my email's spam filter carefully for some sort of response. Anyway, I'm here now, so what's done is done. Several of your members have been taking part in our discussions at bettergedcom.wikispaces.com, and I thought I would come here and ask a few questions about your data model and plans to accommodate the Genealogical Proof Standard (GPS) put forth by the Board For Certification Of Genealogists as well as other ways to embrace theories as opposed to conclusion-based data that is the norm in today's genealogy data. Some of our members are professional genealogists involved heavily in the efforts to codify the research process, and one of the long-term goals of BetterGEDCOM is to embrace the research process by codifying standards for what we have been calling the genealogical workspace which would be a software or service capable of documenting theory development and the writing of freeform theories and proof statements that comply with the best practices of professional genealogy today. Please keep in mind that we do not know that it is even possible to accommodate the above goal of codifying a genealogical workspace's elements within the same data model as one designed for use with today's genealogy software. Our first and foremost project is to devise a data model that is capable of mapping to today's genealogy software databases. It may be that the mere idea of theory development would radically change the structure of the data model, implying the software developers would need to change their data models substantially simply to be compatible with such concepts, and this we absolutely do not want. Your data model is very well developed, and in fact it could be something our data model ends up looking very much like. (We have agreed not to _begin_ with any previously existing work in our deliberations, no matter the source.) However, I am interested in what you have thought about the research process. Here are some objects that I have clumsily started with: Evidence-item=source for most folks Evidence-store = repository. Assertion=conclusion for most folks Theory functions like an intermediate item between evidence-item and assertion. Whereas an evidence-item is a thing (like a book or an interview), a Theory is an item which provides a way to develop ideas in more free-form fashion. A Theory in my mind is something cited in an Assertion (conclusion) but is not itself equivalent to an assertion. In the same way sources are standalone items that exist but are not assertions/conclusions, so are theories. The names are irrelevant. They're different just to make things a little separate. Call them George and Sally for all I care. Without reproducing several of the discussions over there, I am certainly interested to see what you guys have to say on issues related to the data model. I'll be looking through the archives as well, and I hope you'll come over there to help us along with our deliberations even if the issues aren't new to you guys. We're building broad-based support, and education is part of the process. Thanks, and I look forward to your comments. Greg Lamberson [hidden email] Build A BetterGEDCOM Genealogical Technology Standards Group http://bettergedcom.wikispaces.com/ Lamberson One-name Study Main website: http://freepages.genealogy.rootsweb.ancestry.com/~glamberson/ Blog: http://lambersongenealogy.wordpress.com/ Twitter: http://twitter.com/lambersonroots Genealogy wiki for collaboration: http://www.werelate.org/wiki/User:Glamberson ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
Re: Hi From BetterGEDCOM; and Methodology Questions
|
2010/11/12 Greg Lamberson <[hidden email]> Hi all, Hi, Gramps works with an internal storage, which is hard to change, and exchange formats, which are handled by plugins and can easily change (Gedcom, gramps-xml) Another exchange format would not be difficult to support, altough the mapping to our own data store might be messy in some cases (as is the case with Gedcom). Gramps now follows the idea of allowing to store every snippet of data you encounter, with most snippets allowing to attach a source to (the evidence). The source reference allows only 5 confidence levels, which is copied from GEDCOM. From what you say I take it you want to extend this more rigorously. I am all in favour, but doing that needs a broad basis, as diverging from GEDCOM is not something many users like. In other words, while extending things, a fallback to Gedcom must be worked out too so as to keep interoperability with those not moving to a new scheme. Some of our members are professional genealogists involved heavily in the Nice. Some interesting assertions between information will have to be stored. Main blocker here would be how fine grained the objects are, eg must date of an event have it's own evidence document? Like Gedcom, we now only provide for the entire event to have a source, but that makes proofs harder.
Our data model has grown from the Gedcom model though, which means it has it's problems. I think you will mainly find that Gedcom has quite some logic behind it :-) Should I start from scratch, I'd have some things which are very different from what Gramps has now. However, I am interested in what you have thought about the research process. Source in Gramps Evidence-store = repository. Repository in Gramps Assertion=conclusion for most folks Source Reference in Gramps, it holds 5 levels like Gedcom, which have their own meaning, Very Low = Unreliable or estimated Very High = Direct or primary evidence, dominance of the evidence See http://homepages.rootsweb.ancestry.com/~pmcbride/gedcom/55gcch2.htm#CERTAINTY_ASSESSMENT The extra fith in Gramps is the one when there is no QUAY tag in Gedcom Theory functions like an intermediate item between evidence-item and assertion. We have no support for this. I'd need to see practical examples to know what one wants to achieve here.
I'll try to keep an eye on the developments. Should you create a new datamodel, then please, store things as an xml schema, there are great libraries out there to parse xml. Once you have that, Gramps can easily function as a testcase to see how existing Gedcom can move to this format. Benny
------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
Re: Hi From BetterGEDCOM; and Methodology Questions
|
|
Hi, Thank you for the reply to my query. It's been a little crazy with our project just getting off the ground this week, and I apologize for not getting back to you sooner. I have anticipated that responding to this would be difficult because I didn't have the language to work out why the concepts mentioned below for source and evidentiary elements don't address the concerns some of our number are interested in. Now I think I can simply convey what I am interested in. Current genealogy software does not generally support the idea of why certain conclusions are drawn. There is no structural support for expressing or including information about analysis or proof statements or other deliberative items. These concepts
go far beyond a numeric grading system, and these are the concerns I am trying to get a handle on regarding GRAMPS (and other products and their data models). Frankly, the data objects that are likely to be needed to support these ideas fully may well break or seriously alter the structure needed by basically all of today's software products, or at least that is the conclusion some have drawn. We have considered support of these concepts a likely separate project, but we still need to delineate the concepts of conclusion-based research and concepts of theory and analysis. We're obviously still working out what this all means in terms of data relationships, but I hope this elaboration helps clarify what our interests are regarding a long-term data model. Regards, Greg Lamberson From: Benny Malengier <[hidden email]> To: Greg Lamberson <[hidden email]> Cc: [hidden email] Sent: Fri, November 12, 2010 9:01:07 AM Subject: Re: [Gramps-devel] Hi From BetterGEDCOM; and Methodology Questions 2010/11/12 Greg Lamberson <[hidden email]> Hi all, Hi, Gramps works with an internal storage, which is hard to change, and exchange formats, which are handled by plugins and can easily change (Gedcom, gramps-xml) Another exchange format would not be difficult to support, altough the mapping to our own data store might be messy in some cases (as is the case with Gedcom). Gramps now follows the idea of allowing to store every snippet of data you encounter, with most snippets allowing to attach a source to (the evidence). The source reference allows only 5 confidence levels, which is copied from GEDCOM. From what you say I take it you want to extend this more rigorously. I am all in favour, but doing that needs a broad basis, as diverging from GEDCOM is not something many users like. In other words, while extending things, a fallback to Gedcom must be worked out too so as to keep interoperability with those not moving to a new scheme. Some of our members are professional genealogists involved heavily in the Nice. Some interesting assertions between information will have to be stored. Main blocker here would be how fine grained the objects are, eg must date of an event have it's own evidence document? Like Gedcom, we now only provide for the entire event to have a source, but that makes proofs harder.
Our data model has grown from the Gedcom model though, which means it has it's problems. I think you will mainly find that Gedcom has quite some logic behind it :-) Should I start from scratch, I'd have some things which are very different from what Gramps has now. However, I am interested in what you have thought about the research process. Source in Gramps Evidence-store = repository. Repository in Gramps Assertion=conclusion for most folks Source Reference in Gramps, it holds 5 levels like Gedcom, which have their own meaning, Very Low = Unreliable or estimated Very High = Direct or primary evidence, dominance of the evidence See http://homepages.rootsweb.ancestry.com/~pmcbride/gedcom/55gcch2.htm#CERTAINTY_ASSESSMENT The extra fith in Gramps is the one when there is no QUAY tag in Gedcom Theory functions like an intermediate item between evidence-item and assertion. We have no support for this. I'd need to see practical examples to know what one wants to achieve here.
I'll try to keep an eye on the developments. Should you create a new datamodel, then please, store things as an xml schema, there are great libraries out there to parse xml. Once you have that, Gramps can easily function as a testcase to see how existing Gedcom can move to this format. Benny
------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
Re: Hi From BetterGEDCOM; and Methodology Questions
|
|
2010/11/14 Greg Lamberson <[hidden email]>
Hi Greg. I understand what you try to achieve. I work in mathematics, but I know only the very basics of automatic proofs (I'm in Analysis). Anyway, the sensible approach according to me is not a different datamodel, but instead a meta-information datamodel. It would be quite problematic implementation wise if one would need the actual data for all the proofs. So, one could instead store basic assertion, like person/Name/Surname - implied by - sourcekey with the requirement that all assertions follow from a source one way or the other. A theory then holds the rules about how one can work with assertions. Eg, the question if the Name follows from real sources, comes down to proving Is 'Person/Name' 'deductible' from primary sources? Which one can proof from its subitems. The problem lies in how fine-grained things must be. Do you need to have assertions for surname, given name, nick, or do you only want if for the entire name? Answering these questions allows you to know how a datamodel might have to change. Things must however remain manageable by a user, that is, as an application we must be rooted in a good user interface, not in a correct theory that is not practical. Benny
------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
Re: Hi From BetterGEDCOM; and Methodology Questions
|
2010/11/16 Benny Malengier <[hidden email]>
Well, primary sources are often wrong, either by mistake or by deliberate misstatements. I've seen many primary sources I don't believe in because they contradict other primary sources that say something different. They can't all be right, so you have to decide which version you believe or hold you decision till later.
I think the problem runs deeper. Many genealogy problems amount to: Is person P1 mentioned in document D1 the same person as P2 mentioned in D2? The data model needs to hold duplicate persons whose identity/sameness depends on whether you believe one theory or another. Likewise, the same person but with different parents, children or spouses. Some things can be modelled in GEDCOM, but in general it can only represent conflicting data about elementary facts (I use this extensively), conflicting descents are much harder to model (and document as such). Regards, Julio ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
In reply to this post by Benny Malengier
There has been some recent discussion about the datamodel in Gramps for Names (relating to the new input mechanisms for structured names) and places (again related to the structure of place names).
I would like to tie these thing together with datamodels for evidence. Specifically, if you are thinking of a new genealogy datamodel, every piece of evidence should be linked to the specific name found on that evidence, and then each name can be linked to a putative person. Similarly, it is important to record the place name (as shown on the evidence) separately from the place as we know it now. For example a relative (names changed for privacy) is recorded: On his birth certificate and marriage certificate he is Ernest Brian Hugo Lewis. On his children's birth certificates he is Ernest Hugh Lewis. He often called himself Hugh Ernest Lawrence Lewis (because of, not in spite of, the acronym) or Ernest Lawrence Lewis. He used the nom-de-plume Hugh Lawrence. Many other relatives are recorded as Ernest Lewis on the birth certificate, but appear as Ernest Brian Lewis on census records. At present, I have to record one of the names as the preferred name for the person. By default [in GRAMPS it happens], this would be the 'Birth Name', so this would be Ernest Lewis in the last example. Then I might record some of the other names as alternative names for the person. I might record a piece of evidence such as his marriage certificate, and record a transcript of that. I might link via an analysis or proof statement from the evidence to the 'person' as a conclusion. What seems to be missing is a mechanism to record the name as shown in the evidence in a structured way, not just as a transcript. So (in terms of how this might be practical), I input the transcript for the evidence in a structured way, and then might be prompted to say whether this name actually relates to some specific person that already exists in the database. Reasons for saying it is the same person might be prompted as 'age is consistent', 'birthplace is consistent' etc. Similar arguments apply to places. |
Re: Hi From BetterGEDCOM; and Methodology Questions
|
|
Tim,
This is the exact issue that Tom Wetmore of LifeLines fame has been getting at over at BetterGEDCOM and, separately, I have been working on and have posted this blog entry: http://genmadscientist.wordpress.com/2010/11/16/who-is-john-smith-adventures-in-genealogical-data-modeling/ Please review my entry. I think Tom is preparing something else on this right now, but I'm not exactly sure. I hope we can get together and work on this, as this is the crux of the matter, albeit we express it in different ways. Greg Lamberson ----- Original Message ---- From: Tim Lyons <[hidden email]> To: [hidden email] Sent: Tue, November 16, 2010 9:51:14 AM Subject: Re: [Gramps-devel] Hi From BetterGEDCOM; and Methodology Questions There has been some recent discussion about the datamodel in Gramps for Names (relating to the new input mechanisms for structured names) and places (again related to the structure of place names). I would like to tie these thing together with datamodels for evidence. Specifically, if you are thinking of a new genealogy datamodel, every piece of evidence should be linked to the specific name found on that evidence, and then each name can be linked to a putative person. Similarly, it is important to record the place name (as shown on the evidence) separately from the place as we know it now. For example a relative (names changed for privacy) is recorded: On his birth certificate and marriage certificate he is Ernest Brian Hugo Lewis. On his children's birth certificates he is Ernest Hugh Lewis. He often called himself Hugh Ernest Lawrence Lewis (because of, not in spite of, the acronym) or Ernest Lawrence Lewis. He used the nom-de-plume Hugh Lawrence. Many other relatives are recorded as Ernest Lewis on the birth certificate, but appear as Ernest Brian Lewis on census records. At present, I have to record one of the names as the preferred name for the person. By default [in GRAMPS it happens], this would be the 'Birth Name', so this would be Ernest Lewis in the last example. Then I might record some of the other names as alternative names for the person. I might record a piece of evidence such as his marriage certificate, and record a transcript of that. I might link via an analysis or proof statement from the evidence to the 'person' as a conclusion. What seems to be missing is a mechanism to record the name as shown in the evidence in a structured way, not just as a transcript. So (in terms of how this might be practical), I input the transcript for the evidence in a structured way, and then might be prompted to say whether this name actually relates to some specific person that already exists in the database. Reasons for saying it is the same person might be prompted as 'age is consistent', 'birthplace is consistent' etc. Similar arguments apply to places. -- View this message in context: http://gramps.1791082.n4.nabble.com/Hi-From-BetterGEDCOM-and-Methodology-Questions-tp3039612p3045071.html Sent from the GRAMPS - Dev mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
In reply to this post by Tim Lyons
Sources can be attached to each name in Gramps, not sure you're aware of that.
Still, genealogy would be at a terrible loss if people actually had to restrain the name they use to one of the documented version of the name. Your connection of "birth name" to "the name in the birth certificate" is a cruel one. Birth name is a simple concept, really, a name that doesn't include anything that couldn't be used from birth. --lcc On 11/16/10, Tim Lyons <[hidden email]> wrote: > > There has been some recent discussion about the datamodel in Gramps for > Names > (relating to the new input mechanisms for structured names) and places > (again related to the structure of place names). > > I would like to tie these thing together with datamodels for evidence. > > Specifically, if you are thinking of a new genealogy datamodel, every piece > of evidence should be linked to the specific name found on that evidence, > and then each name can be linked to a putative person. Similarly, it is > important to record the place name (as shown on the evidence) separately > from the place as we know it now. > > For example a relative (names changed for privacy) is recorded: > > On his birth certificate and marriage certificate he is Ernest Brian Hugo > Lewis. > On his children's birth certificates he is Ernest Hugh Lewis. > He often called himself Hugh Ernest Lawrence Lewis (because of, not in spite > of, the acronym) or Ernest Lawrence Lewis. > He used the nom-de-plume Hugh Lawrence. > Many other relatives are recorded as Ernest Lewis on the birth certificate, > but appear as Ernest Brian Lewis on census records. > > At present, I have to record one of the names as the preferred name for the > person. By default [in GRAMPS it happens], this would be the 'Birth Name', > so this would be Ernest Lewis in the last example. Then I might record some > of the other names as alternative names for the person. I might record a > piece of evidence such as his marriage certificate, and record a transcript > of that. I might link via an analysis or proof statement from the evidence > to the 'person' as a conclusion. > > What seems to be missing is a mechanism to record the name as shown in the > evidence in a structured way, not just as a transcript. So (in terms of how > this might be practical), I input the transcript for the evidence in a > structured way, and then might be prompted to say whether this name actually > relates to some specific person that already exists in the database. Reasons > for saying it is the same person might be prompted as 'age is consistent', > 'birthplace is consistent' etc. > > Similar arguments apply to places. > -- > View this message in context: > http://gramps.1791082.n4.nabble.com/Hi-From-BetterGEDCOM-and-Methodology-Questions-tp3039612p3045071.html > Sent from the GRAMPS - Dev mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today > http://p.sf.net/sfu/msIE9-sfdev2dev > _______________________________________________ > Gramps-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gramps-devel > ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
Re: Hi From BetterGEDCOM; and Methodology Questions
|
|
In reply to this post by Greg Lamberson
2010/11/16 Greg Lamberson <[hidden email]> Tim, Interesting. So you lean to a datamodel like: source - information in source - person Where then disconnecting a person from the source can undo all you added to the person as coming from that source (birth date, name, ...) An interesting concept, however, one that only very professional genealogist will be able to keep correct. One could see it a shadow or skeleton objects that hold the information learned from one source(part), and one source(part) alone, and then a real object is the merging of all skeleton objects, where the user can set priorities to what he deems is more correct (in case of conflicts). This would simplify some things I do not like in our present setup: connecting the same source over and over again to different parts of a person (as source of an attribute, of the name, of the person, of the event date, ...) It is doable but a major rewrite :-) One could envision the user to start with selecting and adding his source (eg from a certificate manager), creating snippets of information, and then collecting all this information is real tangible information. The real data must not be stored, it follows from the definition of the merging operation. It would be a hell of job to convert our present data to such a set-up, but I can see the benefit. Benny
------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
Benny's comment makes me realise that I am talking about two separate things: a theoretical datamodel for genealogical research, and the practical here and now datamodel. I suppose that my musings on a theoretical model could have been on one of the BetterGEDCOM sites, rather than here, but I wanted to respond to what was said here.
THEORETICAL DATAMODEL. I have had a look at this, but although it discusses some of the issues, the model does not seem right to me. It may however just be the way the model is presented. What I think is wrong is that the various references are all presented as subsidiary to the Person-name. This seems to already pre-judge the issue of whether all the documents actually refer to the same person. (I think there is the same problem in the reference presented elsewhere which argues about whether the age of a person is right in one document or another - the assumption seems to be made that the documents all refer to the same person). Now, I have lots of people called Able Brown, and a couple of them were born in the same year (I only have evidence for the year, not date in year). If I held a single Able Brown record, and linked them to the sources, I would have difficulty in deciding which referred to the same "actual real-life person". Instead, what I suggest is needed is a 'Person-name' entity which has a one-to-one relation with a source entity and a one-to-one relation with an "actual real-life person" entity. Having a 'Person-name' entity enables me to list these, and decide which relate to which "actual real-life person" entity. [Obviously, you can have other technical approaches so long as they achieve the same end.] PRACTICAL DATAMODEL For a practical datamodel, that is reasonably easily feasible to enter data into today, such as an implementation of GRAMPS, I think that current GEDCOM input and output are terribly important. With use of the internet comes much greater need to interchange genealogical data, and for this, GEDCOM is the only practical solution, and I think will remain so for quite some time to come. I think there are, and will be, many people who maintain their family tree on their home computer, and then want to export it to several different genealogical site. Also people want to import part or all of trees from various sites onto their own computer database. It is likely to be many many years (if ever) before another interface gets anywhere the same ubiquity as GEDCOM. [Sorry, BetterGEDCOM, to discourage you, and don't stop thinking about how genealogical research really works, and what can be done to improve record keeping, but given the current situation, I really think that it is so. Look at the longevity of the Windows interface, and the large number of copies of Windows GRAMPS that are downloaded (currently about 3 to 1 in favour of Windows). Windows is widely used and so is GEDCOM - it is difficult to supplant either whatever the problems of the existing interface or the merits of a new one.] As far as data input is concerned, I agree that we have to be very careful to ensure that GRAMPS is practical, and not "something that only a professional genealogist will be able to keep correct". I think that the current census gramplet is a very good example of how data input should proceed. You input the data from your source, and the data is distributed into the various GRAMPS records where it belongs. In the context of the discussion about names, there is a problem that it does not currently allow the recording of the name as it appears in the source document (but this could be fixed by adding the name as another field on the input and as another attribute in the GRAMPS database). It is true that the user determines the conclusion as to which "actual real-life person" entity is involved at the outset, but this is probably inevitable for a practical easy to use system. At least the data input mechanism records the main evidence that leads to the conclusion, if not a narrative description of why the conclusion was reached. |
Re: Hi From BetterGEDCOM; and Methodology Questions
|
|
Tim,
Thanks for your thoughtful responses. Let me clarify some things in light of your comments. Yes, we are absolutely talking about two separate things in terms of the present and the future. In fact, my questions related to the data model issue I raise regarding analysis, methodology, or whatever you prefer, are decidedly futuristic and not meant to reflect the project's immediate direction. I personally feel it is important to understand this issue and how it might fit into a data model in the future, but that's it. In fact, my own attempt at sketching out the problem was done as a direct result of conversations of some in our group and with Tom Wetmore. My feeble aforementioned blog entry was done as an exercise to assist in my own understanding, not to imply I have a handle on the issue or indeed any firm conclusions. My sketch in fact does not represent person entires but in fact represent database tables and not what the user would see. I think that, viewed with this explanation, you'll be able to see what I meant to express was the exact real-person:person-name:source relationship you mention. In practical terms, speaking for myself, I fully expect there to be programs importing and exporting GEDCOM for many years. It's a known quantity with near-ubiquitous adoption at some level. Why would developers abandon it, especially since the hard work on it is done? On the other hand, I think we can come up with a practical, workable improvement upon GEDCOM relatively quickly, but I'm not naive to think that such a new mechanism won't take a few years to catch on, even under the best of circumstances. Regarding the "person" issue and GRAMPS, I think there are others who would like to see further discussion on that particular item. Regarding the GRAMPS data model in general, your data model is certainly one which features prominently in many conversations as we advance towards coming up with one of our own. Thank you all very much for the extremely thorough and helpful responses to my inquiries. Greg Lamberson Co-organizer, BetterGEDCOM Project http://bettergedcom.wikispaces.com/ [hidden email] ----- Original Message ---- From: Tim Lyons <[hidden email]> To: [hidden email] Sent: Tue, November 16, 2010 6:50:00 PM Subject: Re: [Gramps-devel] Hi From BetterGEDCOM; and Methodology Questions Benny's comment makes me realise that I am talking about two separate things: a theoretical datamodel for genealogical research, and the practical here and now datamodel. I suppose that my musings on a theoretical model could have been on one of the BetterGEDCOM sites, rather than here, but I wanted to respond to what was said here. THEORETICAL DATAMODEL. Benny Malengier wrote: > > 2010/11/16 Greg Lamberson <[hidden email]> > >> Tim, >> >> This is the exact issue that Tom Wetmore of LifeLines fame has been >> getting >> at >> over at BetterGEDCOM and, separately, I have been working on and have >> posted >> this blog entry: >> >> >>http://genmadscientist.wordpress.com/2010/11/16/who-is-john-smith-adventures-in-genealogical-data-modeling/ >>/ >> >> >> Please review my entry. I think Tom is preparing something else on this >> right >> now, but I'm not exactly sure. I hope we can get together and work on >> this, >> as >> this is the crux of the matter, albeit we express it in different ways. >> > I have had a look at this, but although it discusses some of the issues, the model does not seem right to me. It may however just be the way the model is presented. What I think is wrong is that the various references are all presented as subsidiary to the Person-name. This seems to already pre-judge the issue of whether all the documents actually refer to the same person. (I think there is the same problem in the reference presented elsewhere which argues about whether the age of a person is right in one document or another - the assumption seems to be made that the documents all refer to the same person). Now, I have lots of people called Able Brown, and a couple of them were born in the same year (I only have evidence for the year, not date in year). If I held a single Able Brown record, and linked them to the sources, I would have difficulty in deciding which referred to the same "actual real-life person". Instead, what I suggest is needed is a 'Person-name' entity which has a one-to-one relation with a source entity and a one-to-one relation with an "actual real-life person" entity. Having a 'Person-name' entity enables me to list these, and decide which relate to which "actual real-life person" entity. [Obviously, you can have other technical approaches so long as they achieve the same end.] PRACTICAL DATAMODEL For a practical datamodel, that is reasonably easily feasible to enter data into today, such as an implementation of GRAMPS, I think that current GEDCOM input and output are terribly important. With use of the internet comes much greater need to interchange genealogical data, and for this, GEDCOM is the only practical solution, and I think will remain so for quite some time to come. I think there are, and will be, many people who maintain their family tree on their home computer, and then want to export it to several different genealogical site. Also people want to import part or all of trees from various sites onto their own computer database. It is likely to be many many years (if ever) before another interface gets anywhere the same ubiquity as GEDCOM. [Sorry, BetterGEDCOM, to discourage you, and don't stop thinking about how genealogical research really works, and what can be done to improve record keeping, but given the current situation, I really think that it is so. Look at the longevity of the Windows interface, and the large number of copies of Windows GRAMPS that are downloaded (currently about 3 to 1 in favour of Windows). Windows is widely used and so is GEDCOM - it is difficult to supplant either whatever the problems of the existing interface or the merits of a new one.] As far as data input is concerned, I agree that we have to be very careful to ensure that GRAMPS is practical, and not "something that only a professional genealogist will be able to keep correct". I think that the current census gramplet is a very good example of how data input should proceed. You input the data from your source, and the data is distributed into the various GRAMPS records where it belongs. In the context of the discussion about names, there is a problem that it does not currently allow the recording of the name as it appears in the source document (but this could be fixed by adding the name as another field on the input and as another attribute in the GRAMPS database). It is true that the user determines the conclusion as to which "actual real-life person" entity is involved at the outset, but this is probably inevitable for a practical easy to use system. At least the data input mechanism records the main evidence that leads to the conclusion, if not a narrative description of why the conclusion was reached. -- View this message in context: http://gramps.1791082.n4.nabble.com/Hi-From-BetterGEDCOM-and-Methodology-Questions-tp3039612p3046001.html Sent from the GRAMPS - Dev mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
In reply to this post by Greg Lamberson
Greg,
I suppose it is Tom's conclusions: http://bettergedcom.wikispaces.com/file/view/EvaluateGramps.pdf Regards, Jérôme --- En date de : Mar 16.11.10, Greg Lamberson <[hidden email]> a écrit : > De: Greg Lamberson <[hidden email]> > Objet: Re: [Gramps-devel] Hi From BetterGEDCOM; and Methodology Questions > À: [hidden email] > Date: Mardi 16 novembre 2010, 18h00 > Tim, > > This is the exact issue that Tom Wetmore of LifeLines fame > has been getting at > over at BetterGEDCOM and, separately, I have been working > on and have posted > this blog entry: > > http://genmadscientist.wordpress.com/2010/11/16/who-is-john-smith-adventures-in-genealogical-data-modeling/ > > > Please review my entry. I think Tom is preparing something > else on this right > now, but I'm not exactly sure. I hope we can get together > and work on this, as > this is the crux of the matter, albeit we express it in > different ways. > > Greg Lamberson > > ----- Original Message ---- > From: Tim Lyons <[hidden email]> > To: [hidden email] > Sent: Tue, November 16, 2010 9:51:14 AM > Subject: Re: [Gramps-devel] Hi From BetterGEDCOM; and > Methodology Questions > > > There has been some recent discussion about the datamodel > in Gramps for Names > (relating to the new input mechanisms for structured names) > and places > (again related to the structure of place names). > > I would like to tie these thing together with datamodels > for evidence. > > Specifically, if you are thinking of a new genealogy > datamodel, every piece > of evidence should be linked to the specific name found on > that evidence, > and then each name can be linked to a putative person. > Similarly, it is > important to record the place name (as shown on the > evidence) separately > from the place as we know it now. > > For example a relative (names changed for privacy) is > recorded: > > On his birth certificate and marriage certificate he is > Ernest Brian Hugo > Lewis. > On his children's birth certificates he is Ernest Hugh > Lewis. > He often called himself Hugh Ernest Lawrence Lewis (because > of, not in spite > of, the acronym) or Ernest Lawrence Lewis. > He used the nom-de-plume Hugh Lawrence. > Many other relatives are recorded as Ernest Lewis on the > birth certificate, > but appear as Ernest Brian Lewis on census records. > > At present, I have to record one of the names as the > preferred name for the > person. By default [in GRAMPS it happens], this would be > the 'Birth Name', > so this would be Ernest Lewis in the last example. Then I > might record some > of the other names as alternative names for the person. I > might record a > piece of evidence such as his marriage certificate, and > record a transcript > of that. I might link via an analysis or proof statement > from the evidence > to the 'person' as a conclusion. > > What seems to be missing is a mechanism to record the name > as shown in the > evidence in a structured way, not just as a transcript. So > (in terms of how > this might be practical), I input the transcript for the > evidence in a > structured way, and then might be prompted to say whether > this name actually > relates to some specific person that already exists in the > database. Reasons > for saying it is the same person might be prompted as 'age > is consistent', > 'birthplace is consistent' etc. > > Similar arguments apply to places. > -- > View this message in context: > http://gramps.1791082.n4.nabble.com/Hi-From-BetterGEDCOM-and-Methodology-Questions-tp3039612p3045071.html > > Sent from the GRAMPS - Dev mailing list archive at > Nabble.com. > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 > supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and > DOM L2 & L3. > Spend less time writing and rewriting code and more > time creating great > experiences on the web. Be a part of the beta today > http://p.sf.net/sfu/msIE9-sfdev2dev > _______________________________________________ > Gramps-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > > > > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 > supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and > DOM L2 & L3. > Spend less time writing and rewriting code and more > time creating great > experiences on the web. Be a part of the beta today > http://p.sf.net/sfu/msIE9-sfdev2dev > _______________________________________________ > Gramps-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gramps-devel > ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
Gramps users and devs,
Tom Wetmore has written an in-depth evaluation of Gramps in relation to the Evidence and Conclusion Process available here: http://bettergedcom.wikispaces.com/GRAMPS+Data+Model I think it accurately relays the situation, but if anyone knows of something that he missed, please post a note. Thanks! -Doug ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
About Evidence and related, someone made "GenTech-like" schemes.
Maybe this could help to understand the concept: * admin http://loic.fejoz.free.fr/gentechuml/AdministrativeSubmodel.pdf * conclusion http://loic.fejoz.free.fr/gentechuml/ConclusionalSubmodel.pdf * evidence http://loic.fejoz.free.fr/gentechuml/EvidenceSubmodel.pdf Jérôme --- En date de : Mer 17.11.10, Doug Blank <[hidden email]> a écrit : > De: Doug Blank <[hidden email]> > Objet: Re: [Gramps-devel] Hi From BetterGEDCOM; and Methodology Questions > À: [hidden email] > Cc: [hidden email] > Date: Mercredi 17 novembre 2010, 14h02 > Gramps users and devs, > > Tom Wetmore has written an in-depth evaluation of Gramps in > relation > to the Evidence and Conclusion Process available here: > > http://bettergedcom.wikispaces.com/GRAMPS+Data+Model > > I think it accurately relays the situation, but if anyone > knows of > something that he missed, please post a note. > > Thanks! > > -Doug > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 > supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and > DOM L2 & L3. > Spend less time writing and rewriting code and more > time creating great > experiences on the web. Be a part of the beta today > http://p.sf.net/sfu/msIE9-sfdev2dev > _______________________________________________ > Gramps-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gramps-devel > ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
In reply to this post by Greg Lamberson
[I appreciate that this might well not be what the user sees. I am not sure what distinction you are drawing between entities and rows in a database table. I take it that person-name is a database table, and each different Person-name-number belongs to a different row or entity in the table. You seem to use the term object type for database table. (And object for row or entity). However, this is not important; I think it is just different choices of word]. Well, not /quite/ what I had in mind. You show Person-name database tables which contain [references to] more than one source database table. This means that if it turns out that 'referenced in a birth record' and 'referenced in a marriage record' refer to different actual, real-life persons, then you have a problem. My suggestion was that each of your person-name objects should refer to at most one source, and to exactly one real-person object. In fact, I would not have Real-person-xxxnameyyy values in the real-person object at all. If I then asked 'what is the name of this real-person', I would reply that he is known as John Lester Smith, John Smith, Uncle John, and Johnny Smith (by following the 6 links to the person-name objects). I am not sure that there is any real sense in which I know that the real-person's name /is/ John Lester Smith. All I know is that in various places he is called various different things. (I suppose that for practical reasons, as well as the Ref=person-name array of references, you might also have a 'ref=person-display-name' to refer to the name that you wish to use when a single name is to be displayed. This might be Johnny Lester Smith, which is actually none of the Person-name objects, hence the need to allow zero source references in a Person-name object. BTW, this is not far-fetched, I have so many people with the same names in my tree, that I might well use a combination of names that I have not seen anywhere in the source to distinguish the person from others.) |
Re: Hi From BetterGEDCOM; and Methodology Questions
|
In reply to this post by Greg Lamberson
From [gramps-developers]
On 12/11/2010 13:50, Greg Lamberson wrote: > Hi all, > > I am one of the organizers behind BetterGEDCOM, and I actually have been trying > to join this list for around a month. <snip> > Without reproducing several of the discussions over there, I am certainly > interested to see what you guys have to say on issues related to the data model. > I'll be looking through the archives as well, and I hope you'll come over there > to help us along with our deliberations even if the issues aren't new to you > guys. We're building broad-based support, and education is part of the process. > > Thanks, and I look forward to your comments. > Greg Lamberson > [hidden email] From [gramps-users] On 01/12/2010 04:58, Simon Cropper wrote: > Hi, > > Sounds dumb but I can find any information on how immigration or emigration > events are coded. > > My family immigrated from England to Australia in the 60s. > > What type of event should I create... > > - Immigration Event : Place Australia? or Place England? > > - Emigration Event : Place Australia? or Place England? > > Ideally their should be a migration event where you state where you left and > where you went. No ambiguity! > better in a better GEDCOM? The current implementation of gramps seems not to allow you to connect two places. David Lynch ------------------------------------------------------------------------------ Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
Re: Hi From BetterGEDCOM; and Methodology Questions
|
The two events are connected through the person that experienced them.
On 12/1/10, David Lynch <[hidden email]> wrote: > From [gramps-developers] > On 12/11/2010 13:50, Greg Lamberson wrote: >> Hi all, >> >> I am one of the organizers behind BetterGEDCOM, and I actually have been >> trying >> to join this list for around a month. > <snip> >> Without reproducing several of the discussions over there, I am certainly >> interested to see what you guys have to say on issues related to the data >> model. >> I'll be looking through the archives as well, and I hope you'll come over >> there >> to help us along with our deliberations even if the issues aren't new to >> you >> guys. We're building broad-based support, and education is part of the >> process. >> >> Thanks, and I look forward to your comments. >> Greg Lamberson >> [hidden email] > From [gramps-users] > On 01/12/2010 04:58, Simon Cropper wrote: >> Hi, >> >> Sounds dumb but I can find any information on how immigration or >> emigration >> events are coded. >> >> My family immigrated from England to Australia in the 60s. >> >> What type of event should I create... >> >> - Immigration Event : Place Australia? or Place England? >> >> - Emigration Event : Place Australia? or Place England? >> >> Ideally their should be a migration event where you state where you left >> and >> where you went. No ambiguity! >> > Is this handled well in GEDCOM currently? Could it be handled > better in a better GEDCOM? The current implementation of gramps seems > not to allow you to connect two places. > > David Lynch > > > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > Gramps-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gramps-devel > -- Sent from my mobile device Gerald Britton ------------------------------------------------------------------------------ Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
In reply to this post by David Lynch-4
On Wed, Dec 1, 2010 at 3:46 AM, David Lynch
<[hidden email]> wrote: > From [gramps-developers] > On 12/11/2010 13:50, Greg Lamberson wrote: >> Hi all, >> >> I am one of the organizers behind BetterGEDCOM, and I actually have been trying >> to join this list for around a month. > <snip> >> Without reproducing several of the discussions over there, I am certainly >> interested to see what you guys have to say on issues related to the data model. >> I'll be looking through the archives as well, and I hope you'll come over there >> to help us along with our deliberations even if the issues aren't new to you >> guys. We're building broad-based support, and education is part of the process. >> >> Thanks, and I look forward to your comments. >> Greg Lamberson >> [hidden email] > From [gramps-users] > On 01/12/2010 04:58, Simon Cropper wrote: >> Hi, >> >> Sounds dumb but I can find any information on how immigration or emigration >> events are coded. >> >> My family immigrated from England to Australia in the 60s. >> >> What type of event should I create... >> >> - Immigration Event : Place Australia? or Place England? >> >> - Emigration Event : Place Australia? or Place England? >> >> Ideally their should be a migration event where you state where you left and >> where you went. No ambiguity! >> > Is this handled well in GEDCOM currently? Could it be handled > better in a better GEDCOM? The current implementation of gramps seems > not to allow you to connect two places. David, This situation is not specifically currently handled by any genealogy software that I know of. However, it is related (at least in my mind) to an idea that we have discussed before: a "relationship" [1]. Originally, we thought of a relationship as being a way of demarcating the beginning and ending of a marriage-like relationship. But perhaps this could be extended to capture any series of events that together form a single concept. As Gerald mentioned, most software has an implicit connection "through the person that experienced them". However, many consider that not enough. For example, if a person migrated from England to Australia, back to England, and then to the US, there is no way to tie each of those travel events into their beginnings and endings. This is more important for marriages, where a person can marry and divorce---even the same person---multiple times. Having a date attached to the events can help. But again, that is an implicit connection. A series of events could be grouped together, and each event can be marked as a "start" or "end". This could be used for lives, marriages, trips, residences, or other user-defined relationships. Gramps has some support for this kind of an idea already: we have the idea of a "fallback" event. For example, if there is no birth event, we can fallback to a baptism or christening events; for death we can fallback to burial, cremation, or cause of death events. A more general approach would allow a user-defined event to be an ending to the life set of events. However, these are just ideas at this point. -Doug [1] - http://gramps-project.org/wiki/index.php?title=GEPS_001:_Relationship_type_event_link > David Lynch > > > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > Gramps-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gramps-devel > ------------------------------------------------------------------------------ Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
Re: Hi From BetterGEDCOM; and Methodology Questions
|
|
2010/12/1 Doug Blank <[hidden email]> On Wed, Dec 1, 2010 at 3:46 AM, David Lynch One of the things in design phase has been the idea of an itinerary subevent. This has not been worked out however. Idea is that we need a way to show itineraries in Geoview. Using event subtype was an idea, so to do that with GEP 001, but perhaps another GEP is needed. Idea would then be eg: event Emigration, subtype Itinerary, and like that you can connect places. Problem is that that is not a real grouping. Benny
------------------------------------------------------------------------------ Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
|
|
In reply to this post by DS Blank
[I think Greg meant this to go to the entire list. -Doug]
---------- Forwarded message ---------- From: Greg Lamberson <[hidden email]> Date: Wed, Dec 1, 2010 at 3:16 PM Subject: Re: [Gramps-devel] Hi From BetterGEDCOM; and Methodology Questions Strictly speaking, Emigration is migrating out from a place. Immigrating is migrating into a place. The idea of migrating as, most pedantically, an event with two places makes me wonder where such data would be stored? Would one change the structure for all events to accommodate this? Would one simply create a new kind of entity or table in one's database to accommodate this? This is an issue that has come up. My questions as you can see relate to how valuable and difficult making such a change would be. The problem with this sort of change from BetterGEDCOM's point of view is that it's harder to do in the rest of the world that uses relational databases, to say nothing of the presentation problems (aka application issues far outside BetterGEDCOM's scope). Making the addition of another place option on an event would be, I think you guys will agree, easily done in XML. So basically, I'm back to the question: How valuable and pervasive is the need to have two-place events? Perhaps these questions gloss over the powerful idea of documenting migrations? Greg Lamberson [hidden email] Co-Organizer, BetterGEDCOM http://BetterGEDCOM.wikispaces.com/ ----- Original Message ---- From: Doug Blank <[hidden email]> To: David Lynch <[hidden email]> Cc: [hidden email] Sent: Wed, December 1, 2010 6:33:45 AM Subject: Re: [Gramps-devel] Hi From BetterGEDCOM; and Methodology Questions On Wed, Dec 1, 2010 at 3:46 AM, David Lynch <[hidden email]> wrote: > From [gramps-developers] > On 12/11/2010 13:50, Greg Lamberson wrote: >> Hi all, >> >> I am one of the organizers behind BetterGEDCOM, and I actually have been >trying >> to join this list for around a month. > <snip> >> Without reproducing several of the discussions over there, I am certainly >> interested to see what you guys have to say on issues related to the data >>model. >> I'll be looking through the archives as well, and I hope you'll come over >there >> to help us along with our deliberations even if the issues aren't new to you >> guys. We're building broad-based support, and education is part of the >process. >> >> Thanks, and I look forward to your comments. >> Greg Lamberson >> [hidden email] > From [gramps-users] > On 01/12/2010 04:58, Simon Cropper wrote: >> Hi, >> >> Sounds dumb but I can find any information on how immigration or emigration >> events are coded. >> >> My family immigrated from England to Australia in the 60s. >> >> What type of event should I create... >> >> - Immigration Event : Place Australia? or Place England? >> >> - Emigration Event : Place Australia? or Place England? >> >> Ideally their should be a migration event where you state where you left and >> where you went. No ambiguity! >> > Is this handled well in GEDCOM currently? Could it be handled > better in a better GEDCOM? The current implementation of gramps seems > not to allow you to connect two places. David, This situation is not specifically currently handled by any genealogy software that I know of. However, it is related (at least in my mind) to an idea that we have discussed before: a "relationship" [1]. Originally, we thought of a relationship as being a way of demarcating the beginning and ending of a marriage-like relationship. But perhaps this could be extended to capture any series of events that together form a single concept. As Gerald mentioned, most software has an implicit connection "through the person that experienced them". However, many consider that not enough. For example, if a person migrated from England to Australia, back to England, and then to the US, there is no way to tie each of those travel events into their beginnings and endings. This is more important for marriages, where a person can marry and divorce---even the same person---multiple times. Having a date attached to the events can help. But again, that is an implicit connection. A series of events could be grouped together, and each event can be marked as a "start" or "end". This could be used for lives, marriages, trips, residences, or other user-defined relationships. Gramps has some support for this kind of an idea already: we have the idea of a "fallback" event. For example, if there is no birth event, we can fallback to a baptism or christening events; for death we can fallback to burial, cremation, or cause of death events. A more general approach would allow a user-defined event to be an ending to the life set of events. However, these are just ideas at this point. -Doug [1] - http://gramps-project.org/wiki/index.php?title=GEPS_001:_Relationship_type_event_link > David Lynch > > > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > Gramps-devel mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/gramps-devel > ------------------------------------------------------------------------------ Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel ------------------------------------------------------------------------------ Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev _______________________________________________ Gramps-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gramps-devel |
«
Return to GRAMPS - Dev
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |