Rethinking Gramps Place data model

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

Rethinking Gramps Place data model

prculley
The following should be considered a starting place for discussion around the Gramps place data model.  Any changes to this would require considerable changes, new XML version, db upgrades, likely changes to some reports etc.

One of the items on the Gramps 5.1 Roadmap is to look into better GEDCOM support for places.  We could continue to force fit GEDCOM import data to Gramps, or look into expanding Gramps data model to make for a better fit.

1      Place

1.1           Place.Type:

 Gramps only supports a single place type

Gov (http://gov.genealogy.net/search/index) and GEDCOM L group support multiple types, each with a subordinate date range, GEDCOM L group support a citation for each type as well

1.1.1    Recommendation

Make place types a list.  Each element should have a subordinate date range and may have a citation (another decision).

We should also provide a routine similar to the current place displayer to return a place type for a particular date.

1.2           Place Types:

Changes to place types, do not actually modify the data model, but dealing with them better will certainly impact a lot of code.

GeoNames currently doesn’t do much to provide place types.  It currently uses PCLx, for Country, PPLx for 'Populated Place', and ADM1-ADMn for different level of administrative place.  These do not map well to Gramps PlaceTypes.  The Place Cleanup Gramplet tries to do it anyway, but allows user modification.

Gov currently has over 260 place types in several broad categories.  The categories are Administrative, Civil, Religious (church), Judicial, populated place, transportation, and a few miscellaneous others.  They are still adding more.  The GetGov Gramplet currently stores the returned German place type as a Custom Gramps place type, which is of course not translatable.  For example, Deutsches Reich, or USA gets a PlaceType of 'Staat', rather than country.  While the system has a lot of types it is very German centric, many types have only German names in their definition documents although some of the more commonly used types have at least English translations and some have several other translations.

1.2.1    Recommendation

One of;

1)      Adopt the Gov type system.  We would have to do a lot of translation work on many types, or indicate that the type is local to certain countries (so could use the local words).  Our GUI would probably have to use at least a two level hierarchy in the PlaceType selector, possibly three levels, to help users find appropriate types for manually entered places or filtering.

2)      Provide a conversion of the Gov type to the closest Gramps PlaceType, possibly adding a few more Gramps PlaceTypes.  If we did that, I think it would be reasonable to store the original Gov type in a place fact.

1.3           Place.Name:

Gramps supports multiple names, each with a language and date range

GEDCOM supports two additional parts of a name; neither of which seem to be used much and are not currently supported by Gramps.

FONE (Place phonetic variation) and its subordinate TYPE.  This seems to be used for far eastern places for example if hiragana was used to provide a reading of a name written in kanji, then the <PHONETIC_TYPE> value would indicate kana. The TYPE is defined as [<user defined> | hangul | kana]

ROMN (PLACE_ROMANIZED_VARIATION:= {Size=1:120}) and its subordinate TYPE.  The romanized variation of the place name is written in the same form prescribed for the place name used in the superior <PLACE_NAME> context. The method used to romanize the name is indicated by the line_value of the subordinate <ROMANIZED_TYPE>, for example if romaji was used to provide a reading of a place name written in kanji, then the <ROMANIZED_TYPE> subordinate to the ROMN tag would indicate ‘romaji’.  The TYPE is defined as [<user defined> | pinyin | romaji | wadegiles]

GEDCOM L group adds in _NAMC (place name addition) for each name.  Their documentation currently says "Addition to PLACE_NAME, can be appended to PLACE_NAME in non-delimited reports to make the label unique".  This is for suffixes like "am Main" in "Frankfurt am Main".  

GEDCOM L group adds in ABBR with a subordinate TYPE.  ABBREVIATION_OF_NAME Abbreviation for the place name, whereby the type of abbreviation can be further explained with the optional TYPE.  It is not too clear what to do with this.

GEDCOM L group adds in a citation for each name.

The GeoNames data and Place Cleanup Gramplet currently store place name abbreviations as an alternate name with the 'abbr' language code.

The GeoNames data and Place Cleanup Gramplet currently store colloquial place names ('Big Apple' for New Yok City USA) as an alternate name with no language code.

1.3.1    Recommendation

1)      Make the abbreviation and colloquial name part of a more general place fact list.  Each would have a date, and possibly a citation (another decision) associated with it.

1.4           Postal Code:

 Gramps currently offers a single field 'Code' to store postal codes.  It may have also been used for other purposes in the past.

GeoNames, GOV, GEDCOM L all support multiple postal codes.  GEDCOM L adds in a subordinate DATE range and citation for each code.

The Place Cleanup Gramplet currently stores multiple postal codes in the code field separated by commas.

1.4.1    Recommendation

One of the following:

2)      Make the postal code(s) part of a more general place fact list.  Each code would have a date, and possibly a citation (another decision) associated with it.

