Quantcast

Hi From BetterGEDCOM; and Methodology Questions

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Hi From BetterGEDCOM; and Methodology Questions

Greg Lamberson
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hi From BetterGEDCOM; and Methodology Questions

Benny Malengier


2010/11/12 Greg Lamberson <[hidden email]>
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.

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
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.

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.

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.)

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.

Here are some objects that I have clumsily started with:

Evidence-item=source for most folks

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.
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.

We have no support for this. I'd need to see practical examples to know what one wants to achieve here.


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.

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
 

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


------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hi From BetterGEDCOM; and Methodology Questions

Greg Lamberson
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,

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.

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
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.

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.

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.)

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.

Here are some objects that I have clumsily started with:

Evidence-item=source for most folks

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.
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.

We have no support for this. I'd need to see practical examples to know what one wants to achieve here.


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.

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
 

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/%7Eglamberson/
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



------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hi From BetterGEDCOM; and Methodology Questions

Benny Malengier


2010/11/14 Greg Lamberson <[hidden email]>
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.

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

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,

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.

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
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.

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.

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.)

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.

Here are some objects that I have clumsily started with:

Evidence-item=source for most folks

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.
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.

We have no support for this. I'd need to see practical examples to know what one wants to achieve here.


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.

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
 

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/%7Eglamberson/

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



------------------------------------------------------------------------------
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



------------------------------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hi From BetterGEDCOM; and Methodology Questions

Julio Sánchez-2

2010/11/16 Benny Malengier <[hidden email]>


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?

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.
 
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.

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hi From BetterGEDCOM; and Methodology Questions

Tim Lyons
Administrator
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hi From BetterGEDCOM; and Methodology Questions

Greg Lamberson
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hi From BetterGEDCOM; and Methodology Questions

lcc .
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hi From BetterGEDCOM; and Methodology Questions

Benny Malengier
In reply to this post by Greg Lamberson


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.

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


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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hi From BetterGEDCOM; and Methodology Questions

Tim Lyons
Administrator
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 <lamberson@yahoo.com>

> 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hi From BetterGEDCOM; and Methodology Questions

Greg Lamberson
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hi From BetterGEDCOM; and Methodology Questions

jerome
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hi From BetterGEDCOM; and Methodology Questions

DS Blank
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hi From BetterGEDCOM; and Methodology Questions

jerome
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hi From BetterGEDCOM; and Methodology Questions

Tim Lyons
Administrator
In reply to this post by Greg Lamberson
Greg Lamberson wrote
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.
[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.)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hi From BetterGEDCOM; and Methodology Questions

David Lynch-4
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!
>
     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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hi From BetterGEDCOM; and Methodology Questions

Gerald Britton-2
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hi From BetterGEDCOM; and Methodology Questions

DS Blank
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Hi From BetterGEDCOM; and Methodology Questions

Benny Malengier


2010/12/1 Doug Blank <[hidden email]>
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.

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

-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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Fwd: Hi From BetterGEDCOM; and Methodology Questions

DS Blank
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
12
Loading...