Implementing persona support in Gramps

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Implementing persona support in Gramps

Nick Hall
On 03/02/16 18:48, Tim Lyons wrote:
> would be nice to have a single display that shows the main
> information about a person, and allows that information to be edited. For
> example, it could show events, children etc, and then it should be possible
> to edit and add without having to go into a separate editor. I have done a
> VERY quick and dirty Photoshop mock-up of what something like this might
> look like in:
>
> https://gramps-project.org/wiki/index.php?title=GEPS_034:_Improve_usability#Reduce_the_number_of_editors

I have written viewers to view data.  These enable me to display
information in a much more interesting way than the standard Gramps
interface.  When displaying events for a person, family events are
included as if they were individual events.  For non-primary roles, I
display the role and main participants of the event.  The source
citations are listed and their associated images are easily accessible.  
When displaying an event, I show all the participants with lists of
their attributes.

I generally want to add data one source at a time.  For structured
sources, I use the Form addons.  For unstructured sources, I have an
editor which allows me to create events and attributes.  This uses the
same data storage that the Forms use.  All objects created are linked to
a source citation.

This approach cuts down my use of the standard editors.

I made a prototype available a couple of years ago.  However, there
wasn't much interest so I just wrote something for myself.


Nick.


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implementing persona support in Gramps

enno
In reply to this post by Nick Hall
Nick,
How do we record source information?

The first step is transcription. We can identify information about people, events and the relationships between people in sources.  This can be stored in attributes of event reference and event objects.  I have been doing this since I first wrote the census addons in 2009, and it works quite well.  The Forms gramplet is really just a structured transcription editor.
As far as I'm concerned, the best place to record information about people is in person records. Anything else makes things more complicated, because you need a special viewer for those persons. In GEDCOM X, these persons are tagged as extracted, but Tom Wetmore has argued that that such is not really necessary, because there are other ways to recognize a persona.

The next step is interpretation.  From an age we can calculate a date range.  Given the text description of a place we can link to a place object.  We could also classify an event sub-type or occupation.  However, attributes only let us store text.  We really need the ability to store both the transcribed text and the interpretation.

What is the solution?

Take for example a residence in a baptism record.  The baptism event is the main event, and the residence is stored as text in the event reference objects of the mother and father.  There are a couple of options:

1. Create a residence event.
2. Create an additional hidden attribute to record the place handle.
IMO, an event is the easiest, even if there is no date. If needed, these events can also be tagged as extracted, to suppress their display in the event view.

Also consider the age and birth place attributes in a census record.  Do we really want to create multiple birth events?
We don't, but I think it's the easiest way.

My main priority is to create a tool that is useful and easy to use, but it would also be nice to integrate this neatly into Gramps.
I think that integration is the easiest if we use existing objects, and don't add anything that duplicates those for the sake of adding some sort of 'evidence' layer. Any extracted object can be considered evidence by nature, so there is no need for that layer.

The only thing you need in the model is a way to group persons as an alternative to merging. This will create an empty person that inherits data from all persons that you assume to be the same individual. You may feel a need to do the same for events.

When conflicts arise between inherited data items, one may decide to override these with a new item in the conclusion object itself.

That's all, model wise. You need a tree view for grouped persons, and maybe a similar one for events, and other objects that can be grouped into conclusions. This view needs to support more than 2 levels in case of a multi-tier model.

regards,

Enno


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implementing persona support in Gramps

Nick Hall
On 12/02/16 23:30, Enno Borgsteede wrote:

>> My main priority is to create a tool that is useful and easy to use,
>> but it would also be nice to integrate this neatly into Gramps.
> I think that integration is the easiest if we use existing objects,
> and don't add anything that duplicates those for the sake of adding
> some sort of 'evidence' layer. Any extracted object can be considered
> evidence by nature, so there is no need for that layer.
>
> The only thing you need in the model is a way to group persons as an
> alternative to merging. This will create an empty person that inherits
> data from all persons that you assume to be the same individual. You
> may feel a need to do the same for events.
>
> When conflicts arise between inherited data items, one may decide to
> override these with a new item in the conclusion object itself.
>
> That's all, model wise. You need a tree view for grouped persons, and
> maybe a similar one for events, and other objects that can be grouped
> into conclusions. This view needs to support more than 2 levels in
> case of a multi-tier model.