3)      Make postal codes a list.  Each element should have a subordinate date range and may have a citation (another decision).

1.5           MAIDENHEAD_LOCATOR

GEDCOM L has added this to the Place import/export.

The Maidenhead Locator divides the world into small areas (micro-fields) marked by 8 letters and numbers.  It was originally conceived for use in ham radio, but it is also used as a geographic locator in some other applications.  https://en.wikipedia.org/wiki/Maidenhead_Locator_System

1.5.1    Recommendation

Store the Maidenhead locator in a more general place fact list.  Date and Citation parts of the fact would not be used.

1.6           ADMINISTRATIVE_IDENTIFIER

GEDCOM L has added this to the Place import/export.

The official or public identifier for a location object, such as community code, ISO 3166 for countries and states.  GEDCOM L allows multiple of these, each with date range and an additional TYPE and citation.

1.6.1    Recommendation

Store the ADMINISTRATIVE IDENTIFIER in a more general place fact list along with the Date and Citation.  Merge the TYPE_OF_ADMINISTRATIVE_IDENTIFIER into the fact type.

1.7           DEMOGRAPHICAL_DATA

GEDCOM L has added this to the Place import/export.

Demographics about people to the place object, such as number of households, number of people, occupations, and so on.  GEDCOM L allows multiple of these, each with date range and an additional TYPE and citation.

1.7.1    Recommendation

Store the DEMOGRAPICAL_DATA in a more general place fact list along with the Date and Citation.  Merge the TYPE_OF_DEMOGRAPICAL_DATA into the fact type.

1.8           EVENT_DETAIL

GEDCOM L has added this to the Place import/export.

GEDCOM L has added an event reference to the place.  It is not too clear what this is intended to be used for.

1.8.1    Recommendation

None…

2      Enclosed by

The following items would be part of the Gramps place reference, which currently only includes a date and the reference to another place.

2.1           HIERARCHICAL_RELATIONSHIP

GEDCOM L has added this to the Place import/export.

Values are [POLI | RELI | GEOG | CULT] to differentiate political (administrative), ecclesiastical, geographical or cultural attributions.  GEDCOM L includes this to provide some indication of the type of enclosure.  For example a Church might be enclosed by a city and enclosed by a parish, with different relationships.

2.2           Citation

GEDCOM L adds a citation to the Enclosed by

2.2.1    Recommendation

No change.  The Hierarchical relationship can be inferred from the type of the enclosing place, so it appears to me to be redundant.  I also think that a citation here adds little value.

3      Place facts

To deal with several new facts associated with places, I propose a generalized Place Facts list.  Each place fact would include the type, value, date, and possibly citation.

4      Citations

GEDCOM L has added citations to most of its additional data.  To me this seems excessive.  I think we need to decide if we support citations individually, or just citations on the Place object.  This would affect the proposed Place Fact structure, as well as Place Name, Type, Postal codes, and Place Enclosed by.


Paul C.


_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Gramps Place data model

John Ralls-2
On Jan 31, 2019, at 12:09 PM, Paul Culley <[hidden email]> wrote:

>
> The following should be considered a starting place for discussion around the Gramps place data model.  Any changes to this would require considerable changes, new XML version, db upgrades, likely changes to some reports etc.
>
> One of the items on the Gramps 5.1 Roadmap is to look into better GEDCOM support for places.  We could continue to force fit GEDCOM import data to Gramps, or look into expanding Gramps data model to make for a better fit.
>
> 1      Place
> 1.1           Place.Type:
>  Gramps only supports a single place type
>
> Gov (http://gov.genealogy.net/search/index) and GEDCOM L group support multiple types, each with a subordinate date range, GEDCOM L group support a citation for each type as well
>
> 1.1.1    Recommendation
> Make place types a list.  Each element should have a subordinate date range and may have a citation (another decision).
>
> We should also provide a routine similar to the current place displayer to return a place type for a particular date.
>
> 1.2           Place Types:
> Changes to place types, do not actually modify the data model, but dealing with them better will certainly impact a lot of code.
>
> GeoNames currently doesn’t do much to provide place types.  It currently uses PCLx, for Country, PPLx for 'Populated Place', and ADM1-ADMn for different level of administrative place.  These do not map well to Gramps PlaceTypes.  The Place Cleanup Gramplet tries to do it anyway, but allows user modification.
>
> Gov currently has over 260 place types in several broad categories.  The categories are Administrative, Civil, Religious (church), Judicial, populated place, transportation, and a few miscellaneous others.  They are still adding more.  The GetGov Gramplet currently stores the returned German place type as a Custom Gramps place type, which is of course not translatable.  For example, Deutsches Reich, or USA gets a PlaceType of 'Staat', rather than country.  While the system has a lot of types it is very German centric, many types have only German names in their definition documents although some of the more commonly used types have at least English translations and some have several other translations.
>
> 1.2.1    Recommendation
> One of;
>
> 1)      Adopt the Gov type system.  We would have to do a lot of translation work on many types, or indicate that the type is local to certain countries (so could use the local words).  Our GUI would probably have to use at least a two level hierarchy in the PlaceType selector, possibly three levels, to help users find appropriate types for manually entered places or filtering.
> 2)      Provide a conversion of the Gov type to the closest Gramps PlaceType, possibly adding a few more Gramps PlaceTypes.  If we did that, I think it would be reasonable to store the original Gov type in a place fact.
>
> 1.3           Place.Name:
> Gramps supports multiple names, each with a language and date range
>
> GEDCOM supports two additional parts of a name; neither of which seem to be used much and are not currently supported by Gramps.
>
> FONE (Place phonetic variation) and its subordinate TYPE.  This seems to be used for far eastern places for example if hiragana was used to provide a reading of a name written in kanji, then the <PHONETIC_TYPE> value would indicate kana. The TYPE is defined as [<user defined> | hangul | kana]
>
> ROMN (PLACE_ROMANIZED_VARIATION:= {Size=1:120}) and its subordinate TYPE.  The romanized variation of the place name is written in the same form prescribed for the place name used in the superior <PLACE_NAME> context. The method used to romanize the name is indicated by the line_value of the subordinate <ROMANIZED_TYPE>, for example if romaji was used to provide a reading of a place name written in kanji, then the <ROMANIZED_TYPE> subordinate to the ROMN tag would indicate ‘romaji’.  The TYPE is defined as [<user defined> | pinyin | romaji | wadegiles]
>
> GEDCOM L group adds in _NAMC (place name addition) for each name.  Their documentation currently says "Addition to PLACE_NAME, can be appended to PLACE_NAME in non-delimited reports to make the label unique".  This is for suffixes like "am Main" in "Frankfurt am Main".  
>
> GEDCOM L group adds in ABBR with a subordinate TYPE.  ABBREVIATION_OF_NAME Abbreviation for the place name, whereby the type of abbreviation can be further explained with the optional TYPE.  It is not too clear what to do with this.
>
> GEDCOM L group adds in a citation for each name.
>
> The GeoNames data and Place Cleanup Gramplet currently store place name abbreviations as an alternate name with the 'abbr' language code.
>
> The GeoNames data and Place Cleanup Gramplet currently store colloquial place names ('Big Apple' for New Yok City USA) as an alternate name with no language code.
>
> 1.3.1    Recommendation
> 1)      Make the abbreviation and colloquial name part of a more general place fact list.  Each would have a date, and possibly a citation (another decision) associated with it.
>
> 1.4           Postal Code:
>  Gramps currently offers a single field 'Code' to store postal codes.  It may have also been used for other purposes in the past.
>
> GeoNames, GOV, GEDCOM L all support multiple postal codes.  GEDCOM L adds in a subordinate DATE range and citation for each code.
>
> The Place Cleanup Gramplet currently stores multiple postal codes in the code field separated by commas.
>
> 1.4.1    Recommendation
> One of the following:
>
> 2)      Make the postal code(s) part of a more general place fact list.  Each code would have a date, and possibly a citation (another decision) associated with it.
> 3)      Make postal codes a list.  Each element should have a subordinate date range and may have a citation (another decision).
>
> 1.5           MAIDENHEAD_LOCATOR
> GEDCOM L has added this to the Place import/export.
>
> The Maidenhead Locator divides the world into small areas (micro-fields) marked by 8 letters and numbers.  It was originally conceived for use in ham radio, but it is also used as a geographic locator in some other applications.  https://en.wikipedia.org/wiki/Maidenhead_Locator_System
>
> 1.5.1    Recommendation
> Store the Maidenhead locator in a more general place fact list.  Date and Citation parts of the fact would not be used.
>
> 1.6           ADMINISTRATIVE_IDENTIFIER
> GEDCOM L has added this to the Place import/export.
>
> The official or public identifier for a location object, such as community code, ISO 3166 for countries and states.  GEDCOM L allows multiple of these, each with date range and an additional TYPE and citation.
>
> 1.6.1    Recommendation
> Store the ADMINISTRATIVE IDENTIFIER in a more general place fact list along with the Date and Citation.  Merge the TYPE_OF_ADMINISTRATIVE_IDENTIFIER into the fact type.
>
> 1.7           DEMOGRAPHICAL_DATA
> GEDCOM L has added this to the Place import/export.
>
> Demographics about people to the place object, such as number of households, number of people, occupations, and so on.  GEDCOM L allows multiple of these, each with date range and an additional TYPE and citation.
>
> 1.7.1    Recommendation
> Store the DEMOGRAPICAL_DATA in a more general place fact list along with the Date and Citation.  Merge the TYPE_OF_DEMOGRAPICAL_DATA into the fact type.
>
> 1.8           EVENT_DETAIL
> GEDCOM L has added this to the Place import/export.
>
> GEDCOM L has added an event reference to the place.  It is not too clear what this is intended to be used for.
>
> 1.8.1    Recommendation
> None…
>
> 2      Enclosed by
> The following items would be part of the Gramps place reference, which currently only includes a date and the reference to another place.
>
> 2.1           HIERARCHICAL_RELATIONSHIP
> GEDCOM L has added this to the Place import/export.
>
> Values are [POLI | RELI | GEOG | CULT] to differentiate political (administrative), ecclesiastical, geographical or cultural attributions.  GEDCOM L includes this to provide some indication of the type of enclosure.  For example a Church might be enclosed by a city and enclosed by a parish, with different relationships.
>
> 2.2           Citation
> GEDCOM L adds a citation to the Enclosed by
>
> 2.2.1    Recommendation
> No change.  The Hierarchical relationship can be inferred from the type of the enclosing place, so it appears to me to be redundant.  I also think that a citation here adds little value.
>
> 3      Place facts
> To deal with several new facts associated with places, I propose a generalized Place Facts list.  Each place fact would include the type, value, date, and possibly citation.
>
> 4      Citations
> GEDCOM L has added citations to most of its additional data.  To me this seems excessive.  I think we need to decide if we support citations individually, or just citations on the Place object.  This would affect the proposed Place Fact structure, as well as Place Name, Type, Postal codes, and Place Enclosed by.


