This @emyoulation post makes me thinking about this question.
I don’t have tried that tool but do you think Gramps documentation make possible to modify it to generate a gramps xml file instead of a gedcom file?
And to do that is there somewhere a mapping definition of fields [a Schema crosswalk] between them? More generally this mapping to gramps objects and gedcom objects (or familysearch objects), if it exists, could eventually be used to generate a xml file from any genealogy website or software if its fields can also be known, found or deducted.
Sorry, but I don’t see the point of using external tools to convert to Gramps XML? Gramps can import a gedcom and then output a Gramps XML. If Gramps does not do a good job on the import, wouldn’t it be best to fix whatever flaws it has rather than recreate a considerable amount of existing functionality?
The Form Gramplet and Form editor are baby steps towards an internal Swiss army knife of inbound ETL. As are the import & export plug-ins
The creation of internal & external ETL tools would create a healthy data exchange ecosystem for Gramps.
External products (complimentary and competitive) are NOT going to support the Gramps XML format if data can only be manipulated inside Gramps. That only seems like a way to siphon off their users.
Offhand, I could probably list a dozen ways such tools would directly help our community.
Sorry but I am not following you. Tools to bridge between rich data sources and Gramps sound wonderful. Tools to export Gramps in a form that can be used elsewhere are equally desirable. To me, however, Gramps XML has little to do with those scenarios.
AIUI, and perhaps I’m wrong, Gramps XML is a format that supports all the features of Gramps and no others. It provides the most compatible way to move data between different versions of Gramps.
I know gedcom has many problems but that is what we have. I haven’t explored GetMyAncestors in detail but I imagine it would be a very extensive re-write to change it to output Gramps XML. A re-write that would make it unusable to anyone but Gramps users. That’s why I suggest that if any fixes to gedcom import should be within Gramps since it is only of benefit to Gramps users.
Next, being an extensible and chunky format, the .gramps files can be enrichened by external applications for purposes beyond Gramps’ scope.
In the specific case of GetMyAncestors, a plumber’s nightmare Gramplet could create a wrapper for an un-forked GetMyAncestors. The Gramplet installer could include the entire External tool & dependencies. (To eliminate the installation woes.) It would require layering a GUI on top of their CLI functionality and some double-piping for the data. (Their GEDCOM output into a cache folder, which is sucked in through a preconfigured GEDCOM import)
Plumber’s Nightmares have a tendency to back up and spill sewage everywhere. So you’d want to run it with a blank Tree and then import the resulting .gramps into your main Tree. (So a bucket brigade along with that double-piping.)
-This is also why I earlier have tried to raise the question about interchangeable formats, but indirectly been called an idiot, demanding etc. for asking for it from some member of this forum.
Modifying GetMyAncestors to write Gramps XML is of course possible, and it has some advantages, like supporting more types of names than are covered in our current GEDCOM implementation, and even converting standardized place to a simple hierarchy. And that’s just a matter of reading the documentation, and sticking to the schema.
Note that, even though FamilySearch doesn’t use a lineage-linked model on-line, and GedcomX is not lineage-linked either, the Gramps XML must include families to be useful for current Gramps, so it will have to be lineage-linked.
The Family Tree Data Model
The purpose of this document is to help programmers become familiar with the data model of the FamilySearch Family Tree. The FamilySearch data model conforms to the GEDCOM X spec as much as possible. For more information, see the GEDCOM X guide.
The following graphic shows how data objects used in the FamilySearch Family Tree are associated. As the model illustrates, the core of the Family Tree data model are the individual persons that, linked together by relationships, create the Tree. The purpose of the other data objects is to give support and detailed information about the person, relationships and the research recorded in the Family Tree.
I think the starting assumption was that the data was not in Gramps yet and that no Import add-on existed yet either.
But one of the oversights that Gramps shares with other programs is the lack of an option to export an unexpected slice of its data. (Sometimes there a workaround with Reports or Category View exports to CSV. But this creates a parsing problem at the other end.)
The Export in Gramps is based on a Person as the slice criteria. If you want a different slice, you are currently out of luck.
For instance, you cannot to export (a part of; or, all of) a Place tree or a Repository or a Media collection. Even something a simple as a single Note cannot be exported. But even if a filter that wasn’t Person criteria was added, there are records that cannot designated by filtering. These include the items that cannot be directly addressed: internet records, addresses, LDS ordinances, alternate names.
Naturally, there would complications to exporting discrete records: include its secondary objects? include its hierarchy of enclosing objects?
But it is these kinds of oversights that creates a niche for external tools.
OK, got it. I thought that lineage linked meant connections between individuals and families, as used in Gramps and GEDCOM, but now that I read the GedcomX specification, which uses the same term for links between individuals, without families, I see that you’re right.
What other links would you consider then? Properties linked to persons? Group membership, like persons working in an organisation, or as members of a church, or other association?
I first started using Gramps as a Source Linked database. There was a 1924 reference booklet that was presented in such a dense & convoluted format that it was necessary to feed the data into a different format to grasp it. I chose Gramps and was hooked.
Years later, I’d like to output that chunk of genealogical data for others readers of that booklet. Unfortunately, extracting just the data supported by that reference is not an option.
One Place studies are place linked. Family Name studies are surname linked.
Unfortunately, the Export view doesn’t cover all the data for any Object, nor maintain the structured tree. You have to do too much reconstructive surgery on each export/import cycle.
And the data formatting doesn’t play well with the “comma” delimiter of CSV. (It might work better with TSV - ‘tab’ delimiters.) We use commas & double-quotes too much. (Particularly painful to exchange are: the lat/long format in degrees/minutes/seconds format instead of decimal; and the collated name & place fields.) It works better going out as .odt format but re-assembling the data after manipulating it is still ugly.
I thought I had a workaround for a few minutes by hanging objects on a Dummy person & exporting just that 1 person.
But there were a few glitches.
The initial experiment was very messy. It required hanging all the different object types on a Person… which meant each Place would need its own Event. And hanging all those Families on a dummy profile was nearly as bad.
Then I realized I could use a Note. Every linked object there would be carried along in the Export. And I’d only have to clean out the dummy person & dummy note after the import.
For the most part that worked… except that there is a bug where the export process double-filters the People. So every Person (& every Family) but the dummy person was dropped in the process. But all the other types of objects carried along as hoped!
That meant two smaller scope goals: 1) getting a bug fixed, and 2) having the view export to add a 3rd format (an internal alternative the existing external options of CSV & Open Office): output to a Gramps Note (either new or append to an existing)… where each ID has an internal link.
(Outputting a filtered view list to a Note has a LOT of other uses.)
