Wikidata:Property proposal/Burial date

date of burial or cremation edit

Originally proposed at Wikidata:Property proposal/Person

Done: date of burial or cremation (P4602) (Talk and documentation)

Description	date on which this person was buried or cremated
Represents	burial (Q331055)
Data type	Point in time
Domain	person
Example	Bartholomeus Dolendo (Q4865218) -> 1626-05-27 : I let a precision: month to the death date, and was searching for the burial date property (that we know in https://rkd.nl/en/explore/artists/23546)
Planned use	to specify a date that is not a death date (in case, for example, of not knowing the exact death date)
Robot and gadget jobs	no
See also	start time (P580), place of burial (P119)

Motivation

Hello,

In some cases, we don't know the exact death date, but we do know the burial date. I think that if we want to be accurate, we should specify it.

To my mind, there are two options:

a whole new property (like date of death (Q18748141))
a qualifier for Q18748141 (like latest date (P1326))

Thank you, Daehan (talk) 14:05, 27 June 2017 (UTC)[reply]

Discussion

Support as a property (could be seen as a symetric counterpart of date of baptism (P1636)). Even when the date of death (P570) is know, it also could be useful when there is some time between death and burial. VIGNERON (talk) 14:54, 27 June 2017 (UTC)[reply]
- in Sweden you get your burial plot and then after maybe 50 years it ends ==> someone also can be buried at this location ==> its a time span with start and end date (start time (P580) --> end time (P582)). Adding another property 'date of burial' then we also need a property 'enddate of burial plot' - feels wrong direction - I have documented about 2000 graves on Norra begravningsplatsen (Q252312) see blog Salgo60 (talk) 07:43, 8 October 2017 (UTC)[reply]
Support ~~Wait~~ as 'date of burial' to stay with the naming of date of birth (P569) and date of death (P570). But please add an example of a concrete person. ChristianKl (talk) 16:30, 27 June 2017 (UTC)[reply]
- Example of graves that have start and end dates at cemetery Norra begravningsplatsen (Q252312) tinyurl.com/y7hjzczk as enddate is not exact it has precision decade - Salgo60 (talk) 13:17, 9 October 2017 (UTC)[reply]
Support Do we want to expand this to cremation as well? Mahir256 (talk) 16:38, 27 June 2017 (UTC)[reply]
Good observation. Maybe we should have a more generic word, with "burial" and "cremation" as qualifier? --Daehan (talk) 16:50, 27 June 2017 (UTC)[reply]
Weak oppose I would prefer a qualifier to death date than a complete property ; we already have too many of them for very precise things... I find a monthly date with a latest date (P1326) qualifie sufficient :) --Hsarrazin (talk) 05:54, 28 June 2017 (UTC)[reply]
Support --Manu1400 (talk) 19:00, 28 June 2017 (UTC)[reply]
Oppose: use start time (P580) as qualifier for place of burial (P119).
--- Jura 18:16, 29 June 2017 (UTC)[reply]
It would be good if we could find a name that includes cremation. ChristianKl (talk) 19:34, 1 July 2017 (UTC)[reply]
Support -- Marcus Cyron (talk) 00:43, 2 July 2017 (UTC)[reply]
Strong support Quite often we do not have date of birth (P569) but we do have date of baptism (P1636) which serves as a proxy, similarly we do not have date of death (P570) but we know when person was buried. And similarly that date is often used in similar way as death date. Current approach seems to save burial date in date of death (P570) as in Abraham Bosschaert (Q2821813), for whom we do not know the actual death date. Jura's proposal to use start time (P580) as qualifier for place of burial (P119) would be OK if that is what we do for date of baptism or if date of death (P570) was implemented as start time (P580) qualifier for place of death (P20). --Jarekt (talk) 21:18, 2 July 2017 (UTC)[reply]
- Date of burial is already added to place of burial that way. We don't do it exactly the same way for baptism, as the location is added with a qualifier to the date. Similar to mariage. Supposedly, it's rare that we know the date of burial, but not the place and we generally collect the place of burial.
  --- Jura 11:36, 4 July 2017 (UTC)[reply]
Support — Ayack (talk) 11:27, 4 July 2017 (UTC)[reply]
Why not use point in time (P585) as a qualifier for significant event (P793) burial (Q331055)? --Yair rand (talk) 20:07, 6 July 2017 (UTC)[reply]
( Oppose, in case that wasn't clear.) --Yair rand (talk) 23:05, 4 September 2017 (UTC)[reply]
Oppose use Yair rand solution. For data users its easier to have a single property which shows all significant life events instead of splitting it up to endless place- and time-properties. For example I designed once a webpage which shows biographical information about famous people. If significant event (P793) is used, the page would grow basically by itself. Now I would need to add everytime new lines of code after a property like this is created. --Pasleim (talk) 14:13, 14 July 2017 (UTC)[reply]

I still would prefer a separate property because it is easier to access it from Lua than dealing with qualifiers. But I would prefer Yair rand solution to Jura's because I do not have to know where someone is buried to save the date of burial. For example this gives me date of burial but not a place and I can not add a reference to individual qualifiers. Now I am worried that there might be more creative solutions to save Burial date and we different people will do it differently. --Jarekt (talk) 20:17, 14 July 2017 (UTC)[reply]

Yes! I was about to write this before I've read it! --Marsupium (talk) 16:36, 24 July 2017 (UTC)[reply]

You can still save it with place of burial ("unknown"), but it's likely that your value isn't referenced as good as it should.
--- Jura 12:42, 29 July 2017 (UTC)[reply]

place of burial ("unknown") is strange for the case where I just do not know it. Also place and date of burial should not be in the same statement so we can add separate references. Sources often state date of burial instead of date of death, but use place of death instead of place of burial, for example this reference. --Jarekt (talk) 13:40, 9 August 2017 (UTC)[reply]

Support — In biography, date of birth, death, baptism, and burial are fundamental datum and should be explicit. And lacking birth and death dates, and thus using baptismal and burial dates instead, is quite common. These are inherent events in any life (the two latter as proxies when the former are not known); unlike marriages, accessions to the throne, or shooting JFK (a presumably significant event in Oswald's life). --Xover (talk) 17:58, 18 July 2017 (UTC)[reply]
Oppose Per Jura1. Matěj Suchánek (talk) 17:36, 8 August 2017 (UTC)[reply]
Oppose +1 to Yair rand solution and Pasleim explication. Too many properties make query more complicated and may lessen wikidata usefulness. El Caro (talk) 16:51, 17 August 2017 (UTC)[reply]
Support Can add eaisly a useful information when you don't know when the death happen, but you have the date of burrial. I've just got the case with Thomas Maillard (Q22249365). Trizek (talk) 16:51, 17 August 2017 (UTC)[reply]
Comment I am writing a Lua code (c:Module:Creator) to create person infobox using Wikidata data. I can process date of birth (P569), date of death (P570), work period (start) (P2031), work period (end) (P2032), date of baptism (P1636) and floruit (P1317) properties using exactly the same generic code (c:Module:Wikidata date). However to get burial date I would need to have specialized code to try 2-3 different ways that information is stored now. Current state is very inconvenient for the tool writers. --Jarekt (talk) 13:54, 31 August 2017 (UTC)[reply]
Support this is an official date in a life and sometimes available in the sources, while the other not. I do think we should always try to fill date of death, sometimes derived from --Hannolans (talk) 22:00, 5 September 2017 (UTC)[reply]
Support From the examples given above, this is as important as date of baptism (P1636), and serves as proxy of date of death (P570) (just like date of baptism (P1636) serves as proxy of date of birth (P569). So to be consistent with those, we need it as a separate prop --Vladimir Alexiev (talk) 17:46, 29 September 2017 (UTC)[reply]
Oppose use Jura solution place of burial (P119)/start time (P580) as you also has normally an end date place of burial (P119)/end time (P582) when the person does not have access to the grave plot Salgo60 (talk) 07:33, 8 October 2017 (UTC)[reply]
Support ~★ nmaia ^d 01:05, 8 November 2017 (UTC)[reply]
Support --Giovanni Alfredo Garciliano Díaz ★ diskutujo 02:56, 12 November 2017 (UTC)[reply]
Support as date of obit, date of real committal Jura's way.--Ben Skála (talk) 10:08, 20 November 2017 (UTC)[reply]
@Daehan, VIGNERON, Salgo60, ChristianKl, Mahir256, Hsarrazin: Done as date of burial or cremation (P4602). Thierry Caro (talk) 06:59, 1 December 2017 (UTC)[reply]

@Thierry Caro: The name that came out of the discussion was "date of burial or cremation" and not "burial date". Unfortunately, the software copies the page name and not the label name into the field. ChristianKl (✉) 09:39, 1 December 2017 (UTC)[reply]

@ChristianKl: thanks do we have a model how to use it?

Today I use the following properties as qualifiers see example 6181340#P119

place of burial (P119)
- burial plot reference (P965) - plot location
- start time (P580) - date buried
- end time (P582) - date when the right to the grave plot expire
- coordinate location (P625) - coordinates

- Salgo60 (talk) 15:55, 2 December 2017 (UTC)[reply]

@Salgo60: We don't have a model that goes beyond the provided example. If you want to propose a model feel free to do that on the talk page of the property. You can also write property usage instructions. If someone disagrees with your proposal, they will say so. ChristianKl (✉) 15:59, 2 December 2017 (UTC)[reply]