I suggested that we add links between people, allowing a person to
inherit from its component personae, but it didn't gain any support.

However, containing the personae within the event reference objects of a
person works quite well.  Unfortunately, the same approach doesn't work
for events.

Storing evidence of events in event objects is my preferred solution.  
Creating multiple residence events is useful, but it would be nice to
have the facility to aggregate them.  It would also be useful to be able
to aggregate several port of call events into a single voyage event.

Birth and death events are slightly different.   We only expect one real
birth and death event for a person.  Creating multiple birth events to
record evidence of the birth can have unwanted side-effects.  For
example, suppose we have a baptism source, but only evidence of the
birth from census returns.  In this case, the baptism could be more
useful than an approximate birth.  We need a way to distinguish the
reliability of an event.

The alternative is to create a pseudo-event stored in place and date
attributes.  A real event could always be created from a pseudo-event.

My latest data entry addons do a very good job for all types of source.


Nick.


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implementing persona support in Gramps

enno
Hi Nick,
> I suggested that we add links between people, allowing a person to
> inherit from its component personae, but it didn't gain any support.
Sad ...
> However, containing the personae within the event reference objects of a
> person works quite well.  Unfortunately, the same approach doesn't work
> for events.
This suggests that personae can't exist without a person, because
without a person you have no event reference objects. Is that true?
> Storing evidence of events in event objects is my preferred solution.
> Creating multiple residence events is useful, but it would be nice to
> have the facility to aggregate them.  It would also be useful to be able
> to aggregate several port of call events into a single voyage event.
Right. And that requires nesting/linking just like for personae. It's
what GEDCOM X allows for subjects in general, but I haven't seen it used
on FamilySearch yet.
> Birth and death events are slightly different.   We only expect one real
> birth and death event for a person.  Creating multiple birth events to
> record evidence of the birth can have unwanted side-effects.  For
> example, suppose we have a baptism source, but only evidence of the
> birth from census returns.  In this case, the baptism could be more
> useful than an approximate birth.  We need a way to distinguish the
> reliability of an event.
This reminds me of a comment by Tom Wetmore about facts vs. events. He
preferred to record events implied by records not describing the events
themselves as facts, i.e. embedded data, so that a structured
transcription doesn't contain more than 1 event. I understand the idea,
and Tony Proctor dis something similar by using eventlets, which are
events embedded in another structure, as opposed to ones that can be
referenced by ID. I'm hoping that I read that right.
> The alternative is to create a pseudo-event stored in place and date
> attributes.  A real event could always be created from a pseudo-event.
Indeed. A pseudo-event is like a fact then, right.
> My latest data entry addons do a very good job for all types of source.
I have never tried them, because reality is that I don't do any data
entry from sources, because I always paste the whole text of an indexed
record as a citation text, and I have loads of such texts from all sorts
of sites.

In the current state of my research, I would primarily use personae as a
means to display names as found in events, so that I can easily see that
my ancestor known as Jan Harmen Borgsteede was born as Johann Hermann
Borgstett, and was registered with loads of other variations at
different events. Linking sources to various names afterwards is a bit
of a nuisance now. In this case, personae are sort of an afterthought,
and they're only useful when they can be displayed in views and reports.

For future research, I really like to create personae attached to
events/records and group those under persons later, but on reading the
1st part of your message, it looks like such is not possible yet. Is
that right? With personae, I mean real objects that include the usual
person fields like name and vitals, not attributes that need special
interpretation to be presented like personae, if you know what I mean.

regards,

Enno


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implementing persona support in Gramps

Nick Hall
On 14/02/16 18:07, Enno Borgsteede wrote:
> For future research, I really like to create personae attached to
> events/records and group those under persons later, but on reading the
> 1st part of your message, it looks like such is not possible yet. Is
> that right? With personae, I mean real objects that include the usual
> person fields like name and vitals, not attributes that need special
> interpretation to be presented like personae, if you know what I mean.

Both the census and forms addons create personae, but with limitations.  
Source information is stored as attributes and only one event is created
per citation.  If a person contains information from only one citation,
then it can be considered to be a persona. The attribute bundles can be
moved between people.

I am currently experimenting with the best way to create "facts" or
"eventlets" from the source information.  They could be stored in events
or special hidden attributes.  The facts that I am particularly
interested are:  name, birth, residence, occupation and death.

