[Gramps v6.0.6 on Windows 10 & 11]
Gramps includes a life event called ‘burial’. Do people use that event even if there is no body to bury, because they were cremated, and their ashes were not actually buried (interred) but were scattered somewhere?
If not, what is the best way to handle such an event?
If someone os cremated, I use ‘Cremated’ not ‘Burial’.
Yes, there is a ‘cremation’ event but after that there is another event, the ‘disposal’ of the ashes. Some are ‘buried’ / interred, some are scattered, e.g. at a favoured location of the deceased (not always legal, but it happens). [Some end up on a shelf in the surviving partner’s home, or even at the back of a cupboard of the surviving partner’s home only to be found after the death of the partner.]
Do Gramps users not bother to record this subsequent event?
In the Event Cremation I usually just put a note in the Description
Field as to the dispersal of ashes if known
phil
Thank you, that would also work for me.
There is the term inurnment for when the urn is buried.
Just create a custom event or write a custom type called “ash‑scattering ceremony”, interment of ashes, inurnment as DaveSch suggest, **or something similar.
**
Gramps users have to be careful in creating custom types for Events that mark vital statistics: Birth, Death, Marriage, Divorce.
For instance, a Cremation event is a Death fallback. But a Custom Event would not be.
The Fallback Events section of the wiki has a concise overview.
There is a difference between a cremation and what you actually do with the ash…
Burial is not the same as death, same goes for inurnment is not the same as cremation or death.
And if you shall be historical correct, you make an Event for what actually happened, not what Gramps needs as a fallback!
True enough. But it wasn’t what I was trying to say. I am trying to give information so people can weigh the tradeoffs for themselves. Then select the approach that gives them the most benefit for their needs.
Gramps uses an expensive “probably alive” calculation when the pertinent (vital statistic) life event cannot be found. Even though it might be expensive, the cost is worthwhile. It allows Gramps to avoid considering the whole tree. The awareness of fallback events extends the savings into the ‘fuzzy’ parts of the tree.
And the fallback events give visual (italics) feedback that both: the key statistic event is missing and offers an event date that would be in proximity for that missing date. It is more helpful than a blank.
But that feedback would be missing when using a custom event. Because the custom event will not be aware of it in the fallback calculation.
If you decide that you prefer a custom type, you do not necessarily have to lose the fallback feedback and other benefits… but it requires a bit of hacking.
For what needs to be changed in such a hack, there is an excellent example:
@DaveSch felt that Gramps should have a Stillborn event to simplify data entry. And added Feature Request 11554 to track his proposed solution and get it into the queue for inclusion in a future release. Because it added some compatibility with an unsupported GEDCOM 5.5.1 tag (although GEDCOM7 changes the approach), it was rolled into the Gramps 5.2 release.
But the file changes (a shown in for the related pull request on GitHub) can be very instructive on what needs to happen to :
While doing this change, Dave generalized the PeopleModel’s awareness of Fallbacks. Simplifying future extensions to the lists of Fallback types… now they will require only changing a single source code file. (He points out that Reports and Charts will need reviewing for their flexibility in Fallback awareness.)
I don’t use arbitrary calculations, nor do I use arbitrary values in any way when it comes to historical events.
It’ would be better if Gramps could support custom types of events for those who want to utilize these calculations.
It could be as simple as one or two checkboxes when creating or editing an Event:
[ ] Fallback for Birth
[ ] Fallback for Death
“probably alive” is a Gramps built-in calculation. (Where the Preferences Limits tab is the only user-facing interface.) It is not a reflection about any particular person’s methodology.
Adding interface would be the next step in the evolution. Such added complexities are normally deferred until there is a proven demand. So far, there has only been 1 instance (or at least, that I recall in the last 10 years of watching) where someone has been vocal about a need and the same user shared their hack.
Does it really rise to that level of need yet? I’d place the ability to re-organize Custom Types in with the alphabetized pre-defined Types well above that. And it is still on the back-burner… probably due to little community outcry, or, that it hasn’t piqued developer interest.
“Probably Alive” is an arbitrary calculation and not something that matters in actual genealogical research. It’s a ‘nice to have’ feature at best.
What I don’t understand is why you’re spending so much time explaining something you already know I don’t consider relevant. It comes across as trying to have the last word rather than addressing the actual point.
All I said was that this could be handled with a custom event type.
Scattering of ashes and similar events have nothing to do with death, burial, or cremation. These events can occur years after the cremation and cannot be treated as indicators of death without distorting the historical record.
You’re now introducing arguments I never made. My point has only been that these events are separate from death‑related event logic and should be handled as custom event types. Everything else you’re bringing in is unrelated to what I actually wrote.
I am not explaining necessarily for you. Information posted in this thread will be used to update the wiki. (Eventually) So, fully composed responses will be useful until then and be used for copy’n’paste in the wiki article. So rather than re-cover the stale thought process, I flesh it out the content while fresh.
However, since I ‘quote’ a particular sentence in your posting for responding, Discourse notifies you and may seems like we are in deep discussion… when the content is really for future reference.
“If” the intention is to provide accurate information for future reference, then it’s even more important that the information posted is correct. What you wrote above is not accurate.
You’re presenting your replies as neutral documentation, but you’re responding directly to statements I never made and introducing claims that don’t reflect the actual discussion. That creates a misleading record, not a useful reference.
“If” the goal is to update the wiki, then the information should be based on what was actually said, not on assumptions or arguments introduced after the fact.
Again: scattering of ashes, urn interment, and similar ceremonies cannot be used as a fallback for death, burial, or cremation, because these events can take place years after the death, as I’ve already written.
Cremation is a fallback for death in the same way burial is a fallback for death.
Urn interment or ash scattering are NOT.
Therefore, there is no problem using a custom event type for these kinds of events.
We have been around “probably alive” before for me the Data page in
Preferences should be changed from “Display ages for events after Death”
to “Display ages for all events” so the whole function is on or off.
Personal point of view not expecting to see anything changed.
phil
In the case that prompted my original post the ashes were laid to rest about 12 years after death.