2012/5/30 Doug Blank <doug.blank@gmail.com>
On Tue, May 29, 2012 at 5:53 PM, Enno Borgsteede <ennoborg@gmail.com> wrote:

> What I was initially thinking about was to create hyperlinks from names
> in the text, that refer to new or existing persons in the tree, but with
> those you can't easily store link dates and places, so it's rather
> incomplete.

BTW, you can do something like that in Gramps since version 3.3. In
the notes editor, you can edit text, and put links to any of the main
objects in Gramps (person, family, place, media, events, etc). In that
manner, you can put together a narrative, with links to all the
components through the story.

These links become HTML links in the Narrated Web Report and in
http://Gramps-Connect.org/, the on-line version of gramps.

A combination of certificates and live-linking in notes could give a
close approximation to these ideas.

Yes, this was what I had in mind somewhat.

What would extra be needed in such 'certificate text':
* overlap of links. That is why I call it annotations. The same piece of text might be needed in different objects. So instead of showing it as a single underline, different colored underlines that on hover or so show an annotation text.
* the annotation text (link) is a combination of free text and link into an object.

Ok, just brainstorming now. Do pick the holes in the following. For example:

Certificate: 'John Doe, born on 14 Okt 1954.'

You link this to an existing source, or select that a new source must be created for it. You select John Doe, and click in the annotation part: Select existing person -> John Doe. This gives in the annotation part overview of known data that can be relevant, eg the existing birth event.
You then select 14 Okt 1954,  and you select birth event date.
You set confidence to high.

On save of the certificate, we store a certificate, with text and annotation, and update the normal objects with the new data (so here add a source of type birth record, source text, the name of the person is updated with a new citation, the existing birth event is changed to the new date and source citation is added). The user has the option to keep the old birth date (conclusion not applied), or overwrite it with the new one from this source (conclusion applied). The 'conclusions' are saved in the certificate as a timestamped 'diff' between old data and new data.

As all update of objects goes together with adding source citation, the source citation is the object that links back to the certificate ID. This allows to retrieve the conclusions.

Together with this, we then require a 'record' mode. In record mode, a certificate is openend, linked to an existing or new source, and one edits the normal gramps data. The open certificate records all changes to the data as diffs in the certificate. This as a way to use the conclusion system even when entering data the old way.

So, with such a structure, you can hope to undo a conclusion (undoing would not require to delete the conclusion, so a conclusion is applied or not applied).
You can also open a person, and see a list of all sources and source citations, and a list of all accompanying certificates. The sources and citations give you how the current information derives from sources, while the certificates give an overview via the diffs how the conclusion was reached. Eg, in the example you would see you made a birth event with a date, and later changed it to the new date based on what is in the certificate.

One might believe from above that source and certificate are 1-1, so we can merge them. I believe it is more like source-certificate is 1-n, so a source collects different parts. Question is if source citation -certificate is then n-1, and if those cannot be merged somehow. We should aim for a n-1 relation here, so not n-m. As a certificate holds the information that is changed in the other objects (to source extra text is added, to event a date, to person an extra citation for the name, ...) it should be a new object.

Obviously, storing changes done in the family tree like this, will really blow up the database. We can be clever however. When a new object is created, we only need to store the ID with no data. After that, we only need to store the old data from the changes. We can use the serialize function of the objects. So store the old data of the difference in serialized data.
A database upgrade would give a serious headache however, requiring an upgrade of the certificate data. In other words, somebody who has time to think this through should do the programming :-)
Obviously, everything becomes again more complicated.