Recommended layout/DB design?

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

Recommended layout/DB design?

Paul Smith

Is there some sort of recommended DB layout document?  I ask because last night I was fixing up some addresses (yes, as a new user I started using ‘addresses’ instead of ‘event, residence, census’) and I noticed that I could end up with:

 

Person

+- Event (residence, census)

   +- Citation

   +- Place

 

…or…

 

Person

+- Event (residence, census)

   +- Place

      +- Citation

 

…or…

 

Person

+- Event (residence, census)

   +- Citation

   +- Place

      +- Citation

 

So which is correct?  The design of the database should explain how we represent objects and how we expect them to

 

And is there perhaps a ‘recommended solutions’ type guide that might have sections like…

 

   ‘Added Census Data’

 

   We recommend that you add census data like this…

 

Thanks,

Paul

 

 

 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org
Reply | Threaded
Open this post in threaded view
|

Re: Recommended layout/DB design?

John W. Kitz-3
Paul,

On 2017-12-20 09:53, Paul Smith wrote:

> Is there some sort of recommended DB layout document?  I ask because
> last night I was fixing up some addresses (yes, as a new user I
> started using ‘addresses’ instead of ‘event, residence,
> census’) and I noticed that I could end up with:
>
> Person
>
> +- Event (residence, census)
>
>    +- Citation
>
>    +- Place
>
> …or…
>
> Person
>
> +- Event (residence, census)
>
>    +- Place
>
>       +- Citation
>
> …or…
>
> Person
>
> +- Event (residence, census)
>
>    +- Citation
>
>    +- Place
>
>       +- Citation
>
> So which is correct?

It has been stated a number of number of times on this list since I've
been subscribed to it; a lot of what one can do with Gramps depends on
personal preference, so I'm not aware of a single correct way of doing
this in Gramps let alone in genealogy, but I'm sure some have a
different opinion on that.

Having stated that AFAIK all three options mentioned by you are possible
in Gramps. To date, given the example, I'd prefer the first option,
since it makes the most sense to me to attach a citation 'as close as
possible' to what it pertains to.

I.e. a residence register, which is one of the sources I have used, says
something about the place of residence in time as it relates to any one
individual and not about the, in time more or less static, address
itself, as does the 2nd example you provide seems to do.

The 3rd example you provide I'd be inclined to use when trying to record
a combination of both, e.g. a residence event, with a reference to a
residence register attached as its source, as well as a place attached,
with in turn a citation attached with specific information about the
place itself.

> The design of the database should explain how we
> represent objects and how we expect them to
>
> And is there perhaps a ‘recommended solutions’ type guide that
> might have sections like…
>
>    ‘Added Census Data’
>
>    We recommend that you add census data like this…
>
> Thanks,
>
> Paul

Regards, Jk.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org
Reply | Threaded
Open this post in threaded view
|

Re: Recommended layout/DB design?

enno
In reply to this post by Paul Smith

Hello Paul,

Is there some sort of recommended DB layout document?  I ask because last night I was fixing up some addresses (yes, as a new user I started using ‘addresses’ instead of ‘event, residence, census’) and I noticed that I could end up with:

 

Person

+- Event (residence, census)

   +- Citation

   +- Place

 

…or…

 

Person

+- Event (residence, census)

   +- Place

      +- Citation

 

…or…

 

Person

+- Event (residence, census)

   +- Citation

   +- Place

      +- Citation

 

So which is correct?  The design of the database should explain how we represent objects and how we expect them to

Since all elements shown here sit in global tables, they can all be shared, so you should follow John's advice, meaning that you attach the citation to the object it pertains to.

This means that #1 is the recommended form, because in that, you attach the citation to the residence event itself. You can use #3 if you have some additional information about the place itself that can be shared by all events that reference that place.

It would be nice to be able to add separate citations for event date and place, but Gramps cannot do that. Citations apply to the event or the place, not to the event date or the event place, and that's a bit troublesome if you find a tombstone, which has dates, but no places.

Regards,

Enno


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org
Reply | Threaded
Open this post in threaded view
|

Re: Recommended layout/DB design?

John W. Kitz-3
Paul,

On 2017-12-20 12:14, Enno Borgsteede wrote:

> Hello Paul,
>
>> Is there some sort of recommended DB layout document?  I ask because
>> last night I was fixing up some addresses (yes, as a new user I
>> started using ‘addresses’ instead of ‘event, residence,
>> census’) and I noticed that I could end up with:
>>
>> Person
>>
>> +- Event (residence, census)
>>
>> +- Citation
>>
>> +- Place
>>
>> …or…
>>
>> Person
>>
>> +- Event (residence, census)
>>
>> +- Place
>>
>> +- Citation
>>
>> …or…
>>
>> Person
>>
>> +- Event (residence, census)
>>
>> +- Citation
>>
>> +- Place
>>
>> +- Citation
>>
>> So which is correct?  The design of the database should explain how
>> we represent objects and how we expect them to
>  Since all elements shown here sit in global tables, they can all be
> shared, so you should follow John's advice, meaning that you attach
> the citation to the object it pertains to.
>
> This means that #1 is the recommended form, because in that, you
> attach the citation to the residence event itself. You can use #3 if
> you have some additional information about the place itself that can
> be shared by all events that reference that place.
>
> It would be nice to be able to add separate citations for event date
> and place, but Gramps cannot do that. Citations apply to the event or
> the place, not to the event date or the event place, and that's a bit
> troublesome if you find a tombstone, which has dates, but no places.
>
> Regards,
>
> Enno

There's an additional benefit in doing it this way. Consider a couple
living at some address, every time they have a child you'll probably add
a residence event to the child, but you'll only have to add any citation
that may pertain to the place once, as opposed to having to do that for
every individual who at some point in time may reside at that place.

Regards, Jk.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org
Reply | Threaded
Open this post in threaded view
|

Re: Recommended layout/DB design?

Paul Smith
-----Original Message-----
From: John W. Kitz [mailto:[hidden email]]
Sent: 20 December 2017 11:23
To: [hidden email]
Subject: Re: [Gramps-users] Recommended layout/DB design?

Paul,

On 2017-12-20 12:14, Enno Borgsteede wrote:

> Hello Paul,
>
>> Is there some sort of recommended DB layout document?  I ask because
>> last night I was fixing up some addresses (yes, as a new user I
>> started using ‘addresses’ instead of ‘event, residence,
>> census’) and I noticed that I could end up with:
>>
>> Person
>>
>> +- Event (residence, census)
>>
>> +- Citation
>>
>> +- Place
>>
>> …or…
>>
>> Person
>>
>> +- Event (residence, census)
>>
>> +- Place
>>
>> +- Citation
>>
>> …or…
>>
>> Person
>>
>> +- Event (residence, census)
>>
>> +- Citation
>>
>> +- Place
>>
>> +- Citation
>>
>> So which is correct?  The design of the database should explain how
>> we represent objects and how we expect them to
>  Since all elements shown here sit in global tables, they can all be
> shared, so you should follow John's advice, meaning that you attach
> the citation to the object it pertains to.
>
> This means that #1 is the recommended form, because in that, you
> attach the citation to the residence event itself. You can use #3 if
> you have some additional information about the place itself that can
> be shared by all events that reference that place.
>
> It would be nice to be able to add separate citations for event date
> and place, but Gramps cannot do that. Citations apply to the event or
> the place, not to the event date or the event place, and that's a bit
> troublesome if you find a tombstone, which has dates, but no places.
>
> Regards,
>
> Enno

There's an additional benefit in doing it this way. Consider a couple living at some address, every time they have a child you'll probably add a residence event to the child, but you'll only have to add any citation that may pertain to the place once, as opposed to having to do that for every individual who at some point in time may reside at that place.

Regards, Jk.

Thanks John and Enno for nice clear examples,
Paul DS.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org
Reply | Threaded
Open this post in threaded view
|

data harmonization tips?

GRAMPS - User mailing list
I'm trying to clean non-printable characters out of some of my data and having difficulty with surnames. A method to find some non-printable characters is outlined after

When cutting & pasting data from webpages, Excel sheets, PDFs or Word docs, sometimes non-printable characters accidentally become embedded in the data fields of Gramps.  These include tabs (from tabular data), carriage returns and linefeeds.  Since Gramps does not have a visible placeholder for these non-printable characters in the data entry forms, the only way you can tell they exist is when they foul up the data interpretation or when you use the cursor control arrrow keys and the movement of the cursor stutters.

There are a few ways you might visibly notice GRAMPS data contaminated with non-printable characters.  The columnar views may have 2 rows for certain entries and surnames with non-printable characters are grouped separately from visibly identical surnames.  Also, if a common first name is not automatically recognized as "Male" or "Female" during data entry, it almost certainly is contaminated.

I use the Filter gramplet to find records that need to be cleaned.  By enabling the "Use Regular Expressions"  checkbox and searching for   \t   (tabs)  or  \l  (linefeeds)   or \r   (returns), for the Name in a People or Place record, you can identify records that need cleaning.   Since you cannot actually SEE the non-printable character, you have to use the cursor control keys (arrow left and arrow right) to find where the cursor doesn't move or cause a beep. Then delete/backspace to eliminate the non-printable character.

This technique is not completely effective.   Searching for an \e  (escape) or  \l  (linefeeds) in the Name field finds all records.

The worst flaw in the technique is that the Filter gramplet pre-processes the concatenated name fields. Apparently it filters the non-printable characters from all the fields but the Given. (The pre-processing also also the searches to be case insensistive...  thus allowing a search for 'smith' to find 'Smith', 'SMITH', or 'sMiTh')   So you can't find contaminated Surname, Nickname, Call, Title, Prefix, or Suffix  fields. 

I truly wish the filter had a second search pattern with an And/Or radio button.  It would be make it easier to find only the Smiths with a Joh (John, Johanes, Johannes) variant without requiring users to learn the RegEx pattern matching syntax.

The other wish is that GRAMPS had an option like Microsoft Word's "Show/Hide " feature.

What are your tips for Data validation/cleaning/harmonization?


Webpage on using RegEx to find non-printable characters


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org
Reply | Threaded
Open this post in threaded view
|

Re: data harmonization tips?

Dave Scheipers
I can answer at least one of your questions.

Filtering for And/or

You need to create a filter that you will run from the Sidebar Filter
"Custom Filter" drop down list.

Each database area has under the edit menu a Filter Editor. In the
Define filter screen that lists all of the conditions of the filter,
there is a drop-down list. The default is "All Rules Must Apply".
Change that to "At least one rule must apply". The third option is
"Exactly one rule must apply".

Additionally, should you need it, there is a check box to select for
the opposite records defined by the filter.

https://gramps-project.org/wiki/index.php?title=Gramps_4.2_Wiki_Manual_-_Filters#Define_Filter_dialog

Hope this helps, Dave

On Wed, Dec 20, 2017 at 2:04 PM, Emyoulation--- via Gramps-users
<[hidden email]> wrote:

> I'm trying to clean non-printable characters out of some of my data and
> having difficulty with surnames. A method to find some non-printable
> characters is outlined after
>
> When cutting & pasting data from webpages, Excel sheets, PDFs or Word docs,
> sometimes non-printable characters accidentally become embedded in the data
> fields of Gramps.  These include tabs (from tabular data), carriage returns
> and linefeeds.  Since Gramps does not have a visible placeholder for these
> non-printable characters in the data entry forms, the only way you can tell
> they exist is when they foul up the data interpretation or when you use the
> cursor control arrrow keys and the movement of the cursor stutters.
>
> There are a few ways you might visibly notice GRAMPS data contaminated with
> non-printable characters.  The columnar views may have 2 rows for certain
> entries and surnames with non-printable characters are grouped separately
> from visibly identical surnames.  Also, if a common first name is not
> automatically recognized as "Male" or "Female" during data entry, it almost
> certainly is contaminated.
>
> I use the Filter gramplet to find records that need to be cleaned.  By
> enabling the "Use Regular Expressions"  checkbox and searching for   \t
> (tabs)  or  \l  (linefeeds)   or \r   (returns), for the Name in a People or
> Place record, you can identify records that need cleaning.   Since you
> cannot actually SEE the non-printable character, you have to use the cursor
> control keys (arrow left and arrow right) to find where the cursor doesn't
> move or cause a beep. Then delete/backspace to eliminate the non-printable
> character.
>
> This technique is not completely effective.   Searching for an \e  (escape)
> or  \l  (linefeeds) in the Name field finds all records.
>
> The worst flaw in the technique is that the Filter gramplet pre-processes
> the concatenated name fields. Apparently it filters the non-printable
> characters from all the fields but the Given. (The pre-processing also also
> the searches to be case insensistive...  thus allowing a search for 'smith'
> to find 'Smith', 'SMITH', or 'sMiTh')   So you can't find contaminated
> Surname, Nickname, Call, Title, Prefix, or Suffix  fields.
>
> I truly wish the filter had a second search pattern with an And/Or radio
> button.  It would be make it easier to find only the Smiths with a Joh
> (John, Johanes, Johannes) variant without requiring users to learn the RegEx
> pattern matching syntax.
>
> The other wish is that GRAMPS had an option like Microsoft Word's "Show/Hide
> ¶" feature.
>
> What are your tips for Data validation/cleaning/harmonization?
>
>
> Webpage on using RegEx to find non-printable characters
> https://www.regular-expressions.info/nonprint.html
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Gramps-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-users
> https://gramps-project.org

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org
Reply | Threaded
Open this post in threaded view
|

Re: Recommended layout/DB design?

John W. Kitz-3
In reply to this post by Paul Smith
Enno,

---- 8< ----

Earlier today you wrote:

> Citations apply to the event or the
> place, not to the event date or the event place, and that's a bit
> troublesome if you find a tombstone, which has dates, but no places.
>
> Regards,
>
> Enno

Which I don't quite understand since the dates found on a tombstone are
typically the dates that one would enter in Gramps as the dates
associated with the birth and death events respectively.

In addition IMHO the combination of a grave and tombstone can be thought
of as a place known by the combination of some designation (e.g. row
such-and-such, grave no. xyz), in the records of a graveyard used by the
caretakers of a graveyard to identify an individual grave, and the
address (of the form street no., city, area, country) of the grave yard,
which could even be entered using the time dependent place expansion
options that Gramps provides should that be useful.

Regards, Jk.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org
Reply | Threaded
Open this post in threaded view
|

Re: data harmonization tips?

paul womack
In reply to this post by GRAMPS - User mailing list
Emyoulation--- via Gramps-users wrote:
> I'm trying to clean non-printable characters out of some of my data and having difficulty with surnames. A method to find some non-printable characters is outlined after

This regexp matches strings composed of only "plain" characters, with optional
spaces in them.

^[-a-zA-Z ]+(\s*[-a-zA-Z ]+)?$


If you use this in the "People with the <name> Rule (and tick the use regular expressions box), and set the Filter to "return values that do not match the filter rules"
you should see your "bad" data.

  BugBear


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org
Reply | Threaded
Open this post in threaded view
|

Re: Recommended layout/DB design?

enno
In reply to this post by John W. Kitz-3
Op 20-12-17 om 22:08 schreef John W. Kitz:

> Enno,
>
> ---- 8< ----
>
> Earlier today you wrote:
>
>> Citations apply to the event or the
>> place, not to the event date or the event place, and that's a bit
>> troublesome if you find a tombstone, which has dates, but no places.
>>
>> Regards,
>>
>> Enno
>
> Which I don't quite understand since the dates found on a tombstone
> are typically the dates that one would enter in Gramps as the dates
> associated with the birth and death events respectively.
What I mean is that when you find information like this on a tombstone,
they are not the full event information, but just parts of that, or
'facts', and in an ideal data model, citations should be attached to the
individual facts, not to the whole event.

When I find cousins on grave sites, the facts that I see are loose
elements, like the person's common name, birth and death dates, but no
places, except for the place where the person was buried, or cremated,
if the object found is an urn.

In many cases, these are cousins that have died less than 50 years ago,
meaning that their death records are not available on the archive sites,
and there is no easy way to find out where they died, except asking
other cousins, if available. In many cases, people are buried in the
community where they happened to live, but that doesn't mean that they
died there. My father died in hospital, for instance, and that hospital
was way out of town.

For such occasions, I would think that the ideal object to attach the
citation to is the date, and not the whole event, so that, once I do
find out about the place, I can add that, with a proper citation
attached to the event place, which is not the place itself, because that
may be shared with other events.

Attaching citations to these 'facts' makes it easier to trace where
individual parts of information have their origins, like dates on
tombstones, which may very well be wrong, because they are not
authorized by an official. Same for event places, which may also come
from people's memories.

>
> In addition IMHO the combination of a grave and tombstone can be
> thought of as a place known by the combination of some designation
> (e.g. row such-and-such, grave no. xyz), in the records of a graveyard
> used by the caretakers of a graveyard to identify an individual grave,
> and the address (of the form street no., city, area, country) of the
> grave yard, which could even be entered using the time dependent place
> expansion options that Gramps provides should that be useful.
One can do that indeed, but I don't. When I find a grave on-line, I
always use the location of the grave yard itself, and add the grave
number in the citation.

Regards,

Enno


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org
Reply | Threaded
Open this post in threaded view
|

Re: data harmonization tips?

enno
In reply to this post by paul womack
Op 21-12-17 om 10:07 schreef paul womack:

> Emyoulation--- via Gramps-users wrote:
>> I'm trying to clean non-printable characters out of some of my data
>> and having difficulty with surnames. A method to find some
>> non-printable characters is outlined after
>
> This regexp matches strings composed of only "plain" characters, with
> optional
> spaces in them.
>
> ^[-a-zA-Z ]+(\s*[-a-zA-Z ]+)?$
>
>
> If you use this in the "People with the <name> Rule (and tick the use
> regular expressions box), and set the Filter to "return values that do
> not match the filter rules"
> you should see your "bad" data.
Trouble is that this filter does not work for foreign characters which
are perfectly printable, but not part of the regular ASCII alphabet. Do
you know a cure for that?

Enno


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org
Reply | Threaded
Open this post in threaded view
|

Re: data harmonization tips?

paul womack
Enno Borgsteede wrote:

> Op 21-12-17 om 10:07 schreef paul womack:
>> Emyoulation--- via Gramps-users wrote:
>>> I'm trying to clean non-printable characters out of some of my data and having difficulty with surnames. A method to find some non-printable characters is outlined after
>>
>> This regexp matches strings composed of only "plain" characters, with optional
>> spaces in them.
>>
>> ^[-a-zA-Z]+(\s*[-a-zA-Z]+)?$
>>
>>
>> If you use this in the "People with the <name> Rule (and tick the use regular expressions box), and set the Filter to "return values that do not match the filter rules"
>> you should see your "bad" data.
> Trouble is that this filter does not work for foreign characters which are perfectly printable, but not part of the regular ASCII alphabet. Do you know a cure for that?
https://docs.python.org/3/library/re.html

using \w instead of [-a-zA-Z]

may do what you want.

  BugBear

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org
Reply | Threaded
Open this post in threaded view
|

Re: Recommended layout/DB design?

John W. Kitz-3
In reply to this post by enno
Enno,

On 2017-12-21 12:10, Enno Borgsteede wrote:

> In many cases, these are cousins that have died less than 50 years
> ago, meaning that their death records are not available on the archive
> sites, and there is no easy way to find out where they died, except
> asking other cousins, if available. In many cases, people are buried
> in the community where they happened to live, but that doesn't mean
> that they died there. My father died in hospital, for instance, and
> that hospital was way out of town.

Isn't that why one would typically enter separate events for deaths,
burials or cremations?

> For such occasions, I would think that the ideal object to attach the
> citation to is the date, and not the whole event, so that, once I do
> find out about the place, I can add that, with a proper citation
> attached to the event place, which is not the place itself, because
> that may be shared with other events.

IMHO a date is a representation of a point in time, i.e. a mere mark on
a calendar, about which a citation typically doesn't provide any
additional information, unless e.g. in some area of the world one would
at some point in time have changed to another way of keeping track of
time and consequently dates.

AFAIK and in general it is no problem at all to enter an event with
whatever minimal amount of information one may have found up to that
point and add, change, attach or even detach additional information as
and when it becomes available or change accuracy indicators such as
estimated, calculated, about, regular, etc. as and when deemed
necessary. It may just be how I tend to go about doing this, but I do
that all the time.

> Attaching citations to these 'facts' makes it easier to trace where
> individual parts of information have their origins, like dates on
> tombstones, which may very well be wrong, because they are not
> authorized by an official. Same for event places, which may also come
> from people's memories.

I would agree that these last two example carry less weight or have a
lower degree of confidence if you will.

>> In addition IMHO the combination of a grave and tombstone can be
>> thought of as a place known by the combination of some designation
>> (e.g. row such-and-such, grave no. xyz), in the records of a graveyard
>> used by the caretakers of a graveyard to identify an individual grave,
>> and the address (of the form street no., city, area, country) of the
>> grave yard, which could even be entered using the time dependent place
>> expansion options that Gramps provides should that be useful.

Come to think of it one could take a similar approach to prolonged stays
in facilities such as hospitals, psychiatric institutions, prisons, etc.
and enter places like room, floor, building, address, municipality,
area, country to cater to one's needs.

Having said that at this stage I personally think it's unlikely I'll go
to that level of detail. For a dozen or so baptisms I entered places
using the form name-of-the-house-of-worship, municipality, area, country
but found that resulted in things becoming kinda 'cluttery'.

I've since reverted to using municipality, area, country to achieve more
consistency in the resulting data.

> One can do that indeed, but I don't. When I find a grave on-line, I
> always use the location of the grave yard itself, and add the grave
> number in the citation.
>
> Regards,
>
> Enno

Regards, Jk.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org
Reply | Threaded
Open this post in threaded view
|

Re: data harmonization tips?

Nick Hall
In reply to this post by GRAMPS - User mailing list
On 20/12/17 19:04, Emyoulation--- via Gramps-users wrote:
The other wish is that GRAMPS had an option like Microsoft Word's "Show/Hide " feature.

This was discussed briefly on the gramps-devel list.  See:

https://sourceforge.net/p/gramps/mailman/message/35929696/

I don't remember any related feature request.

Nick.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org
Reply | Threaded
Open this post in threaded view
|

Re: Recommended layout/DB design?

Nick Hall
In reply to this post by enno
On 21/12/17 11:10, Enno Borgsteede wrote:

> For such occasions, I would think that the ideal object to attach the
> citation to is the date, and not the whole event, so that, once I do
> find out about the place, I can add that, with a proper citation
> attached to the event place, which is not the place itself, because
> that may be shared with other events.
>
> Attaching citations to these 'facts' makes it easier to trace where
> individual parts of information have their origins, like dates on
> tombstones, which may very well be wrong, because they are not
> authorized by an official. Same for event places, which may also come
> from people's memories.

Where an event has more than one source, attributes can be useful to
store these 'facts'.

For example, a birth event may have a baptism register entry and a
census return as sources.  The census entry may only give an age and the
place of birth may perhaps be the nearest large town.  In this case you
could create two attributes with the key "Date" and two with the key
"Place".  Each attribute can refer to the appropriate citation.

The place and date in the event would represent the conclusion.

Unfortunately, attributes can only store text; it would be useful if
they could store other data types such as dates and handles (pointers to
objects).

Nick.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org
Reply | Threaded
Open this post in threaded view
|

Re: Recommended layout/DB design?

John W. Kitz-3
In reply to this post by Paul Smith
Enno,

On 2017-12-21 12:10, Enno Borgsteede wrote:

--- 8< ----

> For such occasions, I would think that the ideal object to attach the
> citation to is the date,

What about the fact that the more people one has in one's data the more
likely it becomes that two or more events occurred on the same date at
which point and given the preference you expressed above one would is
likely to end up with multiple non-related citations attached to the
same date?

> and not the whole event, so that, once I do
> find out about the place, I can add that, with a proper citation
> attached to the event place, which is not the place itself, because
> that may be shared with other events.

Regards, Jk.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org
Reply | Threaded
Open this post in threaded view
|

Re: Recommended layout/DB design?

Dave Scheipers
Dates do not have citations. The event with a date (or not) has citations.

The event can be cited and from the facts found in the citation will
be more information. Date information, place, those involved and maybe
facts about the person. Each of these facts CAN be individually linked
back to the citation but to what end? so long as they are linked to
the event with the citation they are facts found in the citation
broken apart from the transcript by parsing the info into areas that
Gramps can cleanly categorize and you can replicate for other similar
events for other people.   Notes, attributes etc,

Sometimes, a citation will give you clues to fill in other events; ie.
gross birth information from a census record. The question is do you
add the census citation to the birth record even if all the census
says is that the person MAY have been born between certain years in a
certain location.. Personally, I do not cite the birth with the
census. It's a clue, but it is not a fact. Others add the citation
even if only a clue. Personal choice. For me, if there is no citation
on an event, the information on the event are clues not yet proven.

But this is just me. As always, we each do what we find works best for
ourselves.

Dave.

On Thu, Dec 21, 2017 at 3:56 PM, John W. Kitz <[hidden email]> wrote:

> Enno,
>
> On 2017-12-21 12:10, Enno Borgsteede wrote:
>
> --- 8< ----
>
>> For such occasions, I would think that the ideal object to attach the
>> citation to is the date,
>
>
> What about the fact that the more people one has in one's data the more
> likely it becomes that two or more events occurred on the same date at which
> point and given the preference you expressed above one would is likely to
> end up with multiple non-related citations attached to the same date?
>
>> and not the whole event, so that, once I do
>> find out about the place, I can add that, with a proper citation
>> attached to the event place, which is not the place itself, because
>> that may be shared with other events.
>
>
> Regards, Jk.
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Gramps-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-users
> https://gramps-project.org

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org
Reply | Threaded
Open this post in threaded view
|

Re: Recommended layout/DB design?

paul womack
Dave Scheipers wrote:

> Sometimes, a citation will give you clues to fill in other events; ie.
> gross birth information from a census record. The question is do you
> add the census citation to the birth record even if all the census
> says is that the person MAY have been born between certain years in a
> certain location.. Personally, I do not cite the birth with the
> census. It's a clue, but it is not a fact. Others add the citation
> even if only a clue. Personal choice. For me, if there is no citation
> on an event, the information on the event are clues not yet proven.
>
> But this is just me. As always, we each do what we find works best for
> ourselves.

Agreed. My personal view is that all information resources are good,
and my database is always a "best approximation so far" to an unreachable
platonic truth.

As such, "clues" and "facts" are merely labelled points on the information
quality/certainty spectrum.

Therefore I cite ALL applicable information. I view cites
as the answer to the question "how did I find this out?".

  BugBear

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org
Reply | Threaded
Open this post in threaded view
|

Re: Recommended layout/DB design?

enno
In reply to this post by John W. Kitz-3
Op 21-12-17 om 21:56 schreef John W. Kitz:

> Enno,
>
> On 2017-12-21 12:10, Enno Borgsteede wrote:
>
> --- 8< ----
>
>> For such occasions, I would think that the ideal object to attach the
>> citation to is the date,
>
> What about the fact that the more people one has in one's data the
> more likely it becomes that two or more events occurred on the same
> date at which point and given the preference you expressed above one
> would is likely to end up with multiple non-related citations attached
> to the same date?
It won't happen, because dates don't sit in a separate table. They're
fields in the event table, and in citations, and a couple of other
tables too.

