Jump to content


Photo

Place Details - Comments and Thoughts


  • Please log in to reply
8 replies to this topic

#1 jdchess

jdchess

    Member

  • Members
  • PipPip
  • 6 posts

Posted 21 August 2017 - 10:25 PM

I'm new to the forums and have recently started using RM, but I've been using genealogy applications for a long, long time. I have read several discussions here in the forums regarding the use of the "Place Details" field, some recent, some not. I noticed that several folks have said that the "Place Details" field is usually lost when exporting to GEDCOM and importing into most other genealogy software. Here's a couple of things that I have noticed during some recent GEDCOM export / import testing...

 

The "Place Details" field in RM exports to an ADDR tag subordinate to the event. The GEDCOM 5.5.1 standard allows this particular use of the ADDR tag. So in that regard, RM is compliant in it's export of the "Place Details" field. I may be wrong, but I believe 5.5.1 standard allows this use of the ADDR tag in order for the PLAC tag to remain jurisdictional in nature and not include addresses or specific buildings or locations.

 

While it is true that many genealogy applications do not import the ADDR tag directly into a similar "Place Details" field, the info is not necessarily lost when importing GEDCOM to another application. I have tested importing an RM created GEDCOM with info in the "Place Details" field into FTM 2017 and each time the "Place Details" info has been imported to the notes for the event to which the ADDR tag was subordinate (with "Address:" in front of the data). I believe this is as it should be in the absence of a specific "Place Details" field. Several folks had mentioned FTM specifically in regards to "Place Details" info being lost on import and I wanted to help clear that up.

 

In addition, for kicks and giggles, I also imported the same RM created GEDCOM into an old version of Sierra Generations, and the "Place Details" info (ADDR tag) was also imported into the notes/memo field for the given event. Perhaps some folks who have different applications, both old and new, could do this same test and report the results.

 

I simply wanted to point out that RM is actually creating compliant GEDCOM in it's handling of the "Place Details" field, and that this data is not lost when exporting to GEDCOM and importing to another application (at least not always anyway). Seems to me that the failing is on the part of the other applications that do not have a concession for RM's compliant use of the ADDR tag. Since the GEDCOM standard allows for both ADDR and PLAC in order to create a distinction, one would hope that any application that claims to be GEDCOM compliant would do the same. Looks to me like RM is doing it's part.

 

Please forgive me if this has already been discussed.

 

Jason



#2 mjashby

mjashby

    Advanced Member

  • Members
  • PipPipPip
  • 182 posts

Posted 22 August 2017 - 03:03 AM

Jason,

 

I believe your conclusions about GEDCOM export/import are wholly correct with regard to the PLACe and ADDRess GEDCOM Tags/Database Fields and that issues lie mostly with different interpretations introduced by some of the major software developers/providers who all claim that their products are GEDCOM compliant but still create substantially incompatible 'dialects' of the language.  Ironically, this often leads users to obsessing about the 'inadequacies of the GEDCOM standard' rather than complaining about the real cause  that is poor interpretation/implementation/programming of the Standard by software providers who clearly don't have or, more probably, don't want to agree on a common understanding!  These issues usually remind me of the "two peoples divided by a common language" quotes.

 

Most of the applications that I've used do, in fact, have a Place Details 'field' or designation in their data structure, but don't always use that structure for GEDCOM import/export. Nor do they always make it obviously visible to users, leading to confused usage. Family Tree Maker (Ancestry) is a very significant transgressor in that regard, but then Ancestry also has a totally usable Census Tag/Data structure, but for some inconceivable reason chooses to completely ignore it, instead allocating all Census Events to Residence Facts even though that attribute may be demonstrably incorrect, i.e. just because people were enumerated at a specific (or sometimes non-specific) location on Census night doesn't necessarily mean that it was their residence.

 

Mervyn


MJA

"A Mac User with Windows Tendencies"


#3 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3568 posts

Posted 22 August 2017 - 06:12 AM

I'm probably one of the chief complainers about Place Details. When RM first introduced it, I embraced it enthusiastically because it made so much sense to me and because it made reports read so much better. I'm sure I spent hundreds of hours splitting things like cemeteries and hospitals (for birth and death) into Place and Place Details. But I gradually became aware that when I used my data with other software, the Place Details seemed to be "lost".

 

I think your analysis of the GEDCOM situation and the ADDR tag is correct and the use of the word "lost" may be a little bit inartful with what happens to Place Details. But nevertheless, it still seemed to me and continues to seem to me to this day that about the only way to assure that that the data that otherwise would be stored in Place Details in RM is fully shared with other software is instead to store the data as a part of the Place data. I usually emphasize cemetery names and hospital names, but there are other situations where Place data could benefit from data being stored in Place Details, such as Township names, the fact that someone was born "at the old home place" or at "her grandmother's house", etc. I now store all such variations on what logically is Place Details data in the Place data instead.

 

