From: David S. <st...@pr...> - 2022-09-24 19:07:58
|
Dear devs, I haven't seen any discussion about Gedcom 7 support on this list for a while. There is a [wiki page](https://gramps-project.org/wiki/index.php/GEDCOM_7_support) and a [feature request](https://gramps-project.org/bugs/view.php?id=12226), but is anybody actively working on it? I would be interested to look into it. Best, David -------------- next part -------------- An HTML attachment was scrubbed... |
From: <Emy...@ya...> - 2022-09-24 21:20:37
|
Has even a single tool begun to support GEDCOM7? I've seen no releases announcements or even mentions on roadmaps. The only sample code posted has been converters from 5.5.1 to 7.0 in C and java. And a parser in JavaScript. And they seem to have stagnated. https://gedcom.io/tools/ Although I am curious if the GEDZIP has any innovations we could roll into the organization of .gpkg archives. Right now our top level is very messy with media files. (And it lacks any metadata files to simplify archive management or distribution.) The GEDCOM steering committee reserved a couple of "manifest" filenames used in JAR format specification but go no further. -Brian On Sat, Sep 24, 2022 at 14:08, David Straub via Gramps-devel<gra...@li...> wrote: Dear devs, I haven't seen any discussion about Gedcom 7 support on this list for a while. There is a [wiki page](https://gramps-project.org/wiki/index.php/GEDCOM_7_support) and a [feature request](https://gramps-project.org/bugs/view.php?id=12226), but is anybody actively working on it? I would be interested to look into it. Best, David -------------- next part -------------- An HTML attachment was scrubbed... _______________________________________________ Gramps-devel mailing list Gra...@li... https://lists.sourceforge.net/lists/listinfo/gramps-devel -------------- next part -------------- An HTML attachment was scrubbed... |
From: Patrice L. <pat...@gm...> - 2022-09-25 08:46:26
|
I've seen the new Heredis release support gedcom 7 for imports https://www.heredis.com/en/new-features-2023/ Le sam. 24 sept. 2022, 23:21, Emyoulation--- via Gramps-devel < gra...@li...> a écrit : > Has even a single tool begun to support GEDCOM7? I've seen no releases > announcements or even mentions on roadmaps. > > The only sample code posted has been converters from 5.5.1 to 7.0 in C and > java. And a parser in JavaScript. And they seem to have stagnated. > > https://gedcom.io/tools/ > > > Although I am curious if the GEDZIP has any innovations we could roll into > the organization of .gpkg archives. Right now our top level is very messy > with media files. (And it lacks any metadata files to simplify archive > management or distribution.) The GEDCOM steering committee reserved a > couple of "manifest" filenames used in JAR format specification but go no > further. > > > -Brian > > On Sat, Sep 24, 2022 at 14:08, David Straub via Gramps-devel< > gra...@li...> wrote: Dear devs, > > I haven't seen any discussion about Gedcom 7 support on this list for a > while. There is a [wiki page]( > https://gramps-project.org/wiki/index.php/GEDCOM_7_support) and a > [feature request](https://gramps-project.org/bugs/view.php?id=12226), but > is anybody actively working on it? I would be interested to look into it. > > Best, > David > -------------- next part -------------- > An HTML attachment was scrubbed... > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > > -------------- next part -------------- > An HTML attachment was scrubbed... > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > -------------- next part -------------- An HTML attachment was scrubbed... |
From: <Emy...@ya...> - 2022-09-25 11:11:15
|
That's interesting! Reading down, it looks like they chose to make Heredis 2023 import GEDZIP but not export GEDCOM7. Still, at 20 Sep 2022, it is the first support being promoted. https://www.lcgsco.org/introducing-heredis-2023-a-major-new-update-for-both-windows-and-macintosh/ -Brian On Sun, Sep 25, 2022 at 3:46, Patrice Legoux<pat...@gm...> wrote: I've seen the new Heredis release support gedcom 7 for imports https://www.heredis.com/en/new-features-2023/ Le sam. 24 sept. 2022, 23:21, Emyoulation--- via Gramps-devel <gra...@li...> a écrit : Has even a single tool begun to support GEDCOM7? I've seen no releases announcements or even mentions on roadmaps. The only sample code posted has been converters from 5.5.1 to 7.0 in C and java. And a parser in JavaScript. And they seem to have stagnated. https://gedcom.io/tools/ Although I am curious if the GEDZIP has any innovations we could roll into the organization of .gpkg archives. Right now our top level is very messy with media files. (And it lacks any metadata files to simplify archive management or distribution.) The GEDCOM steering committee reserved a couple of "manifest" filenames used in JAR format specification but go no further. -Brian On Sat, Sep 24, 2022 at 14:08, David Straub via Gramps-devel<gra...@li...> wrote: Dear devs, I haven't seen any discussion about Gedcom 7 support on this list for a while. There is a [wiki page](https://gramps-project.org/wiki/index.php/GEDCOM_7_support) and a [feature request](https://gramps-project.org/bugs/view.php?id=12226), but is anybody actively working on it? I would be interested to look into it. Best, David -------------- next part -------------- An HTML attachment was scrubbed... _______________________________________________ Gramps-devel mailing list Gra...@li... https://lists.sourceforge.net/lists/listinfo/gramps-devel -------------- next part -------------- An HTML attachment was scrubbed... _______________________________________________ Gramps-devel mailing list Gra...@li... https://lists.sourceforge.net/lists/listinfo/gramps-devel -------------- next part -------------- An HTML attachment was scrubbed... |
From: <Emy...@ya...> - 2022-09-25 11:28:31
|
Doing import only seems like a safer strategy. Maybe we could try the same thing? The Gramps plug-in system has separate import and export types. If they had to be released in matched reciprocal plug-ins,there would only be 1 type. Those incompatible bits of GEDCOM7 that Paul noted could be stored as intact GEDCOM7 chunk notes. So that they are still available for a post-process should the Gramps data Model evolve. But the GEDZIP media attachments are of more immediate value. -Brian On Sun, Sep 25, 2022 at 6:11, Emyoulation--- via Gramps-devel<gra...@li...> wrote: That's interesting! Reading down, it looks like they chose to make Heredis 2023 import GEDZIP but not export GEDCOM7. Still, at 20 Sep 2022, it is the first support being promoted. https://www.lcgsco.org/introducing-heredis-2023-a-major-new-update-for-both-windows-and-macintosh/ -Brian On Sun, Sep 25, 2022 at 3:46, Patrice Legoux<pat...@gm...> wrote: I've seen the new Heredis release support gedcom 7 for imports https://www.heredis.com/en/new-features-2023/ Le sam. 24 sept. 2022, 23:21, Emyoulation--- via Gramps-devel <gra...@li...> a écrit : Has even a single tool begun to support GEDCOM7? I've seen no releases announcements or even mentions on roadmaps. The only sample code posted has been converters from 5.5.1 to 7.0 in C and java. And a parser in JavaScript. And they seem to have stagnated. https://gedcom.io/tools/ Although I am curious if the GEDZIP has any innovations we could roll into the organization of .gpkg archives. Right now our top level is very messy with media files. (And it lacks any metadata files to simplify archive management or distribution.) The GEDCOM steering committee reserved a couple of "manifest" filenames used in JAR format specification but go no further. -Brian On Sat, Sep 24, 2022 at 14:08, David Straub via Gramps-devel<gra...@li...> wrote: Dear devs, I haven't seen any discussion about Gedcom 7 support on this list for a while. There is a [wiki page](https://gramps-project.org/wiki/index.php/GEDCOM_7_support) and a [feature request](https://gramps-project.org/bugs/view.php?id=12226), but is anybody actively working on it? I would be interested to look into it. Best, David -------------- next part -------------- An HTML attachment was scrubbed... _______________________________________________ Gramps-devel mailing list Gra...@li... https://lists.sourceforge.net/lists/listinfo/gramps-devel -------------- next part -------------- An HTML attachment was scrubbed... _______________________________________________ Gramps-devel mailing list Gra...@li... https://lists.sourceforge.net/lists/listinfo/gramps-devel -------------- next part -------------- An HTML attachment was scrubbed... _______________________________________________ Gramps-devel mailing list Gra...@li... https://lists.sourceforge.net/lists/listinfo/gramps-devel -------------- next part -------------- An HTML attachment was scrubbed... |
From: Enno B. <enn...@gm...> - 2022-09-25 11:47:50
|
Op 24-09-2022 om 23:20 schreef Emyoulation--- via Gramps-devel: > Has even a single tool begun to support GEDCOM7? I've seen no releases announcements or even mentions on roadmaps. Yes, My Family Tree has it: https://chronoplexsoftware.com/myfamilytree/index.htm And when I read the blog, it seems that they introduced GEDCOM 7 support in 2021. OTOH, 'big' companies like RootsMagic don't even have a plan: https://community.rootsmagic.com/t/rm-official-statement-regarding-gedcom-7-0/38 This is the only statement that I can found on their Discourse forum. Enno |
From: Jan S. <jan...@ne...> - 2022-09-25 15:44:42
|
MacFamilyTree 10 <https://www.syniumsoftware.com/macfamilytree> seems to be able to export GEDCOM 7.0.3. I see no trace of import capability. I have no mac, so I cannot test it. Jan Den 2022-09-25 kl. 13:47, skrev Enno Borgsteede: > Op 24-09-2022 om 23:20 schreef Emyoulation--- via Gramps-devel: >> Has even a single tool begun to support GEDCOM7? I've seen no >> releases announcements or even mentions on roadmaps. > > Yes, My Family Tree has it: > > https://chronoplexsoftware.com/myfamilytree/index.htm > > And when I read the blog, it seems that they introduced GEDCOM 7 > support in 2021. > > OTOH, 'big' companies like RootsMagic don't even have a plan: > > https://community.rootsmagic.com/t/rm-official-statement-regarding-gedcom-7-0/38 > > > This is the only statement that I can found on their Discourse forum. > > Enno > > > > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel -------------- next part -------------- An HTML attachment was scrubbed... |
From: Nick H. <ni...@gr...> - 2022-09-25 16:29:31
|
On 24/09/2022 20:07, David Straub via Gramps-devel wrote: > I haven't seen any discussion about Gedcom 7 support on this list for a while. There is a [wiki page](https://gramps-project.org/wiki/index.php/GEDCOM_7_support) and a [feature request](https://gramps-project.org/bugs/view.php?id=12226), but is anybody actively working on it? I would be interested to look into it. Full Gedcom 7.0 support would be a large task. There has been a recent discussion about adding an additional gender option: https://gramps.discourse.group/t/additional-gender-options The current policy is that we don't want to deliberately break Gedcom compliance. So we should certainly look at situations where the latest standard clears up previous ambiguity. Changes to the data model should be discussed on this list first. I have suggested adding a date to attributes for example. Of course creating a new exporter or importer for Gedcom 7.0 is always an option. Are there any changes in particular that you would like to see in Gramps? Nick. |
From: David S. <st...@pr...> - 2022-09-25 19:01:36
|
Thanks all for the clarifications. Honestly I haven't looked enough into the differences between the specifications for v5 and v7, or at the current importer/exporter implementations, to understand what work needs to be done. Maybe I'll play around with parsing Gedcom 7 to better understand. For now I was only thinking about the (lossy) import/export to/from the current Gramps data format. David ------- Original Message ------- Nick Hall via Gramps-devel <gra...@li...> schrieb am Sonntag, 25. September 2022 um 18:13: > > > > On 24/09/2022 20:07, David Straub via Gramps-devel wrote: > > > I haven't seen any discussion about Gedcom 7 support on this list for a while. There is a wiki page and a feature request, but is anybody actively working on it? I would be interested to look into it. > > > Full Gedcom 7.0 support would be a large task. > > There has been a recent discussion about adding an additional gender option: > > https://gramps.discourse.group/t/additional-gender-options > > The current policy is that we don't want to deliberately break Gedcom > compliance. So we should certainly look at situations where the latest > standard clears up previous ambiguity. > > Changes to the data model should be discussed on this list first. I > have suggested adding a date to attributes for example. > > Of course creating a new exporter or importer for Gedcom 7.0 is always > an option. > > Are there any changes in particular that you would like to see in Gramps? > > > Nick. > > > > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Jan S. <jan...@ne...> - 2022-09-26 04:04:37
|
I would like the addition of support of media located on the Internet <https://github.com/gramps-project/gramps/pull/1200#issuecomment-857538398>. Jan Den 2022-09-25 kl. 18:13, skrev Nick Hall via Gramps-devel: > On 24/09/2022 20:07, David Straub via Gramps-devel wrote: >> I haven't seen any discussion about Gedcom 7 support on this list for >> a while. There is a [wiki >> page](https://gramps-project.org/wiki/index.php/GEDCOM_7_support) and >> a [feature >> request](https://gramps-project.org/bugs/view.php?id=12226), but is >> anybody actively working on it? I would be interested to look into it. > > Full Gedcom 7.0 support would be a large task. > > There has been a recent discussion about adding an additional gender > option: > > https://gramps.discourse.group/t/additional-gender-options > > The current policy is that we don't want to deliberately break Gedcom > compliance. So we should certainly look at situations where the > latest standard clears up previous ambiguity. > > Changes to the data model should be discussed on this list first. I > have suggested adding a date to attributes for example. > > Of course creating a new exporter or importer for Gedcom 7.0 is always > an option. > > Are there any changes in particular that you would like to see in Gramps? > > > Nick. > > > > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel -------------- next part -------------- An HTML attachment was scrubbed... |
From: Nick H. <ni...@gr...> - 2022-10-05 21:55:11
|
On 26/09/2022 05:04, Jan Skarvall wrote: > I would like the addition of support of media located on the Internet > <https://github.com/gramps-project/gramps/pull/1200#issuecomment-857538398>. > I've already made a first attempt at coding this. Nick. |
From: Nick H. <ni...@gr...> - 2022-09-26 15:47:42
|
On 25/09/2022 20:01, David Straub wrote: > For now I was only thinking about the (lossy) import/export to/from the current Gramps data format. There is a list of information lost in the Gedcom export here: https://gramps-project.org/wiki/index.php/Gramps_and_GEDCOM A lossless export with a corresponding import would give another backup option. I'm not sure how useful it would be for importing into other software. Nick. |
From: <Emy...@ya...> - 2022-09-26 17:38:38
|
There is a significant change in date ranges that looks like it might require a revision to our date validator. The ranges are now expected to be 'ordered' to be accepted as valid. So while the Gramps date validator will happily accept "bet 1900 and 1880" ; GEDCOM 7 requires the upper and lower values to be in the order: "bet 1880 and 1900". I wonder if their sample parsers understand B.C.E. date span orders correctly? Or those spanning the year zero? And is this new left-to-right bias going to cause compatibility problems in right-to-left writing systems? https://gedcom.io/migrate/ On Monday, September 26, 2022 at 10:47:56 AM CDT, Nick Hall via Gramps-devel <gra...@li...> wrote: On 25/09/2022 20:01, David Straub wrote: > For now I was only thinking about the (lossy) import/export to/from the current Gramps data format. There is a list of information lost in the Gedcom export here: https://gramps-project.org/wiki/index.php/Gramps_and_GEDCOM A lossless export with a corresponding import would give another backup option. I'm not sure how useful it would be for importing into other software. Nick. _______________________________________________ Gramps-devel mailing list Gra...@li... https://lists.sourceforge.net/lists/listinfo/gramps-devel -------------- next part -------------- An HTML attachment was scrubbed... |
From: <Emy...@ya...> - 2022-09-27 17:10:10
|
If Gramps get any traction in development of a GEDCOM7 or GEDZIP add-on, it ought to be submitted for the list at: https://www.familysearch.org/en/GEDCOM/implementation-progress On Mon, Sep 26, 2022 at 10:47, Nick Hall via Gramps-devel<gra...@li...> wrote: On 25/09/2022 20:01, David Straub wrote: > For now I was only thinking about the (lossy) import/export to/from the current Gramps data format. There is a list of information lost in the Gedcom export here: https://gramps-project.org/wiki/index.php/Gramps_and_GEDCOM A lossless export with a corresponding import would give another backup option. I'm not sure how useful it would be for importing into other software. Nick. _______________________________________________ Gramps-devel mailing list Gra...@li... https://lists.sourceforge.net/lists/listinfo/gramps-devel -------------- next part -------------- An HTML attachment was scrubbed... |
From: Christopher H. <cd...@em...> - 2022-10-04 02:55:23
|
Nick, So regarding the gender discussion, and data model change to add date to attributes and a new Gender attribute type, if we are going to update attributes Gedcom 7 throws everything and the kitchen sink in so what else should we consider adding? Place? Address? The free form Type field? Media list? Contact information? UID? Also not directly related, but since time is treated as a substructure of date it would seem the logical thing to do would be to extend the Gramps date object to include it. But then that raises questions as should it be a free form text field or structured hour, minute, seconds data? And if structured should it be included in date calculations? And what of approximations, like morning, afternoon, evening? But then I think they are so closely interrelated I imagine this topic must have been discussed and ruled against long ago? What are your thoughts and what would you like to see here? -Chris On Sun, 2022-09-25 at 17:13 +0100, Nick Hall via Gramps-devel wrote: > On 24/09/2022 20:07, David Straub via Gramps-devel wrote: > > I haven't seen any discussion about Gedcom 7 support on this list > > for a while. There is a [wiki > > page](https://gramps-project.org/wiki/index.php/GEDCOM_7_support) > > and a [feature > > request](https://gramps-project.org/bugs/view.php?id=12226), but is > > anybody actively working on it? I would be interested to look into > > it. > > Full Gedcom 7.0 support would be a large task. > > There has been a recent discussion about adding an additional gender > option: > > https://gramps.discourse.group/t/additional-gender-options > > The current policy is that we don't want to deliberately break Gedcom > compliance. So we should certainly look at situations where the > latest > standard clears up previous ambiguity. > > Changes to the data model should be discussed on this list first. I > have suggested adding a date to attributes for example. > > Of course creating a new exporter or importer for Gedcom 7.0 is > always > an option. > > Are there any changes in particular that you would like to see in > Gramps? > > > Nick. > > > > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel -------------- next part -------------- An HTML attachment was scrubbed... |
From: Nick H. <ni...@gr...> - 2022-10-05 22:07:43
|
On 04/10/2022 03:34, Christopher Horn wrote: > So regarding the gender discussion, and data model change to add date > to attributes and a new Gender attribute type, if we are going to > update attributes Gedcom 7 throws everything and the kitchen sink in > so what else should we consider adding? Place? Address? The free form > Type field? Media list? Contact information? UID? As far as gender is concerned, all we really need to do is add the fourth option corresponding to "X". We can use events for more details information. Enhancements to attributes would be a much bigger task. > > Also not directly related, but since time is treated as a substructure > of date it would seem the logical thing to do would be to extend the > Gramps date object to include it. But then that raises questions as > should it be a free form text field or structured hour, minute, > seconds data? And if structured should it be included in date > calculations? And what of approximations, like morning, afternoon, > evening? But then I think they are so closely interrelated I imagine > this topic must have been discussed and ruled against long ago? Gedcom 7.0 defines TIME and a PHRASE tag. We should use this standard unless we have a good reason not to. At the moment out advice is to use a "Time" attribute. > > What are your thoughts and what would you like to see here? > That depends on what features our users would like, and who we have to code them. If you are volunteering to code a feature, then I would be happy to work on a design with you. Nick. |
From: Nick H. <ni...@gr...> - 2022-10-05 22:14:23
|
On 05/10/2022 14:06, <hidden> wrote: > I would really love it if the first step could be to modify Gramps Import so that it accepts plug-ins. > > I have used the plug-in architecture for Gramps Export to implement an export for The GedView mobile app (which is excellent and includes all my media evidence of BMD and Census data), and have also done a small part of export to Heredis. But of course there is no plug-in architecture for Imports. Once that is done, maybe an import plug-in for Gedcom 7 could be done. > Yes. I totally agree. A new Gedcom 7.0 import would probably want to do something slightly different from the current import whilst still sharing most of the code. Nick. |
From: David S. <st...@pr...> - 2022-10-06 10:59:54
|
> A new Gedcom 7.0 import would probably want to do something slightly > different from the current import whilst still sharing most of the code. I'm interested in implementing a new standards compliant Gedcom 7 parser that I hope will be much simpler than the currently implemented parser; if/when I succeed, this could potentially form the basis of a Gramps import plugin. But I don't want to promise anything just yet, I'll keep you updated. David ------- Original Message ------- Nick Hall via Gramps-devel <gra...@li...> schrieb am Donnerstag, 6. Oktober 2022 um 00:14: > > > > On 05/10/2022 14:06, <hidden> wrote: > > > I would really love it if the first step could be to modify Gramps Import so that it accepts plug-ins. > > > > I have used the plug-in architecture for Gramps Export to implement an export for The GedView mobile app (which is excellent and includes all my media evidence of BMD and Census data), and have also done a small part of export to Heredis. But of course there is no plug-in architecture for Imports. Once that is done, maybe an import plug-in for Gedcom 7 could be done. > > Yes. I totally agree. > > A new Gedcom 7.0 import would probably want to do something slightly > different from the current import whilst still sharing most of the code. > > Nick. > > > > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |
From: Christopher H. <cd...@em...> - 2022-10-07 03:25:26
|
Yes, I am willing to try to put something together to enhance gender support. As I see it both sex and gender identity have always been attributes or characteristics of a person and not an event. Some people treat them interchangeably, some distinguish between them. Not everyone will agree on how to record things, or how things should be reported. My current thinking has changed some since the Discourse thread and would be to approach it as follows: Create a GenderType with enumerated types that align with the Gedcom standard for sex and that supports custom types and all that entails. Create a new Gender secondary object, of type GenderType, with date, citation and note lists. We might also want to allow for an association to a name or names somehow as well. Add a gender_list to Person that is a list of Gender objects. Add birth_sex_index, sex_index and gender_index to Person, so each an point to either the same or possibly different objects in gender_list, and retire __gender. The Person editor Gender field would work as it does today. The label would be renamed from Gender: to Birth Sex: to make it clearer what it is. Only the enumerated values would be permitted for selection. If a Gender object does not exist it is of course created and birth_sex_index, sex_index and gender_index set to reference it. So the existing work flow is preserved for the majority of our users. A button would be added to open a new Gender Editor for those who need it. The Gender Editor would have a top and bottom section. The top section would be a simple list of the gender records. Each row would include date, type label, a birth sex check box, a current sex check box, a gender check box, and the privacy lock. Only one check box of each type can ever be selected. Code enforces the restriction that only a Gender with a non-custom type can be a sex selection. The bottom section would contain the editing area for the row selected in the top section. Refactor all the code that currently uses the term "gender" to refer to "sex" to be clearer about the property being evaluated. For Gedcom imports/exports there would be get_birth_sex and set_birth_sex methods as that is the object they deal with. Almost everything else that today calls get_gender would be changed to call get_sex_type. That method would return an enum in same manner get_gender does today from whichever object sex_index points to. A has_gender method would return true if the gender_index pointed to a different object than the sex_index. Some reports could be updated to test and then include this additional information. Gramps import and export would need to be updated of course, and the database migration. That is about as far as I have thought about it, and I am sure there is a lot I have not thought of. It is also probably far more work than I realize. Would an approach like this be acceptable? -Chris On Wed, 2022-10-05 at 23:07 +0100, Nick Hall wrote: > On 04/10/2022 03:34, Christopher Horn wrote: > > So regarding the gender discussion, and data model change to add > > date > > to attributes and a new Gender attribute type, if we are going to > > update attributes Gedcom 7 throws everything and the kitchen sink > > in > > so what else should we consider adding? Place? Address? The free > > form > > Type field? Media list? Contact information? UID? > > As far as gender is concerned, all we really need to do is add the > fourth option corresponding to "X". > > We can use events for more details information. Enhancements to > attributes would be a much bigger task. > > > > > > Also not directly related, but since time is treated as a > > substructure > > of date it would seem the logical thing to do would be to extend > > the > > Gramps date object to include it. But then that raises questions > > as > > should it be a free form text field or structured hour, minute, > > seconds data? And if structured should it be included in date > > calculations? And what of approximations, like morning, afternoon, > > evening? But then I think they are so closely interrelated I > > imagine > > this topic must have been discussed and ruled against long ago? > > Gedcom 7.0 defines TIME and a PHRASE tag. We should use this > standard > unless we have a good reason not to. At the moment out advice is to > use > a "Time" attribute. > > > > > > What are your thoughts and what would you like to see here? > > > That depends on what features our users would like, and who we have > to > code them. If you are volunteering to code a feature, then I would > be > happy to work on a design with you. > > > Nick. > > -------------- next part -------------- An HTML attachment was scrubbed... |
From: Nick H. <ni...@gr...> - 2022-10-09 00:11:47
|
On 07/10/2022 04:25, Christopher Horn wrote: > Would an approach like this be acceptable? > I think that this approach is far too complicated. Sex and gender are attributes of a person and can probably be handled as such. I'm not sure that we really need a new editor. A date field on attributes would be useful though. We use the sex/gender of a person in a few ways: to display a colour in charts, to display a symbol in reports, and to determine pronouns in narrative text. Perhaps we need to store a few overrides for these practical purposes. I was just thinking of the comedian Eddie Izzard as an example, who currently identifies as genderfluid and prefers "she/her" pronouns. I'm also not sure that the Gedcom "Sex at birth" definition will necessarily be possible to determine in the future. What happens if the sex on a birth certificate is changed? So at the moment my thoughts are: 1. Add an extra "X" option to our current list, or use a GrampsType with custom values for this purpose. Any custom value would be regarded as "X". 2. Add a date field to attributes. 3. Add an override for preferred pronouns. We need to consider out translators for this. Nick. |
From: Christopher H. <cd...@em...> - 2022-10-09 05:59:08
|
> I'm also not sure that the Gedcom "Sex at birth" definition will > necessarily be possible to determine in the future. What happens if > the > sex on a birth certificate is changed? I agree, there are all kinds of issues around this kind of retroactive change. Many intersex people have been recorded as male or female for centuries so the information on a birth certificate or in a baptismal register has never necessarily been accurate in the first place. > I think that this approach is far too complicated. I agree it would add a lot of complexity. If we only have and recognize a single value though and the gender changes later and that is what the user recorded and is the data used in a Gedcom export then you are not being true to the intended meaning in that standard and in some sense are misrepresenting a fact. Maybe the user wants that and maybe they don't. I'm not saying what I proposed was the best solution, I'm not sure, but I think it attempted to be more accurate. > 1. Add an extra "X" option to our current list, or use a GrampsType > with > custom values for this purpose. Any custom value would be regarded > as "X". I shouldn't have tried collapsing the two types it muddies the water. If this single value is to stay and track with sex in Gedcom then I think adding custom types does not make sense and I think we need to rename gender to sex as leaving it causes confusion. Otherwise if someone puts in transgender, and they may be male but identify as female, using X is miscategorizing them. Or a male or female who puts in agender for that matter. Do you agree? A tooltip can be added explaining gender should be entered as an attribute. For existing Gedcom exports that do not support X I assume U should be used and something added to Gedcom export documentation that it is lossy in that regard. > 2. Add a date field to attributes. As I asked in my initial post, Gedcom 7 adds many possible things to attribute, so if I am updating attribute to add date should anything else be added at the same time? > 3. Add an override for preferred pronouns. We need to consider out > translators for this. I agree, this on the name record. There was a request to be able to flag dead names and treat them in a special manner as well. Should we try to accommodate that too? On Sun, 2022-10-09 at 01:11 +0100, Nick Hall wrote: > On 07/10/2022 04:25, Christopher Horn wrote: > > Would an approach like this be acceptable? > > > I think that this approach is far too complicated. > > Sex and gender are attributes of a person and can probably be handled > as > such. I'm not sure that we really need a new editor. A date field on > attributes would be useful though. > > We use the sex/gender of a person in a few ways: to display a colour > in > charts, to display a symbol in reports, and to determine pronouns in > narrative text. Perhaps we need to store a few overrides for these > practical purposes. I was just thinking of the comedian Eddie Izzard > as > an example, who currently identifies as genderfluid and prefers > "she/her" pronouns. > > I'm also not sure that the Gedcom "Sex at birth" definition will > necessarily be possible to determine in the future. What happens if > the > sex on a birth certificate is changed? > > So at the moment my thoughts are: > > 1. Add an extra "X" option to our current list, or use a GrampsType > with > custom values for this purpose. Any custom value would be regarded > as "X". > > 2. Add a date field to attributes. > > 3. Add an override for preferred pronouns. We need to consider out > translators for this. > > > Nick. > > -------------- next part -------------- An HTML attachment was scrubbed... |
From: Per S. <pe...@st...> - 2022-10-09 06:48:50
|
Nick Hall wrote: > We use the sex/gender of a person in a few ways: to display a colour in > charts, to display a symbol in reports, and to determine pronouns in > narrative text. [...] Also there are addons for filters like "Shares Y-DNA" which presumably uses the sex info there is, so maybe yet another consideration. (Or you can live with manually filtering exceptions out when you need something like that.) -------------- next part -------------- An HTML attachment was scrubbed... |
From: David S. <st...@pr...> - 2022-10-13 06:18:51
|
Hi, short update on the original topic of the thread: I' written a simple standalone Gedcom 7 parser: https://github.com/DavidMStraub/python-gedcom7. It's already listed on https://gedcom.io/tools/. Best, David ------- Original Message ------- Per Starbäck <pe...@st...> schrieb am Sonntag, 9. Oktober 2022 um 08:48: > > > > Nick Hall wrote: > > > > We use the sex/gender of a person in a few ways: to display a colour in > > charts, to display a symbol in reports, and to determine pronouns in > > narrative text. [...] > > > > Also there are addons for filters like "Shares Y-DNA" which presumably > uses the sex info there is, so maybe yet another consideration. (Or you can > live with manually filtering exceptions out when you need something like > that.) > -------------- next part -------------- > An HTML attachment was scrubbed... > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel |