"Y" in Death Location
Posted 09 February 2014 - 12:37 PM
Posted 09 February 2014 - 01:39 PM
The importing program must interpret that it is a location rather than an indicaton that the person is no longer living.
Posted 09 February 2014 - 05:45 PM
Posted 09 February 2014 - 07:55 PM
Try Search - Search and replace - Field to search = Places.
Search for -- Y
Replace with --
That is a Y in the search for field and leave the replace with field blank.
It might work.
I would check the Match Case box and go through one at a time to be sure it doesn't nock out the Y in names like New York.
------------ adeded ---------
YES, you will have to click the SKIP button on most of the finds.
Posted 09 February 2014 - 10:01 PM
0 _EVDEF DEAT 1 TYPE P 1 TITL Death 1 ABBR Death 1 SENT [person] died< [Desc]>< [Date]>< [person:Age]>< [PlaceDetails]>< [Place 2 CONC ]>. 1 ROLE Witness 2 SENT [ThisPerson] witnessed the death of [person]< [Date]>< [PlaceDetails]>< [ 3 CONC Place]>. 1 PLAC Y 1 DATE Y 1 DESC YThis is not the Death event for a person; rather, it is the definition of the Death fact type recognizable pretty well only by RootsMagic software. The Y beside PLAC, DATE, DESC signifies that these fields are enabled for this fact type. "N" would signify the field is disabled.
Try an export with that checkbox unchecked and see if you can find any lines like "2 PLAC Y" within a block starting "1 DEAT" (the block ends with a line beginning with 0 or 1).
Posted 09 February 2014 - 11:11 PM
The GEDCOM file exports: "1 DEAT Y"
If the living flag is unchecked and there is no death fact.
It exports just: "1 DEAT"
If there is a death fact.
If there are dates and/of places there are other tags: "2 CAUS", "2 _SENT", "2 DATE", "2 _SDAT", "2 PLAC" and "2 ADDR"
The two with the leading underline are ommotted if you do not include the RM specific things in the exported GEDCOM.
Otherwise the death area is about the same.
Posted 10 February 2014 - 09:44 AM
The occurrence of an event is asserted by the presence of either a DATE tag and value or a PLACe
tag and value in the event structure. When neither the date value nor the place value are known then
a Y(es) value on the parent event tag line is required to assert that the event happened. For example
each of the following GEDCOM structures assert that a death happened:
1 DEAT Y
2 DATE 2 OCT 1937
2 PLAC Cove, Cache, Utah
! All GEDCOM lines have either a value or a pointer unless the line contains subordinate
GEDCOM lines. In other words the presence of a level number and a tag alone should not be
used to assert data (i.e. 1 DEAT Y should be used to imply a death known to have happened but
date and place are unknown, not 1 DEAT ). The Lineage-linked form does not allow a
GEDCOM line with both a value and a pointer on the same line.
While 5.5.1 was never elevated to a standard, the 5.5 GEDCOM Standard included the same specifications:
http://frank.vancaen...te/gedcom55.pdf pg 32
The presence of a DATE tag and/or PLACe tag makes the assertion of when and/or where the event
took place, and therefore that the event did happen. The absence of both of these tags require a
Y(es) value on the parent TAG line to assert that the event happened. Using this convention protects
GEDCOM processors which may remove (prune) lines that have no value and no subordinate lines.
It also allows a note or source to be attached to the event context without implying that the event
Posted 23 August 2014 - 09:15 AM
That clarifies it, Alfred, and a quick check of the GEDCOM 5.5.1 draft spec confirms that RootsMagic is exporting the Death fact correctly when the Living flag is unset and there is no Death or Burial event entered. Therefore, the importing program is misinterpreting it and is at fault.
The reciprocal conclusion, based on recent investigation of importing TMG9 GEDCOM, is that RootsMagic dishonours the GEDCOM specification in that it does not import a Citation or Note for a parent DEATh tag having a Y(es) value. It ignores all child tags of n DEAT Y and merely lists them without line number or explanation in the .LST file. All it does is clear its Living flag. When there is a child tag of 1 DEAT Y, RootsMagic should not only clear the Living flag but also add the Death fact with the values from the child tags.
Until this issue is cleared, anyone importing a GEDCOM from TMG and likely other programs would be wise to inspect it for the presence of "1 DEAT Y" lines immediately followed by 1 or more lines beginning with 2 and replace it with "1 DEAT".