Importing from Genbox - issues and best practice

[Moonlike]

But you can add citations to names, places, etc., so it’s more than just events.

I still don’t think it’s quite as fine-grained as Genbox, but in practical terms I doubt this is a great loss. TBH it was sometimes a pain clicking all of those boxes to create the citations for each data item on the event yet feeling my citations were misleading if I didn’t.

Thanks for the info re evidence. Again, the Genbox method was, if anything, a bit too comprehensive for my liking. It did make a lot of sense and it did make you think about exactly how far the evidence supported one’s conclusions but the downside was the effort required to use this system fully on each piece of information, which meant - in my case at least - it was often neglected. Poor practice on my part perhaps, but the source and the citation were recorded and there to see so it often seemed like overkill.

Conceptually I think there’s one other subtle but definite difference between the two apps, which is that Genbox is centered around a relational database and data structures - and that really shows in its functional design - whereas Gramps is built around object oriented data structures. It’s subtle and I certainly wouldn’t, at this stage, say one approach was better than the other. But clearly where there is any difference between data structures a migration process from one to another has to decide how to translate from one to the other which is where a lot of the interest arises!

[ennoborg]

@Moonlike

I still don’t think it’s quite as fine-grained as Genbox, but in practical terms I doubt this is a great loss. TBH it was sometimes a pain clicking all of those boxes to create the citations for each data item on the event yet feeling my citations were misleading if I didn’t.

You are absolutely right for the 1st part of that sentence, and the other part is up to you to decide on. The reality is, that Gramps is much closer to the data model used in GEDCOM 5.5.1 than to the Gentech data model that inspired Genbox, so if you move to Gramps, you will loose a lot of structure on the evidence side, although the data will be still there, in notes.

IMO, dealing with evidence should be no more difficult as it is on FamilySearch, where you match extracted persons with your tree, like I’m about to do here

where I can see this information about the source itself:

And I think that a good programmer can put this in 2 tabs, one for the citation, and another for the data. And in fact, you can do most of this with the forms Gramplet.

@Moonlike

Conceptually I think there’s one other subtle but definite difference between the two apps, which is that Genbox is centered around a relational database and data structures - and that really shows in its functional design - whereas Gramps is built around object oriented data structures. It’s subtle and I certainly wouldn’t, at this stage, say one approach was better than the other. But clearly where there is any difference between data structures a migration process from one to another has to decide how to translate from one to the other which is where a lot of the interest arises!

Well, as far as I’m concerned, this should not be visible at all, and if it does, the design is not that good. We have a plug-in that can convert our object orient data structures to a full relational database in SQLite, and back, so it’s more like a technical detail, and personal preference on the designer’s side. There are lots of tools to work with both, and right now, the real limitation that you need to deal with is, that a lot of evidence details will need to be moved to notes, or risk being lost.

What I mean is that to add all the details stored in Genbox, in a structured manner, we need to add some extra elements to our current objects, and some extra code to deal with new types of references, and a full relational program like RootsMagic would need extra tables to get the same results.

Without such changes, your best bets are our notes, and attributes. And notes are automatically created by our current import code. Importing custom tags to attributes would require changes in that same GEDCOM import code.

[Moonlike]

Noted @ennoborg, thanks.

@ennoborg

What I mean is that to add all the details stored in Genbox, in a structured manner, we need to add some extra elements to our current objects, and some extra code to deal with new types of references, and a full relational program like RootsMagic would need extra tables to get the same results.

Without such changes, your best bets are our notes, and attributes. And notes are automatically created by our current import code. Importing custom tags to attributes would require changes in that same GEDCOM import code.

I think these are key points. Whether it is worth any modification to Gramps structures (and import code) is the question, and IMO one that should be considered on a case by case basis as to whether it would bring any concrete advance to Gramps for a majority of users (as well as whether there is any appetite amongst the developers to make any such changes, or any appetite to deviate from gedcom standards and/or other widespread practice).

For example based on what you have said about evidence I could not see there being a strong case for changes. For other information the use of Gramps notes and attributes mitigates problems to an extent that depends on whether those notes (and note types if we use that as part of the mechanism) and attributes can be used in reports, charts etc in a a way that adequately matches how Genbox used that info. Also there may be good arguments for refactoring any such data to a form that Gramps handles natively (eg if Genbox is wildly out of line with widespread practice).

Unless and until any one of us finds something to the contrary I am making the working assumption that none of this represents a show-stopper for me; I have an amount of cleanup work to do anyway on my tree and at the moment I’m seeing these issues as just a bit more of that, not a big problem.

This discussion and conclusions has certainly clarified things in my mind, thank you.