What's "GEDCOM L"? It used to be a mailing list whose archive is at https://listserv.nodak.edu/cgi-bin/wa.exe?A0=GEDCOM-L but it hasn't seen a post in over four years. Google doesn't find anything else useful.

Regards,
John Ralls



_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Gramps Place data model

John Ralls-2
Sam,

Thanks. The explanation of where this stuff comes from is one level up, at http://wiki-en.genealogy.net/GEDCOM: It's a German Gedcom-L mailing list. Looks to me like it might be more correct to refer to the agreement as "GEDCOM 5.5EL" as the wiki page and GEPS 043 do.

Regards,
John Ralls

> On Jan 31, 2019, at 1:58 PM, Sam Manzi <[hidden email]> wrote:
>
> Hi John,
>
> You can find it here:
> http://wiki-en.genealogy.net/GEDCOM/PLAC-Tag#Location_Records
>
> Kind regards
> Sam
> ....................
> Relevant feature request and GEPS
>
> 688: Support for Gedcom 5.5EL (or Gedcom-L the more recent standard)
> https://gramps-project.org/bugs/view.php?id=688
>
> GEPS 043: Improving GEDCOM support for Places
> https://www.gramps-project.org/wiki/index.php/GEPS_043:_Improving_GEDCOM_support_for_Places
>
> On Fri, 1 Feb 2019 at 08:50, John Ralls <[hidden email]> wrote:
> On Jan 31, 2019, at 12:09 PM, Paul Culley <[hidden email]> wrote:
> >
> > The following should be considered a starting place for discussion around the Gramps place data model.  Any changes to this would require considerable changes, new XML version, db upgrades, likely changes to some reports etc.
> >
> > One of the items on the Gramps 5.1 Roadmap is to look into better GEDCOM support for places.  We could continue to force fit GEDCOM import data to Gramps, or look into expanding Gramps data model to make for a better fit.
> >
> > 1      Place
> > 1.1           Place.Type:
> >  Gramps only supports a single place type
> >
> > Gov (http://gov.genealogy.net/search/index) and GEDCOM L group support multiple types, each with a subordinate date range, GEDCOM L group support a citation for each type as well
> >
> > 1.1.1    Recommendation
> > Make place types a list.  Each element should have a subordinate date range and may have a citation (another decision).
> >
> > We should also provide a routine similar to the current place displayer to return a place type for a particular date.
> >
> > 1.2           Place Types:
> > Changes to place types, do not actually modify the data model, but dealing with them better will certainly impact a lot of code.
> >
> > GeoNames currently doesn’t do much to provide place types.  It currently uses PCLx, for Country, PPLx for 'Populated Place', and ADM1-ADMn for different level of administrative place.  These do not map well to Gramps PlaceTypes.  The Place Cleanup Gramplet tries to do it anyway, but allows user modification.
> >
> > Gov currently has over 260 place types in several broad categories.  The categories are Administrative, Civil, Religious (church), Judicial, populated place, transportation, and a few miscellaneous others.  They are still adding more.  The GetGov Gramplet currently stores the returned German place type as a Custom Gramps place type, which is of course not translatable.  For example, Deutsches Reich, or USA gets a PlaceType of 'Staat', rather than country.  While the system has a lot of types it is very German centric, many types have only German names in their definition documents although some of the more commonly used types have at least English translations and some have several other translations.
> >
> > 1.2.1    Recommendation
> > One of;
> >
> > 1)      Adopt the Gov type system.  We would have to do a lot of translation work on many types, or indicate that the type is local to certain countries (so could use the local words).  Our GUI would probably have to use at least a two level hierarchy in the PlaceType selector, possibly three levels, to help users find appropriate types for manually entered places or filtering.
> > 2)      Provide a conversion of the Gov type to the closest Gramps PlaceType, possibly adding a few more Gramps PlaceTypes.  If we did that, I think it would be reasonable to store the original Gov type in a place fact.
> >
> > 1.3           Place.Name:
> > Gramps supports multiple names, each with a language and date range
> >
> > GEDCOM supports two additional parts of a name; neither of which seem to be used much and are not currently supported by Gramps.
> >
> > FONE (Place phonetic variation) and its subordinate TYPE.  This seems to be used for far eastern places for example if hiragana was used to provide a reading of a name written in kanji, then the <PHONETIC_TYPE> value would indicate kana. The TYPE is defined as [<user defined> | hangul | kana]
> >
> > ROMN (PLACE_ROMANIZED_VARIATION:= {Size=1:120}) and its subordinate TYPE.  The romanized variation of the place name is written in the same form prescribed for the place name used in the superior <PLACE_NAME> context. The method used to romanize the name is indicated by the line_value of the subordinate <ROMANIZED_TYPE>, for example if romaji was used to provide a reading of a place name written in kanji, then the <ROMANIZED_TYPE> subordinate to the ROMN tag would indicate ‘romaji’.  The TYPE is defined as [<user defined> | pinyin | romaji | wadegiles]
> >
> > GEDCOM L group adds in _NAMC (place name addition) for each name.  Their documentation currently says "Addition to PLACE_NAME, can be appended to PLACE_NAME in non-delimited reports to make the label unique".  This is for suffixes like "am Main" in "Frankfurt am Main".  
> >
> > GEDCOM L group adds in ABBR with a subordinate TYPE.  ABBREVIATION_OF_NAME Abbreviation for the place name, whereby the type of abbreviation can be further explained with the optional TYPE.  It is not too clear what to do with this.
> >
> > GEDCOM L group adds in a citation for each name.
> >
> > The GeoNames data and Place Cleanup Gramplet currently store place name abbreviations as an alternate name with the 'abbr' language code.
> >
> > The GeoNames data and Place Cleanup Gramplet currently store colloquial place names ('Big Apple' for New Yok City USA) as an alternate name with no language code.
> >
> > 1.3.1    Recommendation
> > 1)      Make the abbreviation and colloquial name part of a more general place fact list.  Each would have a date, and possibly a citation (another decision) associated with it.
> >
> > 1.4           Postal Code:
> >  Gramps currently offers a single field 'Code' to store postal codes.  It may have also been used for other purposes in the past.
> >
> > GeoNames, GOV, GEDCOM L all support multiple postal codes.  GEDCOM L adds in a subordinate DATE range and citation for each code.
> >
> > The Place Cleanup Gramplet currently stores multiple postal codes in the code field separated by commas.
> >
> > 1.4.1    Recommendation
> > One of the following:
> >
> > 2)      Make the postal code(s) part of a more general place fact list.  Each code would have a date, and possibly a citation (another decision) associated with it.
> > 3)      Make postal codes a list.  Each element should have a subordinate date range and may have a citation (another decision).
> >
> > 1.5           MAIDENHEAD_LOCATOR
> > GEDCOM L has added this to the Place import/export.
> >
> > The Maidenhead Locator divides the world into small areas (micro-fields) marked by 8 letters and numbers.  It was originally conceived for use in ham radio, but it is also used as a geographic locator in some other applications.  https://en.wikipedia.org/wiki/Maidenhead_Locator_System
> >
> > 1.5.1    Recommendation
> > Store the Maidenhead locator in a more general place fact list.  Date and Citation parts of the fact would not be used.
> >
> > 1.6           ADMINISTRATIVE_IDENTIFIER
> > GEDCOM L has added this to the Place import/export.
> >
> > The official or public identifier for a location object, such as community code, ISO 3166 for countries and states.  GEDCOM L allows multiple of these, each with date range and an additional TYPE and citation.
> >
> > 1.6.1    Recommendation
> > Store the ADMINISTRATIVE IDENTIFIER in a more general place fact list along with the Date and Citation.  Merge the TYPE_OF_ADMINISTRATIVE_IDENTIFIER into the fact type.
> >
> > 1.7           DEMOGRAPHICAL_DATA
> > GEDCOM L has added this to the Place import/export.
> >
> > Demographics about people to the place object, such as number of households, number of people, occupations, and so on.  GEDCOM L allows multiple of these, each with date range and an additional TYPE and citation.
> >
> > 1.7.1    Recommendation
> > Store the DEMOGRAPICAL_DATA in a more general place fact list along with the Date and Citation.  Merge the TYPE_OF_DEMOGRAPICAL_DATA into the fact type.
> >
> > 1.8           EVENT_DETAIL
> > GEDCOM L has added this to the Place import/export.
> >
> > GEDCOM L has added an event reference to the place.  It is not too clear what this is intended to be used for.
> >
> > 1.8.1    Recommendation
> > None…
> >
> > 2      Enclosed by
> > The following items would be part of the Gramps place reference, which currently only includes a date and the reference to another place.
> >
> > 2.1           HIERARCHICAL_RELATIONSHIP
> > GEDCOM L has added this to the Place import/export.
> >
> > Values are [POLI | RELI | GEOG | CULT] to differentiate political (administrative), ecclesiastical, geographical or cultural attributions.  GEDCOM L includes this to provide some indication of the type of enclosure.  For example a Church might be enclosed by a city and enclosed by a parish, with different relationships.
> >
> > 2.2           Citation
> > GEDCOM L adds a citation to the Enclosed by
> >
> > 2.2.1    Recommendation
> > No change.  The Hierarchical relationship can be inferred from the type of the enclosing place, so it appears to me to be redundant.  I also think that a citation here adds little value.
> >
> > 3      Place facts
> > To deal with several new facts associated with places, I propose a generalized Place Facts list.  Each place fact would include the type, value, date, and possibly citation.
> >
> > 4      Citations
> > GEDCOM L has added citations to most of its additional data.  To me this seems excessive.  I think we need to decide if we support citations individually, or just citations on the Place object.  This would affect the proposed Place Fact structure, as well as Place Name, Type, Postal codes, and Place Enclosed by.
>
>
> What's "GEDCOM L"? It used to be a mailing list whose archive is at https://listserv.nodak.edu/cgi-bin/wa.exe?A0=GEDCOM-L but it hasn't seen a post in over four years. Google doesn't find anything else useful.
>
> Regards,
> John Ralls
>
>
>
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel



_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Gramps Place data model

Nick Hall
In reply to this post by prculley
On 31/01/2019 20:09, Paul Culley wrote:
The following should be considered a starting place for discussion around the Gramps place data model.  Any changes to this would require considerable changes, new XML version, db upgrades, likely changes to some reports etc.

One of the items on the Gramps 5.1 Roadmap is to look into better GEDCOM support for places.  We could continue to force fit GEDCOM import data to Gramps, or look into expanding Gramps data model to make for a better fit.

Just as a bit of background, the original place model was not designed to support Gedcom-L.  However, we later realised that our model was a subset of Gedcom-L.  As such I suggested that we didn't deliberately add anything that was incompatible.

Having said that, our model is lacking a few key features which users have asked for:

1. Time dependent place types.

2. A hierachy type.

3. Citations in names, types and the hierarchy.

I suggest that we add these.  I would also have no objection to adding attributes to places.

Gramps can create top-level events, which gives us the ability to store all the information you describe in place facts.  This is not possible in Gedcom.  I have used this to store population data for places and it works well.  I seem to remember similar discussions on the FHISO lists, so I suggest that this is the way forward.

We may also wish to consider adding identifiers in external databases as indexed fields.  At the moment we use the Gramps Id field for the GOV Id.

Regards,


Nick.




_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Gramps Place data model

StoltHD
And we have asked for Attributes with dates for places...

and dates on Notes as a minimum, to be able to make chronological history without having to reorginize every time you find a new piece of information that you want to registre, for places, as long as we cant get Events for places...

Den fre. 1. feb. 2019 kl. 01:47 skrev Nick Hall <[hidden email]>:
On 31/01/2019 20:09, Paul Culley wrote:
The following should be considered a starting place for discussion around the Gramps place data model.  Any changes to this would require considerable changes, new XML version, db upgrades, likely changes to some reports etc.

One of the items on the Gramps 5.1 Roadmap is to look into better GEDCOM support for places.  We could continue to force fit GEDCOM import data to Gramps, or look into expanding Gramps data model to make for a better fit.

Just as a bit of background, the original place model was not designed to support Gedcom-L.  However, we later realised that our model was a subset of Gedcom-L.  As such I suggested that we didn't deliberately add anything that was incompatible.

Having said that, our model is lacking a few key features which users have asked for:

1. Time dependent place types.

2. A hierachy type.

3. Citations in names, types and the hierarchy.

I suggest that we add these.  I would also have no objection to adding attributes to places.

Gramps can create top-level events, which gives us the ability to store all the information you describe in place facts.  This is not possible in Gedcom.  I have used this to store population data for places and it works well.  I seem to remember similar discussions on the FHISO lists, so I suggest that this is the way forward.

