use of BURI (for ashed) in case of cremation

[coret]

When a person is cremated, sometimes urns are placed in a cemetery or ashes are scattered. This place often differs from the place of cremation (or at least the ceremony).

BURI is now defined as "Disposing of the mortal remains of a deceased person."

Information on the event (date and/or place) of placing an urn in a cemetery of the event of scattering of the ashes could be placed under the BURI tag (when looking at the BURI definition), but this feels incorrect to me as a person is either buried or cremated.

[Norwegian-Sardines]

A cremation could also be buried. Burial is the disposition of the deceased, this can take many forms depending on custom including, scattered, at sea, inhumation, scaffolding, green, donation to science, cript, and others.

[tychonievich]

Despite the name of the BURI structure, it is not defined to indicate burial specifically, but rather any disposal of remains. I propose we change the title of BURI from "Burial" to "Disposal of remains" and add "implies BURI" to the end of its description to avoid incorrectly implying it suggests burial.

BURI was present as a generic structure for all event types in the first public version of GEDCOM (v3.0), defined as "the event of disposing of the mortal remains of a person who has died." CREM was added as a special subtype of BURI much later (v5.4). On page 35 of the 5.4 PDF we also see that subtype relationship in a description of the TYPE structure:

The TYPE tag is also optionally used to modify the basic understanding of its superior event. For example, if the CREM tag had not been defined, then the following could have been used to modify the burial event to mean disposal by cremation:

0 INDI 1 BURI 2 TYPE "Cremation"

In drafting 7.0.0 we discussed if we should add other subtypes of BURI (such as BURIAL "disposal by placement under earth or in tomb"), or remove CREM as redundant, but ended up doing neither.

[Norwegian-Sardines]

I agree that CREM should be on the list for depreciation with BURI.TYPE enumeration including {inhumation, cremation, at sea, mausoleum, other} and potentially other depending on customs (native American “burial tree”).

[coret]

OK, but I still see genealogists want to record both the cremation event (the ceremony) and the place of the urn. And, when we are talking about a burial, do we mean the ceremony or the grave?

[Norwegian-Sardines]

By cremation event do you mean the information about who did the cremation?

By ceremony do you mean the wake/visitation? That could be another option on the BURI.TYPE tag.

Not to diminish your thoughts in any way, but, sometimes we get really deep in the weeds on all of the possible events a person can have! I only have a few people with wake information and that always becomes a note on the BURI tag.

I have several cases were the burial plot was reused at a later date, the remains were exhumed and either presented to the family or moved to a new location. This become a note in the BURI tag, rather than a new event entry.

[coret]

I agree that we should be careful not to identify and describe each and every micro event. But the definition should be clear to everyone (programmers and genealogists) what specific events entail. And what to do with other/extra information. It's a balance between structured and unstructured data.

For me as developer of a "GEDCOM publication service" it was unclear that users used the cremation event and the burial event for the place of the urn/ashes together (I assumed these were mutual exclusive).

[dthaler]

There are plenty of GEDCOM files that use CREM and BURI on the same person. Cremation, as defined in an English dictionary such as at dictionary.com or m-w.com, changes the form of the remains but not the location, so the place would be the crematory. Burial (or burying), as defined at dictionary.com, "to put (a corpse) in the ground or a vault, or into the sea", and so changes the location but not the form, so the place would be the resting place, whether a grave, mausoleum, sea, or otherwise.

Hence to the average English-speaking user, "cremation" is not a type of "burial". Putting an urn of ashes into a grave, or scattering ashes at sea, would be the "burial" of the ashes. And the places of cremation and burial may be completely different, i.e., different states or countries even.

I did a google search on '"1 GEDC" "1 CREM"' and easily found several public GEDCOM files that used CREM and BURI on the same person, with the above meanings. Examples:

• http://[lovelock.free.fr/gedcoms/lambeth-aust-nz-line.ged](http://lovelock.free.fr/gedcoms/lambeth-aust-nz-line.ged) has, from Webtrees:

  1 BURI
  2 DATE 30 JUN 2001
  2 PLAC Whangamata, New Zealand
  1 CREM
  2 DATE 28 JUN 2000
  2 PLAC Manakau Crematorium, Papatoetoe, Auckland, New Zealand

• http://[www.olypen.com/tinkers/rods.ged](http://www.olypen.com/tinkers/rods.ged) has, from Family Tree Maker:

  1 BURI
  2 DATE AFT 01 OCT 1981
  2 PLAC Chapel of the Chimes, Oakland, Alameda County, California
  1 CREM
  2 DATE 01 OCT 1981
  2 PLAC Cedar Lawn Memorial Park, Fremont