The main problem is that Gramps does not have the facility to aggregate
events.  Creating multiple birth and death events is not ideal.


Nick.


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implementing persona support in Gramps

enno
Hi Nick,
Both the census and forms addons create personae, but with limitations.  
Source information is stored as attributes and only one event is created 
per citation.  If a person contains information from only one citation, 
then it can be considered to be a persona. The attribute bundles can be 
moved between people.
I never really tried the census add-on, because I don't have many cousins in the UK or US for whom the add-on could be useful, but on trying the forms one, I noticed that it creates an entry in the person table to show the person name etc.

The consequence of this as I see it is that if you have a sequence of census entries where the person has slightly different recorded names, you end up creating either multiple (conclusion) persons to store those name variants, or if you want to avoid that, you end up with census records that point to the same person, which leads to form data that is not true to the census itself. Is that right?

I am currently experimenting with the best way to create "facts" or 
"eventlets" from the source information.  They could be stored in events 
or special hidden attributes.  The facts that I am particularly 
interested are:  name, birth, residence, occupation and death.

The main problem is that Gramps does not have the facility to aggregate 
events.  Creating multiple birth and death events is not ideal.
If we don't want person and event hierarchies in the (conclusion) model, my preference is that all data coming from a source is stored inside the source or citation record, meaning that if you find a record like this one for my grandfather
Name Henricus Borgsteede
Gender Male
Birth Date 31 Mar 1879
Birthplace Amsterdam, Noord-Holland, Netherlands
Father's Name Franciscus Henricus Borgsteede
Father's Age 30y
Mother's Name Jacoba Cornelia Seijs
all lines are stored as source/citation attributes. One can do that for the real citation elements too:
Netherlands Births and Baptisms, 1564-1910
Indexing Project (Batch) Number C04336-5
System Origin Netherlands-EASy
GS Film number 253479
Reference ID akte 3033
For this to work, we would need to standardize attribute names of course, and make sure that this works in all languages, but that should not be much of a problem. The advantage of this is that no source data ends up in persons or events, so there is no confusion between the evidence and conclusion domains.

An alternative would be to put everything into a note that allows semantic mark-up. And in this particular case, which is a birth record on FamilySearh, that mark-up is already there as micro-data:

  <meta itemprop="type" content="http://gedcomx.org/Vital"/>
  <meta itemtype="name" content="Henricus Borgsteede"/>
  <meta itemtype="historicalCollection" content="Netherlands Births and Baptisms, 1564-1910"/>
  
      <data itemscope itemtype="http://schema.org/Person">
        <meta itemprop="name" content="Henricus Borgsteede"/>
        <meta itemprop="url" content="https://familysearch.org/ark:/61903/1:1:X1WW-CLF"/>
        <meta itemprop="gender" content="Male"/> 
                  <meta itemprop="birthDate" content="1879-03-31"/> 
                  <data itemprop="birthPlace" itemscope itemtype="http://schema.org/Place">
                    <data itemprop="address" itemscope itemtype="http://schema.org/PostalAddress">
                      <meta itemprop="name" content="Amsterdam, Noord-Holland, Netherlands"/>
                    </data>
                    <meta itemprop="name" content="Amsterdam, Noord-Holland, Netherlands"/>
                  </data>
      </data> 
      <data itemscope itemtype="http://schema.org/Person">
        <meta itemprop="name" content="Franciscus Henricus Borgsteede"/>
        <meta itemprop="url" content="https://familysearch.org/ark:/61903/1:1:X1WW-CLN"/>
        <meta itemprop="gender" content="Male"/> 
      </data> 
      <data itemscope itemtype="http://schema.org/Person">
        <meta itemprop="name" content="Jacoba Cornelia Seijs"/>
        <meta itemprop="url" content="https://familysearch.org/ark:/61903/1:1:X1WW-CLJ"/>
        <meta itemprop="gender" content="Female"/> 
      </data> 

It is not exactly complete, since the parents have no roles registered, but the person records are there, and could be parsed from the notes content, if we want. The FS persons shown here have no fields to distinguish given names and surnames, but I assume that we can find a solution for that.

What do you think about this?

regards,

Enno


------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implementing persona support in Gramps

Nick Hall
On 12/03/16 22:09, Enno Borgsteede wrote:

> I never really tried the census add-on, because I don't have many
> cousins in the UK or US for whom the add-on could be useful, but on
> trying the forms one, I noticed that it creates an entry in the person
> table to show the person name etc.
>
> The consequence of this as I see it is that if you have a sequence of
> census entries where the person has slightly different recorded names,
> you end up creating either multiple (conclusion) persons to store
> those name variants, or if you want to avoid that, you end up with
> census records that point to the same person, which leads to form data
> that is not true to the census itself. Is that right?
>

No.  Each person in each census can have a source name.  These names can
be viewed in event date order.  They are all tagged with a citation.

The current public version doesn't create conclusion names for you.


Nick.


------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implementing persona support in Gramps

Nick Hall
In reply to this post by enno
On 12/03/16 22:09, Enno Borgsteede wrote:
If we don't want person and event hierarchies in the (conclusion) model, my preference is that all data coming from a source is stored inside the source or citation record, meaning that if you find a record like this one for my grandfather
Name Henricus Borgsteede
Gender Male
Birth Date 31 Mar 1879
Birthplace Amsterdam, Noord-Holland, Netherlands
Father's Name Franciscus Henricus Borgsteede
Father's Age 30y
Mother's Name Jacoba Cornelia Seijs

This approach doesn't work well for census data.  You end up with attributes like "person 1 name", "person 1 age", "person 2 name", "person 2 age" etc...

I decided against this very early on.  Also, the attributes still only allow text to be stored.  I would prefer designing another format.


Nick.


------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implementing persona support in Gramps

Nick Hall
In reply to this post by enno
On 12/03/16 22:09, Enno Borgsteede wrote:
all lines are stored as source/citation attributes. One can do that for the real citation elements too:
Netherlands Births and Baptisms, 1564-1910
Indexing Project (Batch) Number C04336-5
System Origin Netherlands-EASy
GS Film number 253479
Reference ID akte 3033
For this to work, we would need to standardize attribute names of course, and make sure that this works in all languages, but that should not be much of a problem. The advantage of this is that no source data ends up in persons or events, so there is no confusion between the evidence and conclusion domains.


Hopefully FHISO will come up with a standard for this.  It should be quite easy to implement.


Nick.


------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Implementing persona support in Gramps

Nick Hall
In reply to this post by enno
On 12/03/16 22:09, Enno Borgsteede wrote:
  <meta itemprop="type" content="http://gedcomx.org/Vital"/>
  <meta itemtype="name" content="Henricus Borgsteede"/>
  <meta itemtype="historicalCollection" content="Netherlands Births and Baptisms, 1564-1910"/>
  
      <data itemscope itemtype="http://schema.org/Person">
        <meta itemprop="name" content="Henricus Borgsteede"/>
        <meta itemprop="url" content="https://familysearch.org/ark:/61903/1:1:X1WW-CLF"/>
        <meta itemprop="gender" content="Male"/> 
                  <meta itemprop="birthDate" content="1879-03-31"/> 
                  <data itemprop="birthPlace" itemscope itemtype="http://schema.org/Place">
                    <data itemprop="address" itemscope itemtype="http://schema.org/PostalAddress">
                      <meta itemprop="name" content="Amsterdam, Noord-Holland, Netherlands"/>
                    </data>
                    <meta itemprop="name" content="Amsterdam, Noord-Holland, Netherlands"/>
                  </data>
      </data> 
      <data itemscope itemtype="http://schema.org/Person">
        <meta itemprop="name" content="Franciscus Henricus Borgsteede"/>
        <meta itemprop="url" content="https://familysearch.org/ark:/61903/1:1:X1WW-CLN"/>
        <meta itemprop="gender" content="Male"/> 
      </data> 
      <data itemscope itemtype="http://schema.org/Person">
        <meta itemprop="name" content="Jacoba Cornelia Seijs"/>
        <meta itemprop="url" content="https://familysearch.org/ark:/61903/1:1:X1WW-CLJ"/>
        <meta itemprop="gender" content="Female"/> 
      </data> 

It is not exactly complete, since the parents have no roles registered, but the person records are there, and could be parsed from the notes content, if we want. The FS persons shown here have no fields to distinguish given names and surnames, but I assume that we can find a solution for that.

What do you think about this?

This would work as an import format.  Creating conclusion names and places from the source information may well require some human intervention, but Gramps could make a good guess.  I don't see a problem though.


Nick.


------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
12