I agree, and I saw that in DeadEnds and GEDCOM X. Did you mean those? They allow for a large hierarchy when people want that, or none at all when they don’t. And at least in GEDCOM X, you also have the possibily where a source is derived from another one, like when an index entry is derived from a record on film.
IMO, using the evidence model should be no more difficult than matching personae with persons on FamilySearch, which is something I do almost every day.
Here’s an example of dealing with evidence on FamilySearch:
… with data coming from this source:
And to my regret, there is no way to extract the source fields shown here from the page, because they aren’t tagged.
The Dutch open archives site has those fields, and you can see them in the page source at:
When you scroll down to the end of that source, you can see person and event data, and citation fields. And when you select another language at the top of the screen, you can see how all information, including the citation, is generated.
Yes. At some point you are going to have to decide if a person mentioned in a source is the same person as a person in your tree. To a lesser extent you will also have to match events where they have more then one source.
There are other steps that are also involved in an evidence model. When you first record information from a source, it is just a transcription. The researcher tries to record the information as accurately as possible.
The next step will involve interpretation of the data. This could be interpreting a date, or matching a place name to somewhere on a map. There could also be translation or transliteration involved.
Finally you get to the stage where information becomes evidence. You use the information to support a conclusion.
That FamilySearch has a vast catalog of databases indexed with subjects and facts tagged and ready to search and use takes a whole lot of work out of the equation. If Gramps had that it might be just as simple.
I’m pretty sure if a form of this evidence based submodel comes to pass, as I hope it will, that it will be a much smaller group of Gramps users using it.
I realize that, and I think it would be nice that if we have a table with evidence persons with names, and estimated birth dates, and so on, they could be matched with persons in the tree, with an algorithm that is similar to the duplicate persons search.
I have started a separate topic to discuss this:
The data need not be stored in a single or flat table. What is important is that it is structured so you can work with it and hopefully in a way so you don’t limit youself. I think the rest is just UI design and business logic at that point.
My experience is, that many times, I end up with a UI that is quite restrictive, in the sense that I have to use forms, where people with fewer principles use spreadsheets, in which it is easy to jump from one row to another. My late father did that, when he transcribed information from films in the archives, and I also know fellow genealogists who still distribute data that way.
Working with spreadsheets is easy, when your data can be organized in a few tables, where all data that you have found for a person can be stored in a single row. And most times it can, also if you do most your research on-line, because the number of fields in the archives’ databases are quite limited, and there are no repeating fields, meaning that a person never has more than one birth date, or place, and since most sources are tied to a single event, multiple date columns, like a birth and a death date, are also quite rare. They can exist, but even then, there is at most one birth and one death date in that kind of data.
I am assuming, but I can’t check, because the posts were removed, that the CSV files that StoltHD uses also represent flat tables, and I think that’s a valid approach. And I also have the experience that no software that I know has a grid control with the flexibility of a spreadsheet. You always run into some kind of (hidden) commit when you move to another row, so that the underlying database knows what is going on.
It might be possible to create better grid controls than we have in the attributes and person name editors, but I doubt that, so in the end, what I reaaly want is a two way interface, so that I can edit my evidence infomation in a spreadsheet, import it into Gramps, and export it again, to work on it in another location. And for that, it must at least be compatible with flat tables, for the persons, event, and citation.
This is how I see open data, and horizontal integration.
Have you looked GoldieMay yet? It is a commercial (with a free version) automation tool for research logging & analyzing your research process.
There is a research log CSV export that might be integrated.
This is how I do my research in Foam for VSC/Obsidian.
I have a huge amount of structured or unstructured data, e.g. a CSV file from a transcribed Census record, the CSV itself can be extremely large, maybe a million lines or more, I search the document, add markdown/wiki-links to any information I want to relate to any object, e.g. a Place, or a Person.
I can then just by clicking on that link create a new research note for the object of interest and start writing my findings, I usually have a hierarchy for my research journals.
A research Project can have multiple Research Journals, and the RJ for me has a minimum of 3 sub-object/classes/elements:
Research Project
When I have a conclusion, I then move my data to “the next level”, e.g., archiving it in Gramps, more research in other software if needed, creating a timeline in Aeon Timeline, etc.
Sadly, I can’t work with/utilize this workflow in Gramps… but it would have been great to been able to.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