My wish for RM is that there be an option whereby it would merge Place and Place Details when it outputs the data. It's not just GEDCOM export that needs such an option. Such an option, for example, need to exist with the Family Search FamilyTree interface and with the ancestry.com interface. The Place Details data is lost when data is exchanged with FS/FT. The Place Details data already is merged with the Place data when data is exchanged using  the ancestry interface which is a good thing, but the data continues to be merged if the data makes a round trip back to RM. One might wish, for example, that the the Place Details data be stored somewhere else in ancestry.com when it goes from RM to ancestry.com and that it be restored into Place Details in RM to complete the round trip.

 

It's not a simple problem, but it seems to me that the minimum requirement be that there be an option for GEDCOM export and for the FS/FT interface to merge the Place Details data with the Place data, just like already happens with the ancestry.com interface. And better still would be something that splits the Place Details in RM to complete the round trip.

 

Jerry



#4 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 212 posts

Posted 22 August 2017 - 07:23 PM

I'm also one of those complainers about place details. I also think that putting the place details in the ADDR GEDCOM tag is incorrect. The ADDR tag, based on the standard, is for full addresses, and "should be formed as it would appear on a mailing label". Many people place things like, "city cemetery" or "St. Jude's Hospital". Not all place details would be full addresses.

I advocate, like Jerry, placing all place information in the place field rather than using the place detail.

Sorry for the GEDCOM interjection!

#5 jdchess

jdchess

    Member

  • Members
  • PipPip
  • 6 posts

Posted 23 August 2017 - 05:23 PM

Actually, the GEDCOM 5.5.1 standard does in fact allow the use of the ADDR tag subordinate to an event tag (page 32 of The GEDCOM Standard, Draft Release 5.5.1).
 
While the 5.5.1 Standard does state that the "address structure should be formed as it would appear on a mailing label," this is in regards to a full address which is not required when using the ADDR tag. While the ADR1, ADR2, and ADR3 tags require the use of the ADDR tag first, as they must be subordinate to it, the reverse is not true. The ADDR can be used validly without the additional address lines.
 
Furthermore, page 41 states the following in regards to the ADDR tag (ADDRESS_line:=) :
 
"Typically used to define a mailing address of an individual when used subordinate to a RESIdent tag. When it is used subordinate to an event tag it is the address of the place where the event took place. The address lines usually contain the addressee’s name and other street and city information so that it forms an address that meets mailing requirements." (bold emphasis is mine)
 
Page 83 gives the following definition for the ADDR tag :
 
"The contemporary place, usually required for postal purposes, of an individual, a submitter of information, a repository, a business, a school, or a company." (bold emphasis is mine)
 
Notice that while these explanations and definitions do say that the ADDR tag is typically used for a complete mailing address, they do not require it to be or limit it's use in that way. Also, I would like to point out one of seven definitions of the word "address" from Dictionary.com..."the place or the name of the place where a person, organization, or the like is located or may be reached."
 
 
The primary point I was trying to make is that RM, in it's use of the ADDR tag when exporting the "Place Details" field, is creating valid GEDCOM output. If another genealogy application, which claims to be GEDCOM compliant, doesn't read or import that valid GEDCOM correctly, you can hardly blame RM. I do understand that you want to make the data as "portable" as possible. I'm completely, 100% with you on that, and there is certainly nothing wrong with RM trying to make it's exported data as compatible as possible. It just seems to me that there should be a push for better compliance on the destination applications (desktop and web-based) that are not correctly importing valid GEDCOM.
 
In regards to putting all place information (church, cemetery, hospital, residence, etc.) into the place field...  I don't necessarily have an issue with this, and doing so will, for the most part, ensure that all place data is "portable." However, doing so does create bad GEDCOM output. The GEDCOM standard (page 58-59, 91) clearly states that the PLAC tag and PLACE_NAME are for jurisdictional entities. Locations such as hospitals, churches, cemeteries, etc., are not jurisdictional in nature, and therefore, in regards to GEDCOM, do not belong in the place field.
 
Some folks would argue that details such as those, in the absence of a "Place Details" field, belong in the notes for the given event. This would also help ensure data portability, as notes are usually transferred correctly to other applications through GEDCOM.


#6 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 212 posts

Posted 24 August 2017 - 08:14 AM

GEDCOM uses Words like typical and should often when they were hedging their bets to say that there may be a case that some place in the world a different standard may be used, such as an address in some location of the world may not have a component used by other address lables. For instance many rural locations in Norwa France Germany that I've been to only have a farm name, postal code and county, no streets, cities or house numbers. This is why the ADDR/CONT tags are to be used going forward.

A church or cemetery can be jurisdictional because they have official jurisdiction over the documents and the properties of those entities. Jurisdiction is not exclusive to governmental agencies. When a person dies at sea, that is what should be placed in this field, not the governmental locations where the document was officially stored or placed into record. I have literally thousands of people who were born or died at home and farms that need to have those locations recorded in the place rather than the governmental location that ends at county.