etc.

[Norwegian-Sardines]

For me as developer of a "GEDCOM publication service" it was unclear that users used the cremation event and the burial event for the place of the urn/ashes together (I assumed these were mutual exclusive).

I understand completely. I work with a lot of data "in the wild" as well, for academic reasons I'd like to know more about the data found in these two seemingly (rarely seen) mutually exclusive events. But the reality is that some people select an event/attribute just because that value is available. My goal is to create new tag where needed, but to better define old tag with TYPE enumerations that help to define the tag use as well. Removing the CREM tag at some point, but adding BURI.TYPE "Cremation" now could move people to a better use (in my opinion) of tags.

As I outlined previously I can see in modern times an occasional cremation followed by an inhumation of the ashes, just like I can see; a) a cremation followed by a scattering, b) an inhumation followed by an exhumation followed by an urn storage. These can all be wrapped up in two different ways depending on how important the detail is.

1) One BURI event with lots of notes about the various steps/events 2) Multiple BURI events each with its own TYPE to describe the step, with dates or places or just a "Y" (indicating the event happened).

I realize some software does not have a way to deal with multiple events of the same "kind" (i.e. multiple BIRT, DEAT tags) but this is reality when I'm doing research. I could find multiple sources that don't agree on a date or place and I enter them both as distinct tags, even when some events are seen by most as a singularity event. I do this because I have not made a conclusion yet, I'm just collecting information. Sometime a birth or death (or any data or relationship) has no conclusive evidence and must remain subject to change and will remain in the database as two events of the same kind until such time a conclusion can be made, if ever.

[Norwegian-Sardines]

If you do a Google search on "Types of Burial" the term cremation is included in the list. A definition of cremation on one site I looked at was:

Cremation is one of the most common performances of burial.

In some religious customs the only definition acceptable for "Burial" is the inhumation of the body, cremation is not allowed. However, I believe that GEDCOM needs to remove whenever possible a single use term that can have multiple meanings depending on the custom or tradition involved. Burial (the disposition of the deceased) can take many forms! This is why the definition has been outlined by Luther above!

[Norwegian-Sardines]

As an additional note,

GEDCOM is a data transfer standard, not a data storage schema. As such the tag/field name should have little bearing on the data expected/contained in the payload, but for each payload a concise definition of the data contained in that payload must be created.

This is what a good "data dictionary" does, spelling out in no uncertain words what the sender put there and what the receiver expects to find. This has been the greatest failing of past GEDCOM documents, the sometimes wishy-washy terms used and the chance for interpretation rather than setting down expectations. This is not a condemnation of GEDCOM, but a reality of the content found and passed along over the years.

The point I'm making is:

Applications can differentiate all they want between an inhumation or crypt disposition as a burial vs a cremation as some other term, but the BURI tag can (if well defined in the data dictionary) can represent both (and more), just so long as the software takes their recordings of a "Burial" and "Cremation" (or scaffolding, green, donation to science, at sea, ...) to generate a GEDCOM that uses a TYPE (from the enumerated list) to denote the definition of the data transmitted.

We are stuck with the BURI tag at this time, but it could be called "XYATA" for all I care at some time in the future. Remember, for same sex families we still use WIFE/HUSB which imply things to some customs but in the data dictionary we do not imply that sex/gender or the actual fact of the occurrence for a marriage. Domestic partners my not call themselves Wife/Husband in any way.

[albertemmerich]

Gedcom-L discussed this issue. Summary: 1. CREM should not be modified as long as the more general issues #117 and #303 are not finally discussed and decided. Modification of CREM will imply implementation activities for applications. It is stongly recommended to avoid double implementation by a short hand solution for CREM and a following solution for the general problem. 2. Any typification by TYPE as substructure of an event should be aware of localisation. Therefore we need enumerated content for TYPE to have a data transfer with clear interpretation. A language-dependent free text content does not fulfill this requirement. 3. Gedcom-L considers burial and cremation as two different events, which may happen on different dates and at different places. The GEDCOM structure can solve this by different tags or by one tag representing a group of events and differentiate this by enumerated TYPEs. As there a lot of other events after deceasing of an individual, this topic is part of the more general discussion how to handle this and other groups of events. We strongly recommend to have one solution in GEDCOM standard for alle groups of events in a following major version of standard.

As summary we recommend to take the burial/cremation discussion as one example for the discussion of various events not yet implemented with a clear interpretation in the standard, and solve this together with the other events.