We may also wish to consider adding identifiers in external databases as indexed fields.  At the moment we use the Gramps Id field for the GOV Id.

Regards,


Nick.


_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Gramps Place data model

Nick Hall
On 01/02/2019 20:50, StoltHD wrote:
> And we have asked for Attributes with dates for places...


Attributes with dates are events.


>
> and dates on Notes as a minimum, to be able to make chronological
> history without having to reorginize every time you find a new piece
> of information that you want to registre, for places,


An interesting thought, but should be discussed separately.


> as long as we cant get Events for places...


The point is that we can already create events for places.  Just create
an event without any people or families.

This isn't quite the same as having a place as the subject of an event,
but I don't think we are talking about that.

I gave the example of recording the population of a place on a given
date using a Census/Survey event.  What use cases are you think about?


Nick.




_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Gramps Place data model

StoltHD
yes, its the subject...
In Scandinavia and Island, the place history is a big part of the family many places, and to record events and history for i.e. a farm, would be of  great help... as of now its only one Norwegian developed software supporting it, and that system is very closed (Embla)...

Therefore it would have been nice to been able to registre events that was place specific but also family connected to this places and farms... and we also could use this in regard of those wwho owned fishingboats or companies (registre owners, events and so on)
I know its a bit out of a genealogy lineage-linked path, but its a big part of family history for some... and, if this was possible, Gramps would suddenly be a full featured historian software, or atleast a good alternative for a lot of historians... (just a thought)... and yes I know this is not the path you planned for Gramps... its just some thoughts, since I have all of this in my own family...

Jaran

Den fre. 1. feb. 2019 kl. 22:44 skrev Nick Hall <[hidden email]>:
On 01/02/2019 20:50, StoltHD wrote:
> And we have asked for Attributes with dates for places...


Attributes with dates are events.


>
> and dates on Notes as a minimum, to be able to make chronological
> history without having to reorginize every time you find a new piece
> of information that you want to registre, for places,


An interesting thought, but should be discussed separately.


> as long as we cant get Events for places...


The point is that we can already create events for places.  Just create
an event without any people or families.

This isn't quite the same as having a place as the subject of an event,
but I don't think we are talking about that.

I gave the example of recording the population of a place on a given
date using a Census/Survey event.  What use cases are you think about?


Nick.




_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Gramps Place data model

Nick Hall
On 01/02/2019 23:57, StoltHD wrote:
> yes, its the subject...


Allowing a place to be the subject of an event is very powerful.


> In Scandinavia and Island, the place history is a big part of the
> family many places, and to record events and history for i.e. a farm,
> would be of  great help... as of now its only one Norwegian developed
> software supporting it, and that system is very closed (Embla)...
>
> Therefore it would have been nice to been able to registre events that
> was place specific but also family connected to this places and
> farms... and we also could use this in regard of those wwho owned
> fishingboats or companies (registre owners, events and so on)


For users who model boats and ships as places, it would be possible to
create "Port of Call" or "Sinking" events.  It would also be possible to
model merging and splitting of places (e.g. if two farms merged).

I see a company as more of a group of people rather than a place.  At
some point, I would like to introduce a new Group object which could
also be the subject of an event.


> I know its a bit out of a genealogy lineage-linked path, but its a big
> part of family history for some... and, if this was possible, Gramps
> would suddenly be a full featured historian software, or atleast a
> good alternative for a lot of historians... (just a thought)... and
> yes I know this is not the path you planned for Gramps... its just
> some thoughts, since I have all of this in my own family...


I agree.  We should move towards better support for broader family
history, rather than concentrating on lineage.


Nick.




_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Gramps Place data model

GRAMPS - Dev mailing list
In reply to this post by StoltHD
It seems like that's already in Gramps.

Ancestral homes aren't a frequent issue in my Tree but a similar need occurs at the other end of a Life: Burials.

I always add Cemeteries to Burial events when known. It was easy to add a custom "Cemetery" type to places ... plus a Township type as an added Enclosing level. (Since Cemeteries are often outside town/city limits and American Counties can be huge.) 

Now I can "Edit" any Cemetery place and look at the References to get a list of who has been buried there.

You could do the same for Farms or Castles... (There are even standard Types in Place for Building, Farm, & Locality)



On Fri, Feb 1, 2019 at 17:58, StoltHD


_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Gramps Place data model

StoltHD
Its not the same thing Emyoulation, but the feature that you mention is very powerfull, I use it both for Farms and Companies today, but there are no way to add a chronological path of Events to a place as a subject, like you do with families and people... 
It also lack the possibility to register attributes to places, so only thing to do to add history are unstructured notes...

Nick, yes, a company are more of a group, but in Gramps it works well to add a sub-level in the place hierarchy with the type of Company and connect people to this "place", but there are limitations, so a "Group" object, like "Families" would be great.
I use Clooz 3 and there they have both Buildings and Companies as an object, where you can register both place objects and people to this objects, but there are big limitations in the software, so its best to use to figure out connections between documents/sources and what information that's in them.... nothing close to the flexibility Gramps offer...