None of your highlighted verbiage changes the basic definition that ADDR should only contain full addresses, and only the ADDR and CONT tag should be used, ADR1 CTRY etc are not to be used going forward.

Given all of this my only regret is that most software does not have a clue about these details and never will.

#7 jdchess

jdchess

    Member

  • Members
  • PipPip
  • 6 posts

Posted 24 August 2017 - 02:03 PM

KFN,

 

I don't really want to argue with you over the current GEDCOM standard. The simple fact of the matter is that the ADDR tag is in fact VALID when used subordinate to an event tag (BIRT, DEAT, ect.). You can argue that it's not a typical use case, but that alone does not invalidate its use in this particular situation, as I have clearly shown in the above post. Nowhere, that I can find, in the current standard (5.5.1) does it state that only a full address is acceptable when using the ADDR tag. If I missed this statement, please point out the page number.

 

In regards to "jurisdiction..." (not necessarily a lot to do with genealogy, but we are all historians of a sort)

 

The word is from latin "ius" which means "law" and "dicere" which means "to speak"...hence "to speak law." Jurisdiction is the authority given to a legal body to carry out justice or the law within a given field. Common usage can include the geographic area in which that authority applies. Now perhaps you could argue that "The Church" was in fact a jurisdiction at some point in history, but I believe that most would agree that this is no longer the case. (an exception being the Vatican maybe?) So no, I do not believe that a church or cemetery has the authority to administer justice or carry out the law in any given field of responsibility. Jurisdiction means more than simply being in control of "the documents and the properties of those entities." Anything you would place in the "Place Details" field (church, cemetery, hospital, residence, etc.) would be subject to the jurisdiction of the municipality in which it is located. Rural areas outside of incorporated cities and towns would be subject to the jurisdiction of the county (in the US), or at some point in history, perhaps to the jurisdiction of a township.

 

Your example of "died at sea" is not a good argument for you in this situation. "At sea" is not necessarily a complete designation. There are coastal waters that are within the jurisdiction of the state or country in which they are located, and there are international waters which are "Terra nullius." If the exact location is known and is within the legal borders of a coastal county and/or state, then it should be notated as such (with the same usage of "Place Details" and/or event notes applying). If the event occurred in international waters, the "high seas" if you will, then the place should be recorded as such. These would still be examples of jurisdictional locations (there are still maritime laws). I do not believe this would be comparable to using the place field for a hospital or cemetery.

 

In addition to jurisdiction, another reason to not include location detail (non-jurisdictional) in the place field would be to step toward place name standardization, which I know some will argue is not important or impossible to achieve (and I do not necessarily disagree entirely). There is no way to account for the myriad of ways in which someone might record many of these details regarding an exact location. I believe this is the reason that many folks say that details belong in the event notes. Again, I don't necessarily have an issue with full details being included in the place field if that is how you choose to do it, but as a side note, you certainly should not use the description field as I have seen some folks do in other applications. Placing anything in the description field for a given event when there is a date and/or place used will create invalid GEDCOM output.

 

 

I guess my point was that personally, I think RM's "Place Detail" solution is actually an elegant way to handle the problem...not a perfect solution by any means, but a step in the right direction nevertheless.

 

Jason

 

P.S. -- It's good to see someone else passionate about GEDCOM. :)



#8 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 212 posts

Posted 24 August 2017 - 04:38 PM

"P.S. -- It's good to see someone else passionate about GEDCOM. :)"

Been passionate for almost 30 years, but it is a losing battle, probably a lost battle.

#9 RobJ

RobJ

    Advanced Member

  • Members
  • PipPipPip
  • 56 posts

Posted 24 August 2017 - 05:34 PM

I'm happy to see this passion!  It's my opinion that data portability is going to become a very important product feature, in the near future.  That means widespread GEDCOM agreement, a consensus on a GEDCOM 6, whatever it may turn out to be.  GEDCOM HAS to win widespread acceptance, and genealogical companies need to be required to declare and maintain full compatibility with current standards.  The recent loss of certain ancestry tools (TMG, FTM, etc) has caused pain among a segment of genealogical users, and reminded others of the risks of all your eggs in one basket.  In my view, DNA testing and features are also causing some migration, especially toward public 'one world' trees.  Data portability should be an important requirement of all your tools.  It's clearly not now.

 

It's difficult for me to see how widespread agreement can be accomplished without the current gorilla, Ancestry.com.  But I believe it's in everyone's interest to get together and agree, even if it means Ancestry dictates some part of the agreement, parts of which may not be desirable to others.  To me, the most important requirement is that round trip data integrity between tools and sites is ensured. After that, the emphasis should be on allowing, importing, and exporting as much detail as possible, even if your tool cannot handle as much detailed info as another tool, or breaks it up differently.  There will probably always be some incompatibilities in field layouts.