The idea behind my comment is that, in theory, any element could have a
citation attached to it. Dates and places are some examples, and the
citation would then be attached where the element is used, so even when
places are all stored in a single table, the citation for a place
attached to an event would be attached to that event, not to the place
itself. Places can have citations too, but they should be reserved for
citations that apply to the place itself, not to the objects that
reference that place.

One can think about similar designs for names. People born before civil
registrations were introduced were often registered with (assumed)
patronymic names, which were later replaced with official ones stored in
the civil registry, and in that case it would make sense to have a
separate citation for the new surname, leaving the given names
unchanged. Today, however, Gramps can only store citations for full
names, not parts.

When you think about DC design, it could be turned upside down, making
sources more important, and allowing for all sorts of data stored in
source elements. Those elements could be name, birth and death dates for
tombstones, ages for censuses, etc. etc., and the information displayed
for persons and other entities would be a combination/selection of
source elements. You could for instance present the date from a
tombstone until you find a better date in the civil registry.

This model is quite different from what Gramps does now, and there is no
popular software that supports this model in full, but some systems get
pretty close, like FamilySearch, sort of, where you can see these
elements in the attached sources on-line.

Regards,

Enno


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org
Reply | Threaded
Open this post in threaded view
|

Re: Recommended layout/DB design?

John W. Kitz-3
Enno,

On 2017-12-22 11:57, Enno Borgsteede wrote:

> Op 21-12-17 om 21:56 schreef John W. Kitz:
>> Enno,
>>
>> On 2017-12-21 12:10, Enno Borgsteede wrote:
>>
>> --- 8< ----
>>
>>> For such occasions, I would think that the ideal object to attach the
>>> citation to is the date,
>>
>> What about the fact that the more people one has in one's data the
>> more likely it becomes that two or more events occurred on the same
>> date at which point and given the preference you expressed above one
>> would is likely to end up with multiple non-related citations attached
>> to the same date?
> It won't happen, because dates don't sit in a separate table. They're
> fields in the event table, and in citations, and a couple of other
> tables too.
>
> The idea behind my comment is that, in theory, any element could have
> a citation attached to it. Dates and places are some examples, and the
> citation would then be attached where the element is used, so even
> when places are all stored in a single table, the citation for a place
> attached to an event would be attached to that event, not to the place
> itself. Places can have citations too, but they should be reserved for
> citations that apply to the place itself, not to the objects that
> reference that place.
>
> One can think about similar designs for names. People born before
> civil registrations were introduced were often registered with
> (assumed) patronymic names,

Patronymic names were more than just assumed names (see this post[1]).

[1] https://sourceforge.net/p/gramps/mailman/message/36154422/

> which were later replaced with official
> ones stored in the civil registry, and in that case it would make
> sense to have a separate citation for the new surname, leaving the
> given names unchanged.

One of the many options available is discussed in this post.

[2] https://sourceforge.net/p/gramps/mailman/message/36153560/

> Today, however, Gramps can only store citations
> for full names, not parts.
>
> When you think about DC design, it could be turned upside down, making
> sources more important, and allowing for all sorts of data stored in
> source elements. Those elements could be name, birth and death dates
> for tombstones, ages for censuses, etc. etc., and the information
> displayed for persons and other entities would be a
> combination/selection of source elements. You could for instance
> present the date from a tombstone until you find a better date in the
> civil registry.
>
> This model is quite different from what Gramps does now, and there is
> no popular software that supports this model in full, but some systems
> get pretty close, like FamilySearch, sort of, where you can see these
> elements in the attached sources on-line.
>
> Regards,
>
> Enno

With regards to the remainder of the most recent contributions to this
thread, I looks like they are somewhat 'off- or rather side tracked'.

Regards, Jk.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-users
https://gramps-project.org
12