Jaran

Den lør. 2. feb. 2019 kl. 04:47 skrev [hidden email] <[hidden email]>:
It seems like that's already in Gramps.

Ancestral homes aren't a frequent issue in my Tree but a similar need occurs at the other end of a Life: Burials.

I always add Cemeteries to Burial events when known. It was easy to add a custom "Cemetery" type to places ... plus a Township type as an added Enclosing level. (Since Cemeteries are often outside town/city limits and American Counties can be huge.) 

Now I can "Edit" any Cemetery place and look at the References to get a list of who has been buried there.

You could do the same for Farms or Castles... (There are even standard Types in Place for Building, Farm, & Locality)



On Fri, Feb 1, 2019 at 17:58, StoltHD


_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Gramps Place data model

Brylie Christopher Oxley
I opened this for discussion also with the GEDCOM X developers.

https://github.com/FamilySearch/gedcomx/issues/322

On 2.2.2019 23.14, StoltHD wrote:
> Nick, yes, a company are more of a group, but in Gramps it works well
> to add a sub-level in the place hierarchy with the type of Company and
> connect people to this "place", but there are limitations, so a
> "Group" object, like "Families" would be great.


_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Gramps Place data model

Nick Hall
On 02/02/2019 21:23, Brylie Christopher Oxley wrote:
I opened this for discussion also with the GEDCOM X developers.

https://github.com/FamilySearch/gedcomx/issues/322

On 2.2.2019 23.14, StoltHD wrote:
Nick, yes, a company are more of a group, but in Gramps it works well to add a sub-level in the place hierarchy with the type of Company and connect people to this "place", but there are limitations, so a "Group" object, like "Families" would be great.

Thanks.  The problem with the Family object in GEDCOM is that it combines two concepts:  a family grouping and relationships between people.  I notice that GEDCOM X attempts to fix this with a new Relationship object. I don't know how it handles groups though.

Groups could also be used to model an extended family, military regiment or club/society for example.

Nick.




_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Gramps Place data model

StoltHD
Brylie Christofher Oxley, and it seems that they already talked about it and have change it from a proposal to master, i.e., they are actually working on it (changes was made 5 days ago)
https://github.com/FamilySearch/gedcomx/pull/321/commits/ee96dcf21042c62eaab162e7bed07024f937d5c0
https://github.com/FamilySearch/gedcomx/pull/321


Jaran

Den søn. 3. feb. 2019 kl. 00:01 skrev Nick Hall <[hidden email]>:
On 02/02/2019 21:23, Brylie Christopher Oxley wrote:
I opened this for discussion also with the GEDCOM X developers.

https://github.com/FamilySearch/gedcomx/issues/322

On 2.2.2019 23.14, StoltHD wrote:
Nick, yes, a company are more of a group, but in Gramps it works well to add a sub-level in the place hierarchy with the type of Company and connect people to this "place", but there are limitations, so a "Group" object, like "Families" would be great.

Thanks.  The problem with the Family object in GEDCOM is that it combines two concepts:  a family grouping and relationships between people.  I notice that GEDCOM X attempts to fix this with a new Relationship object. I don't know how it handles groups though.

Groups could also be used to model an extended family, military regiment or club/society for example.

Nick.


_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel


_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Gramps Place data model

Tim Lyons
Administrator
In reply to this post by prculley
I am very much against making the Gramps data model (even) more complicated
than it already is. I think that inputting data to use the places data model
correctly is already very complicated. I think that adding further types
administration types and dates would make the whole thing even more
unmanageable than it already is.

I think that future work on Gramps should concentrate on improving the user
interface and making it easier to input data in general (not specifically
only in the case of places).

Tim.



--
Sent from: http://gramps.1791082.n4.nabble.com/GRAMPS-Dev-f1791083.html


_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: Rethinking Gramps Place data model

Nick Hall
On 15/02/2019 21:26, Tim Lyons wrote:
> I am very much against making the Gramps data model (even) more complicated
> than it already is. I think that inputting data to use the places data model
> correctly is already very complicated. I think that adding further types
> administration types and dates would make the whole thing even more
> unmanageable than it already is.


Did you read my related post in the gramps-users list?

Which place enhancements are you against in particular?

Why would adding an "Attributes" tab to the place editor make it more
complicated for users?  Anyone not requiring this feature would simply
not click on the tab.


>
> I think that future work on Gramps should concentrate on improving the user
> interface and making it easier to input data in general (not specifically
> only in the case of places).


I would like to see improvements to Gramps data entry.  The addition of
source-based data entry would be a big improvement.

However, there are no developers volunteering to do this work.


Nick.




_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel