Documentation

date of birth
date on which the subject was born

Description

Date of birth of a living thing; see also: date of death (P570); when date of birth is unknown, use date of baptism (P1636) for date of baptism

Represents

date of birth (Q2389905)

Data type

Point in time

Template parameter

Basic property used by all biographical infoboxes.

Domain

According to this template: person (Q215627), organism (Q7239)

According to statements in the property:
human (Q5), fictional character (Q95074), human whose existence is disputed (Q21070568), house cat (Q146), dog (Q144), horse (Q726), fictional animal character (Q3542731), fictional organism (Q30017383), legendary figure (Q13002315), hypothetical person (Q75855169), fictional human formerly considered to be historical (Q64520857), prosopographical phantom (Q64643615), individual organism (Q110224119), Hominin fossil (Q18347143), stillborn child (Q2345820), captive mammal (Q57812611) or clonal colony (Q611804)

When possible, data should only be stored as statements

Allowed values

According to this template: Past dates

According to statements in the property:

When possible, data should only be stored as statements

Usage notes

태어난 연도가 없거나 기록이 없어 태어난 달과 일만 있는 경우 이 속성 대신 P3150(태어난 월·일)을 사용하세요.
Utilitzeu P3150 (mes/dia nascut) en lloc d’aquest atribut si només teniu el mes i el dia del naixement perquè no hi ha anys de naixement ni registres.

Example

Jude Law (Q160432) → 29 December 1972
Isaac Newton (Q935) → 25 December 1642
Lucy F. Simms (Q17386627) → 1855
1857
1859
Manco Capac (Q165968) → 13^th century

Format and edit filter validation

Abuse filter #55

Tracking: same

Category:Pages with P569 (date of birth) identical with Wikidata (Q19332013)

Tracking: differences

Category:Pages with P569 (date of birth) different from Wikidata (Q19332014)

Tracking: usage

Category:Pages using Wikidata property P569 (Q21096033)

Tracking: local yes, WD no

Category:Date of birth not in Wikidata (Q19332015)

date of death (P570)

Discussion[edit]

More than one date[edit]

How do we claim more than one possible date? For example, Edward the Confessor was born in the year 1003, 1004, or 1005. Danrok (talk) 15:23, 30 May 2013 (UTC)[reply]

There are two options: the first one is to just add the more relevant date "1005" and click on "advanced adjustment" and set the precision to "decade". It will mean that the date is between 995 and 1010. The second one is to add 1003, 1004 and 1005 as possible values (maybe with sources) by clinking to the "add" button in the bottom of the "date of birth" statement box. I've added the first solution to the Edward the Confessor item. Tpt (talk) 15:49, 30 May 2013 (UTC)[reply]

I'd favor the second option of listing the possible dates, because it provides more specific information. Danrok (talk) 15:53, 30 May 2013 (UTC)[reply]

If you want, change the values

. There is no problem. Tpt (talk) 16:58, 30 May 2013 (UTC)[reply]

Animals[edit]

Is it possible to use this property for animals too? --Pasleim (talk) 22:26, 12 June 2013 (UTC)[reply]

Yes, this property is applicable to any instance of an organism. See Wikidata:Project_chat#spilt_date_of_birth_.28P569.29.2C_date_of_death_.28P570.29_and_coordinate_location_.28P625.29.3F (permalink) for more discussion on this. Emw (talk) 01:09, 22 October 2013 (UTC)[reply]

Date formatting[edit]

Seems that we should be giving guidance on how to enter dates, and it should either be a template form, or a link to a page. — billinghurst sDrewth 06:37, 16 June 2013 (UTC)[reply]

Support, billinghurst! For example the problem of #More than one date arose at my own talk page, too. We have to find a way to deal with cases covered by commons:Template:Other date. Help:Modeling#Time & dates might become the right place for such a guidance. --Marsupium (talk) 17:56, 29 November 2013 (UTC)[reply]

Wikidata talk:WikiProject Visual arts/Item structure Date should be best place. --Oursana (talk) 11:10, 2 December 2013 (UTC)[reply]

The questions do not only concern visual arts. However, only the mapping of commons:Template:Other date might be well placed on the pages of WikiProject Visual arts, I have tried to start a general discussion at Help:Modeling/general/time#Modeling of uncertain dates. If you prefer another place we can move the discussion or parts of it. LG, --Marsupium (talk) 15:49, 2 December 2013 (UTC)[reply]

I am with you. Danke und LG--Oursana (talk) 20:22, 2 December 2013 (UTC)[reply]

How to call the data[edit]

How can I call this data inside a template on Wikipedia? Calling simply property 569 doesn't seem to give an answer. -Theklan (talk) 21:12, 16 September 2013 (UTC)[reply]

You have to use a Lua-module at the moment. The data is stored in a format like: "+00000002013-09-17T00:00:00Z", which you have to convert to something more easlily readable for humans. There are also such parameters as precision, calendarmodel, timezone, before and after you have to look into! -- Lavallen (talk) 07:10, 17 September 2013 (UTC)[reply]

And is there any LuaModule done with this? -Theklan (talk) 10:38, 17 September 2013 (UTC)[reply]

Ok! I found it in Module:Wikidata... but the names appear in english, and not in local language. -Theklan (talk) 10:47, 17 September 2013 (UTC)[reply]

Which project are we talking about? -- Lavallen (talk) 13:24, 17 September 2013 (UTC)[reply]

eu:wp, for example. -Theklan (talk) 15:46, 17 September 2013 (UTC)[reply]

The documentation is in English yes, the code is not perfect (it does not take years BCE in account, not precision and not non-Gregorian time, but the rest looks ok). What is the problem? You can translate the documentation if you like, so also the rem-lines in the code... -- Lavallen (talk) 17:03, 17 September 2013 (UTC)[reply]

The problem is that month names appear in english, not in local name when they're called. January, instead of Urtarrila. Or March, instead of Martxoa. -Theklan (talk) 20:43, 17 September 2013 (UTC)[reply]

Ok, that's a problem! But it's maybe something for the Scribunto-developers or maybe something is missing in Translatewiki! -- Lavallen (talk) 05:27, 18 September 2013 (UTC)[reply]

Which is the Translatewiki section for Wikidata? Is it inside mediawiki? -Theklan (talk) 16:26, 7 October 2013 (UTC)[reply]

I do not know, maybe you should search under "wikibase", but in the examples above, I do not think it is related directly to Wikidata, but something else, maybe Scribunto. -- Lavallen (talk) 17:45, 7 October 2013 (UTC)[reply]

Ok... so what could/should I make? -Theklan (talk) 21:58, 9 October 2013 (UTC)[reply]

Century problems[edit]

I've been trying to enter the date of birth for Aldfrith (Q737618), whose birthdate is unrecorded but sometime in the 7th century (his father died in 670). However, if I enter "600s" the system seems to keep interpreting that as a decade (600-609) rather than a century (600-700); there's an option to set "century" as the precision but it doesn't seem to be working. Suggestions? Andrew Gray (talk) 13:05, 20 July 2014 (UTC)[reply]

Looks like bug in editor. There is workaround: click "edit", select value, type "600", click save. — Ivan A. Krestinin (talk) 13:17, 20 July 2014 (UTC)[reply]

Why the bad data violations?[edit]

Looking at Wikidata:Database reports/Constraint violations/P569 there are recordings of bad values. Is this because these dates of birth are years only? If so, while specific dates are better, they often will not exist, and we need a designated means how to have 'year only' and to give demonstrations. Is this a case of setting as a custom value? Please ping me when there is a response}} — billinghurst sDrewth 15:54, 19 August 2014 (UTC)[reply]

It should rather come from {{Constraint:Conflicts with}} currently with has part(s) (P527); instance of (P31): twins (Q14756018), sibling duo (Q14073567), Wikimedia disambiguation page (Q4167410); coordinate location (P625)

Looking at Q2365222, I don't see which one it could be. It does have a year as date of birth. Maybe there is a bug somewhere. @Ivan A. Krestinin: would know. --- Jura 07:41, 20 September 2014 (UTC)[reply]

Q1515154 does have an incorrect date format. --- Jura 07:44, 20 September 2014 (UTC)[reply]

Value is listed as "Bad value" in two cases: 1. Wikidata core mark value as badvalue. 2. ISO presentation of the date is invalid, for example it contains month number zero. Second check is too hard maybe. Some of these values are really invalid (example), another are displayed correctly. But Wikidata editor never use bad ISO presentation. So I think bot must not use it too. I have very old code that fix part of bad ISO dates, but not all. — Ivan A. Krestinin (talk) 07:52, 21 September 2014 (UTC)[reply]

Date of baptism?[edit]

Sometimes only the exact date of baptism of a person is known, e.g. from church records, and usually serves as good approximation. Can we add a qualifier for use within P569 for that? A currenct solution can be studied at Ludwig van Beethoven (Q255) (P565 with a P387 (P387) qualifying the date as "erroneous" plus baptism (Q35856) as significant event (P793) - clumsy and far from optimal I would say). -- Gymel (talk) 14:47, 9 November 2014 (UTC)[reply]

There is now date of baptism (P1636) to use for this case.--Giftzwerg 88 (talk) 19:13, 11 January 2015 (UTC)[reply]

Date of birth for fictional humans[edit]

Any objection to adding fictional humans to the classes allowed to make use of this property? I just stumbled upon this when checking violations for Q2738. Same for date of death. --LydiaPintscher (talk) 17:52, 3 April 2015 (UTC)[reply]

Allowing fictional humans could lead to constraint violations. Although the data model allows dates well before the beginning of the universe and well after the expected destruction of the Solar System, various other constraints may require more ordinary values, which might not apply to fictional humans. Then there is T. H. White's version of Merlin, who lived backward in time and died before he was born. Jc3s5h (talk) 18:14, 7 April 2015 (UTC)[reply]

I think fictional humans used to be accepted. It's just that someone reworked the "person" definition. I'm less convinced about including non-humans. --- Jura 18:18, 7 April 2015 (UTC)[reply]

@Jc3s5h: But not allowing them also leads to constraint violations. --LydiaPintscher (talk) 11:40, 17 April 2015 (UTC)[reply]

Формат дат[edit]

Где исправит формат дат? Тут должно быть 1949 шаран 15 апрель. -- Дагиров Умар (talk) 22:33, 15 June 2015 (UTC)[reply]

Where to change the date format. here It must be so 1949 шаран 15 апрель. -- Дагиров Умар (talk) 22:47, 15 June 2015 (UTC)[reply]

@Дагиров Умар: here: https://ce.wikipedia.org/wiki/Модуль:Dates . -- Vlsergey (talk) 07:41, 16 June 2015 (UTC)[reply]

Спасибо. -- Дагиров Умар (talk) 10:08, 16 June 2015 (UTC)[reply]

Dates available at Wikipedia[edit]

At frwiki, I added a maintenance category for P569: fr:Catégorie:P569 absent de Wikidata. Currently just one or two templates feed into that. --- Jura 10:41, 16 June 2015 (UTC)[reply]

Date output[edit]

How is date output localized on a property like this, especially when the form is something like "12th century" rather than something like "23 March 1786"? StevenJ81 (talk) 16:29, 17 June 2015 (UTC)[reply]

currently renders as "12. century" (12. century). Eventually this might be localized.

For now, I think one is expected to use

{{#invoke:Wikidata|formatStatementsE|item=Q2161498|property=p569|lang=it}}

which currently renders as "XII sec." (XII sec.) --- Jura 16:46, 17 June 2015 (UTC)[reply]

Thank you, Jura. Even that, in turn, must be localized somewhere. Here? Translatewiki? StevenJ81 (talk) 17:29, 17 June 2015 (UTC)[reply]

Maybe: https://www.wikidata.org/w/index.php?title=Module:I18n/date&action=edit --- Jura 17:33, 17 June 2015 (UTC)[reply]

Problem with century in Greek[edit]

The word "century" is been show with english word than greek one when you use wikidata in greek. How to solve it? Xaris333 (talk) 18:38, 4 July 2015 (UTC)[reply]

{{#invoke:Wikidata|formatStatementsE|item=Q2161498|property=p569|lang=el}} currently renders as "12ος αιώνας" (12ος αιώνας). The definition is in Module:I18n/complex date.

For #property, see https://phabricator.wikimedia.org/T104447 --- Jura 19:26, 4 July 2015 (UTC)[reply]

Qualifier determination method (P459) use with date of birth (P569)[edit]

I made the item estimated based on dates from educational cursus (Q20847053) to add dates with decade precision. --- Jura 09:29, 21 August 2015 (UTC)[reply]

@Jura1: what is "educational cursus"? can you give me a link to this method, please? -- Vlsergey (talk) 09:44, 21 August 2015 (UTC)[reply]

Click on whatlinkshere to find two samples. --- Jura 09:51, 21 August 2015 (UTC)[reply]

The samples tells me nothing, so i'm still curious about method itself. Can you provide more detailed description of it? My poor English tells me it something like "we studied this at school", but i double that this can be declared as "the method". -- Vlsergey (talk) 10:10, 21 August 2015 (UTC)[reply]

en:Kenneth_Mapp#Early_life_and_education states that Q6390443 graduated from High School in 1973. According to en:Twelfth_grade#United_States, this would be at age 18. 1973-18=1955 (1950s with decade precision set at Q6390443#P569). --- Jura 10:30, 21 August 2015 (UTC)[reply]

@Jura1: thanks, that makes sense. -- Vlsergey (talk) 10:37, 21 August 2015 (UTC)[reply]

This seems to be a very obscure term; few data consumers will be able to figure out what it means. Jc3s5h (talk) 14:28, 21 August 2015 (UTC)[reply]

Feel free to edit label and/or description. --- Jura 05:07, 3 October 2015 (UTC)[reply]

I made another one age for a given year mentioned in source (Q21042816). --- Jura 05:07, 3 October 2015 (UTC)[reply]

TODO : Elements that should have a date of death (P570)[edit]

Here is a list of people born between 0 and 1895. These people normally should have a date of death (P570), even if the valus is set to unknown value Help. Louperivois (talk) 20:22, 21 September 2015 (UTC)[reply]

I added this to Property talk:P570, but excluded those with date of disappearance (P746) and floruit (P1317) as well. --- Jura 09:18, 13 October 2015 (UTC)[reply]

People born before 1920 are generally worth checking. Wikidata:Database reports/birthday today/to check frequently shows them as lacking P570.
--- Jura 16:17, 8 January 2016 (UTC)[reply]

Circa[edit]

How we can specify that it's a blurred date? --Davidpar (talk) 14:38, 12 December 2015 (UTC)[reply]

@Davidpar: You can use sourcing circumstances (P1480) as qualifier. Example: Galen (Q8778).--Micru (talk) 07:06, 9 March 2016 (UTC)[reply]

Thanks! --Davidpar (talk) 09:14, 9 March 2016 (UTC)[reply]

"Wrong calendar" constraint not working?[edit]

The "Wrong calendar" constraint described in the heading of this page only seems to be finding cases where the year of a birth of a living person was not found, so somebody entered "0" for the year. I would think there are tens of thousands of birth dates that occurred before 1582 but are marked as Gregorian calendar dates. Is something wrong? Jc3s5h (talk) 18:29, 26 February 2016 (UTC)[reply]

fixed.
--- Jura 18:54, 26 February 2016 (UTC)[reply]

I just ran a test and confirmed that if one uses the user interface to enter a date of 1 BCE, it is falsely entered into the database as "−0001-00-00T00:00:00Z". Since a major tool to fix violations of this constraint is telling lies for years before AD 1, I suggest that the constraint be temporarily changed to only examine dates in or after AD 1. Jc3s5h (talk) 22:20, 8 March 2016 (UTC)[reply]

@Mbch331:, thanks for this edit. I'm not familiar with the expressions for filters, but on the surface, "+0000-00-00T00:00:00Z" would seem to be not the best choice. The user interface can't handle year 0, and because pre- year 1 behavior of most aspects of WikiData have been ill-defined, nobody is going to believe any year earlier than 1. Someday a massive examination of each and every date (with a precision of year or better) will have to be done, and the errors we find are going to dwarf any issue of Julian vs. Gregorian calendar. Also, anyone who intends to fix a problem with a year 0 date won't be able to (except to delete it if it's used as an erroneous indication that only the person's month and day of birth is available, but not the year of birth).

So I would suggest the minimum value to work on be ""+0001-00-00T00:00:00Z" Jc3s5h (talk) 23:52, 8 March 2016 (UTC)[reply]

Changed it to January 1st, 1AD. Mbch331 (talk) 06:34, 9 March 2016 (UTC)[reply]

Jc3s5h, I wonder when they will sort out the calendar problems
--- Jura 07:07, 9 March 2016 (UTC)[reply]

@Jura1: Is this tracked in phabricator? --Micru (talk) 07:44, 9 March 2016 (UTC)[reply]

Maybe, but yesterday I came across a tracking bug that listed between 10 or 20 issues related to calendars .. so 1 more or less
--- Jura 07:46, 9 March 2016 (UTC)[reply]

phab:T87764. It's mentioned in phab:T99674. The behavior is said to be consistent with ISO.
--- Jura 09:27, 9 March 2016 (UTC)[reply]

I've been following a bunch of bug reports. Progress is slow. One aspect is that a database used internally was using an older version that had 1 BC = -1 baked in. Another issue was wanting to be able to sort all dates, but not having a method to convert Julian to Gregorian for sorting purposes. Indeed, I don't know where to find a tested algorithm for Julian/Gregorian conversion over the enormous span of years covered by WikiData; many give up the ghost around -4000. Jc3s5h (talk) 10:40, 9 March 2016 (UTC)[reply]

Possibly, if everything had worked out as planned .. it would have been perfect. Maybe we could come up with a suggestion of small steps to move forward.
--- Jura 23:28, 9 March 2016 (UTC)[reply]

Confusing comment reverted (in SPARQL for query.wikidata.org)[edit]

This comment was added by Jura1 at 10:27, 11 August 2016 UT. It reads

#Beware: dates displayed on WQS are always converted to Gregorian (2 BC = -1)

I don't know if it reflects a misunderstanding on Jura1's part, or if it just needs better wording, but it strongly implies that when one is using the Gregorian calendar, one must always convert a negative year to number & word notation by dropping the negative sign, adding 1, and concatinate " BCE" (or " BC") to the string. While this is the only conversion method that Richards, in the "Calendars" chapter of the Explanatory Supplement to the Astronomical 3rd ed. (p. 591) considered worth mentioning, he does not limit it to the Gregorian calendar; it is equally applicable to the Julian calendar. Most of the other sources I've read follow this approach. Two exceptions use a different negative year notation for Gregorian (2 BC = -1) and Julian (2 BC = -2):

Calendrical Calculaitons (w:Nachum Dershowitz and w:Edward Reingold
Fourmilab Calendar Converter by John Walker

The comment weakly implies that a different negative year notation is used, depending on whether one is using the Gregorian or Julian calendar. Any one who follows this implication, and is also familiar with some of the Wikidata code or documentation, is likely to think of the aberrant notation used in XSD 1.0 where only the Gregorian calendar is supported, and 2 BC = -2. This unfortunate gaff was corrected in XSD 1.1, but Wikidata and some of the tools it uses, like BlazeGraph, already had the XSD 1.0 notation baked in.

Really, for either calendar, it is better to think of it as two different, independent, conversions, which may be performed in either order. For example, if you need to convert "January 2, AD 1", Julian, to Gregorian, you would do the conversion using your favorite tool and discover it is "December 31, 1 BC" Gregorian. Then you would change the format to whatever is required. For example, if you were using XSD 1.1, you would write it "0000-12-31". Jc3s5h (talk) 13:03, 11 August 2016 (UTC)[reply]

Which URL do you think people use to view this comment ?
--- Jura 13:34, 11 August 2016 (UTC)[reply]

In the meantime, you seem to have changed your opinion on http://query.wikidata.org . Can we restore it?
--- Jura 07:13, 14 August 2016 (UTC)[reply]

I don't understand the question. We shouldn't have a comment visible on this page (even if is part of a SPARQL query) that implies the convention for interpreting negative year numbers depends on whether the calendar is Julian or Gregorian. In the outside world, this is hardly ever the case (except for Dershowitz/Reingold and Walker). Even within RDF, it isn't a matter of having one convention for Gregorian and one for Julian; rather, it is a matter of having a convention for Gregorian and just passing the string through unexamined for everything else. Jc3s5h (talk) 12:20, 14 August 2016 (UTC)[reply]

"instance of" removal[edit]

I reverted this edit which claims that this property is an instance of a property that encodes a Vcard value. Vcard dates are always Gregorian. Wikidata dates can be either Gregorian or Julian. Thus this claim is not correct. Jc3s5h (talk) 18:59, 19 September 2016 (UTC)[reply]

The edit is correct; it does not assert that every use of the property encodes a vCard property. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:22, 20 September 2016 (UTC)[reply]

Century problems[edit]

I came across Renée Friedman (Q2144921) (Renée Friedman) where the birth date property is set to '20. century' with a precision of century. But the output at the list en:List of female Egyptologists gives her birth as in the 2000s, which is the 21st century (and wrong). It should be outputting 1900s, or ideally actually "20th century". Where should I go to get this fixed? Carcharoth (talk) 10:42, 26 December 2016 (UTC)[reply]

Single value constraint[edit]

Can anyone explain why this property doesn't have the 'single value' constraint (and hence a list of violations in Wikidata:Database reports/Constraint violations/P569), while date of death (P570) does have the 'single value' constraint and a list at Wikidata:Database reports/Constraint violations/P570 ##Single value? It seems that on Wikidata, it's OK to be born as many times as you like, but you only die once. --RexxS (talk) 16:31, 30 May 2017 (UTC)[reply]

It was removed with strange comment. I think it need to be restored. — Ivan A. Krestinin (talk) 16:45, 30 May 2017 (UTC)[reply]
@Sjoerddebruin: would you comment? Infovarius (talk) 14:44, 31 May 2017 (UTC)[reply]

I can think of two reasons to have multiple values. First, various sources may give different values. Second, some people might think it's a good idea to give both the Gregorian calendar date and the Julian calendar date for people born in an era when various countries were switching from one to the other. Jc3s5h (talk) 16:52, 30 May 2017 (UTC)[reply]

Really different sources is very rare case. Much more often case is data import errors, invalid links to databases, iwiki conflicts and etc. Specifying two dates in different calendar is looked as specifying density (P2054) twice using kilogram per cubic metre (Q844211) and gram per cubic centimetre (Q13147228). — Ivan A. Krestinin (talk) 17:32, 30 May 2017 (UTC)[reply]

It's fairly important that we keep multiple sourced values: Q17386627#P569. Otherwise everybody needs to re-do the search again.
--- Jura 17:52, 30 May 2017 (UTC)[reply]

It is rare case, and can be handled using "exceptions" parameter. — Ivan A. Krestinin (talk) 17:56, 30 May 2017 (UTC)[reply]

There is just a risk that some bot-like edit removes it .. Another one: Q706363#P569.
--- Jura 18:00, 30 May 2017 (UTC)[reply]

Bots can start cleanup task without "Single value" constraint. But "Single value" with specified exceptions is signal for botmaster. He can review exceptions before the task start and correct bot`s algorithm. As for Q706363#P569, I think Cassius M. Clay: Freedom's Champion (Q24342288) is source for the first (correct) date. — Ivan A. Krestinin (talk) 18:28, 30 May 2017 (UTC)[reply]

What is an "exceptions" parameter? Jc3s5h (talk) 19:19, 30 May 2017 (UTC)[reply]

Try {{Constraint:Single value|exceptions={{Q|17386627}}, {{Q|706363}} }}. Exception values will not be listed in the report. — Ivan A. Krestinin (talk) 19:24, 30 May 2017 (UTC)[reply]

I suppose that it's not a very rare case. Exceptions will be listed by thousands... Infovarius (talk) 14:44, 31 May 2017 (UTC)[reply]

@Jc3s5h: I can also think of lots of legitimate reasons for having multiple values for date of birth, just as I can think of lots of legitimate reasons for having multiple values for date of death. Even though logically we would normally expect at most one of each (Jon Snow excepted of course). It's just that I can easily read a list of entities that have multiple dates of death, yet no such facility exists for entities that have multiple dates of birth. Having such a list would be useful when writing Lua code to handle these sort of exceptions from what might be normally expected. So, why do we have this inconsistency between dates of birth and death? --RexxS (talk) 19:52, 30 May 2017 (UTC)[reply]

I don't see why your usecase couldn't be served by using a sparql query. Constraint reports are mainly for people doing maintenance at Wikidata.
--- Jura 04:51, 31 May 2017 (UTC)[reply]

Have you ever tried it? A sparql query never finishes for this sort of job. What gives the folks doing maintenance work at Wikidata the right to stop other users from using the facilities that should be available to all? Is my work elsewhere somehow worth less than Wikidata maintenance work? It's about time folks got this this sort of elitist thinking out of their heads and knuckled down to doing some cooperative work. --RexxS (talk) 16:50, 3 July 2017 (UTC)[reply]

I agree that date of death (P570) should be consistent with this property. So I propose to remove Single value constraint from P570 too. --Infovarius (talk) 14:44, 31 May 2017 (UTC)[reply]

Lets use sampling to investigate current situation. For example this piece of report:

Tadeusz Borowski (Q100005): 1951-07-01 from enwiki, 1951-07-03 unsourced
Paul Müller (Q100355): 2010-05-29 from 404 page, 2010-05-30 from VIAF
Wolfgang von Chamier-Glisczinski (Q100363): 1943-08-22 from enwiki, unsourced, 1943-08-12 unsourced
Richard Euringer (Q100364): 1953-08-29 from enwiki, unsourced, 1953-08-28 from VIAF
Stephan Fridolin (Q100450): 1498 from VIAF, 1498-08-18 from BNF
Wilfried Hasselmann (Q100568): 2003 from VIAF, 2003-01-09 unsourced
Nathanael Chytraeus (Q100718): 1598 from VIAF, 1598-02-25 from BNF
Hilde Mangold (Q100742): 1924-09-04 from enwiki, 1924-12-07 from VIAF
Hubert von Meyerinck (Q100989): 1971-05-13 from VIAF, 1971-05-20 from VIAF
Conrad Hommel (Q101129): 1971 from VIAF, 1971-11-11 from itwiki
Adolf Rosenberg (Q101465): 1906 from VIAF, 1906-02-26 from frwiki
Heinrich Pröhle (Q101493): 1895-05-28 from enwiki, 1895 from Brockhaus and Efron Encyclopedic Dictionary. Aux. volume II, 1906 (Q23892481)
Johann Bernhard Vermehren (Q101506): 1803 from VIAF, 1803-11-29 unsourced
Albert Lieven (Q101884): 1971-12-22 from IMDb (can not be used as source), 1971-12-16 from VIAF
Helene von Dönniges (Q101930): 1911-10-01 from BNF, 1911-10-03 from VIAF (but I do not see this date in VIAF)

All these items have two values without specified reason. The most values have no real references. Its are looked like heap of errors that is walking from one database to another. All these items are need to be analyzed and improved. Real sources are need to be added. Unsourced values must be removed. This sampling analysis does not find any items like Lucy F. Simms (Q17386627) with known reason for double dates. So items like Lucy F. Simms (Q17386627) are rare case. — Ivan A. Krestinin (talk) 21:19, 31 May 2017 (UTC)[reply]

Interesting sample. With the exception of Q100355#P570, it seems like they are all either unreferenced or using tertiary resources. Personally, I consider neither particularly useful. Rather than removing any date, it would be good if they could be made into things like Q17386627#P569 or Q706363#P569.
--- Jura 04:35, 2 June 2017 (UTC)[reply]

Q706363#P569 ist not a good example. The second date sourced by the book is worth much more than a simple reference to wikipedia. I think the best would be (at least as a first step, the numbers will be high anyway) to add a complex constraint based on the single value constraint, but with the additional requirement that a date is either unsourced or only sourced by wikipedia. Steak (talk) 08:16, 2 June 2017 (UTC)[reply]

I think you might have misread the sample. The 2nd, deprecated date isn't referenced to Wikipedia.
--- Jura 10:32, 2 June 2017 (UTC)[reply]

I know, but the first one is. Steak (talk) 10:44, 2 June 2017 (UTC)[reply]

What would be the action based on such a constraint?
--- Jura 04:06, 3 June 2017 (UTC)[reply]

Examples corrected for time zone[edit]

Since the date of birth incorporates the time zone, and the only time zone that can be used is UT, I have corrected the examples to name people born in the UK when winter, rather than summer, time was in effect. Jc3s5h (talk) 09:02, 13 July 2017 (UTC)[reply]

Date and... hour[edit]

Hello. Can we add the hour and minute when somebody was born? Is this resolution managed correctly by infobox templates? Emijrp (talk) 20:50, 13 July 2017 (UTC)[reply]

It's worse than you think. Not only can we not add the hour and minute of birth, we are issuing false statements if we give the exact day of birth (rather than just the month) unless the place where the person was born observes w:Universal Time (UT) (for example, the UK in winter). For a list of links related to this issue see User:Jc3s5h/Date links.

There is a rare exception to making false statements. If you are able to determine the hour and minute, and convert those to UT, that would be accurate. But if you had to change the day of the month from the day of the month in local time, you would be out of step with most of the similar Wikidata entries, and the way most of our sources state dates of birth. Jc3s5h (talk) 21:16, 13 July 2017 (UTC)[reply]

The date is undefined (due to hour/timezone reasons) in ~1/24 of all cases, which is not that rare... --Infovarius (talk) 18:48, 15 July 2017 (UTC)[reply]

@Infovarius: I don't understand your statement. Could you explain, and give an example of a item with birth date that is defined, and another that is undefined? Jc3s5h (talk) 22:32, 15 July 2017 (UTC)[reply]

Added qualifier[edit]

I added the allowed qualifier refine date (P4241) by analogy with "date of death" in the example in the property description. - PKM (talk)

Wrong uses as birthday[edit]

I suggest that we add this query to complex constraint.

SELECT DISTINCT ?item ?birth WHERE {
    ?item p:P569/psv:P569 [
      wikibase:timeValue ?birth; wikibase:timePrecision ?precision
    ].
    FILTER(?birth > "+0000-00-00T00:00:00Z"^^xsd:dateTime).
    FILTER(?birth < "+0032-00-00T00:00:00Z"^^xsd:dateTime).
    FILTER(?precision = 10).
    FILTER (?item not in (wd:Q4115189,wd:Q13406268,wd:Q15397819)).
  }
  LIMIT 1000

Try it!

In the most of listed items, P569 will be used wrongly as birthday(P3150). --本日晴天 (talk) 09:27, 3 January 2018 (UTC)[reply]

Nice query. Maybe they could be converted directly.
--- Jura 11:51, 3 January 2018 (UTC)[reply]
- Added to complex constraint.--本日晴天 (talk) 11:14, 31 March 2018 (UTC)[reply]

I created new one. Dates with year 0 seem to be sometimes used to specify "unknown year" (see also: Talk:Q26961029#year 0).

SELECT DISTINCT ?item ?birth WHERE {
    ?item p:P569/psv:P569 [
      wikibase:timeValue ?birth; wikibase:timePrecision ?precision
    ].
    # If year of ?birth is ±0, DATATYPE(?birth) is xsd:string, not xsd:dateTime.
    FILTER REGEX(?birth, "0000\\-\\d\\d-\\d\\dT").
    FILTER(?precision >= 9).
    FILTER (?item not in (wd:Q4115189,wd:Q13406268,wd:Q15397819)).
  }
  LIMIT 1000

Try it!

--本日晴天 (talk) 15:56, 20 January 2018 (UTC)[reply]

Added this one to complex constraint.--本日晴天 (talk) 11:30, 8 July 2019 (UTC)[reply]

Unborn #5[edit]

There is some discussion on Talk:Q38668629 about P569, P31, etc. to use for these. I don't think we are likely to have (m)any other items this will apply to.
--- Jura 21:28, 14 March 2018 (UTC)[reply]

Age fabrication (age fabrication (Q4691861))[edit]

How should we reflect age fabrication? I have an issue with Levko Lukianenko (Q1996140): he was born in 1928, his birth records were lost during World War II and he was sent to the army with soldiers born in 1927, he has 1927 as an official (but forged) birth year since. Have I done it correctly? I still see an alert, thus should we add that age fabrication (Q4691861) is a Wikibase reason for deprecated rank (Q27949697)? I think he is not the first case of age fabrication but I could not find any example. Thanks — NickK (talk) 17:35, 7 July 2018 (UTC)[reply]

I'd say, go for it (with adding Wikibase reason for deprecated rank (Q27949697)). --Azertus (talk) 14:34, 9 September 2018 (UTC)[reply]

Replacing property that may violate privacy (Q44601380)-status with property likely to be challenged (Q44597997)[edit]

I don't think using the property that may violate privacy (Q44601380)-status for date of birth (P569) is workable. The year of birth is a property that's important for authority control and as such it's valuable to add date of birth (P569) whenever we have a quality source. All the libraries that do authority control store data about when people are born and having access to that data is important for us to interact with their datasets and decide whether to items point to the same person. As such I propose to remove property that may violate privacy (Q44601380) from this property. WikiProject Properties has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. ChristianKl ❪✉❫ 14:20, 22 December 2018 (UTC)[reply]

When we have a quality source it's not a problem to add a "property that may violate privacy" - as long as it's publicly sourced its fine. But age is definitely considered a private matter for many living people, and date of birth - just because it is useful as an identifier/disambiguator, is also a piece of privacy-related data just for that reason. If it's available from a reliable quality source then add it, sure, with that source as reference. Otherwise - at least for living people - we should be more cautious with it. I do not support changing this status. ArthurPSmith (talk) 14:00, 24 December 2018 (UTC)[reply]
Oppose. I support ArthurPSmith's cause. Both the properties are unique and different though they may appear similar in some cases such as this. Harsh Rathod Poke me! 08:34, 27 December 2018 (UTC)[reply]
birthday (P3150) is here if the year shouldn't be included. I think we already had some unneeded drama with someone's DOB which seemed to have copied from LoC. LoC, if I recall correctly, had afterwards removed the date, as it probably wasn't needed for their purposes either. --- Jura 11:47, 28 December 2018 (UTC)[reply]
@ArthurPSmith: No, property that may violate privacy (Q44601380) does not say that a reliable source is enough it requires the higher standard that the information "can be considered widespread public knowledge or openly supplied by the individual themselves". property likely to be challenged (Q44597997) is the status that simple requires a reliable source. I would recommend you to read the policy. ChristianKl ❪✉❫ 12:19, 15 May 2019 (UTC)[reply]

Gregorian Calendar[edit]

Can someone block the possibility of adding Gregorian Calendar to dates prior to October 5th, 1582? That would mean we don't have to change all those dates when we encounter them. And perhaps it would be a good idea to run a script to delete Gregorian Calendar everywhere it is now in the database with dates before that calendar was introduced. --HRvO (talk) 17:44, 21 January 2019 (UTC)[reply]

Please discuss at Property talk:P570. Jc3s5h (talk) 18:24, 21 January 2019 (UTC)[reply]

Date of birth in a century[edit]

I see a lot of additions on my Watchlist where a date of birth is created with a certain century. I have some problems with this actually. It concerns persons from the Middle Ages in Europe of whom no date of birth or age at death are known. Adding a date of birth with a certain century imho is nothing more than (educated) guessing which is not suited for a scientific database. We should accept that from historical persons certain dates are simply unknown because they were never recorded. When the date of birth of a person is unknown we should either use Date of birth with the parameter unknown, or we shouldn't create Date of birth at all. We should not suffer from a modern day form of horror vacui... I hope you can agree on this --HRvO (talk) 22:10, 22 January 2019 (UTC)[reply]

Do you have a sample for a case where the century is wrong? --- Jura 14:08, 26 January 2019 (UTC)[reply]

Nobody can say whether it is wrong or right as the date of birth of those persons is unknown. The educated guesses seemed to make sense in the cases I saw. But that's not the point. The point is that we should not include educated guesses, but only known facts. --HRvO (talk) 15:43, 26 January 2019 (UTC)[reply]

There are various ways of determinating dates of birth. If you don't have a sample that is incorrect, it's hard to say if it's appropriate for the items you seem to have in mind. Anyways, in general, I think Wikidata:Property proposal/century fl. could help. --- Jura 06:10, 27 January 2019 (UTC)[reply]

Imho there is only one way to determine a date of birth, which is quoting the official record. Making educated guesses isn't. So I stand by my earlier view that it should either be Date of birth with the parameter unknown value, or no creation of Date of birth at all. --HRvO (talk) 21:04, 2 February 2019 (UTC)[reply]

I don't know if Wikidata has a policy on the matter, but there is a Wikipedia policy which forbids using official birth records for living persons because they are primary, not secondary, sources. Official registration of births wasn't generally practiced until the beginning of about 1800. This leaves a great many historical people and living people whose birth dates would have to be omitted, according to HRvO. I reject this view. Jc3s5h (talk) 20:47, 3 February 2019 (UTC)[reply]

Date of birth requires a reference. If a reference gives a century for date of birth, then it is not our place to second guess the source of the information. User HRvO claims these are "educated guesses", but that statement appears to be his opinion, i.e., he doesn't know that for a fact, and it constitutes original research. --Robert.Allen (talk) 22:44, 29 June 2020 (UTC)[reply]

Twins[edit]

I see that we have a number of cases where this property is used on twins, e.g. Krista and Tatiana Hogan (Q6437699), Anastasia and Tatiana Dogaru (Q4751897), Kendra and Maliyah Herrin (Q16240593), Q38279079. While it is true that twins often share the same date (and place) of birth, is this something to encourage or remove? Bovlb (talk) 23:06, 22 March 2019 (UTC)[reply]

@Bovlb: Noticed it as well, I don't care. Only in cases where we haven't dedicated items for each of the twins it might be better to have it on the twins item than not at all. This question but applies to a lot of properties on groups of persons, occupation (P106) for example is also popular and for group items in general, perhaps a question for WD:PC. --Marsupium (talk) 11:15, 1 April 2019 (UTC)[reply]

@Marsupium: I can see the case for occupation (P106) in the case of, say, a sibling duo (Q14073567) that work collaboratively as a group of authors (Q1690980). Regarding the other properties, I sympathize with the argument that it is better to have the information represented somewhere than not at all, but that is balanced by the argument that it is better not to represent things incorrectly. The former favours human editors who can hypothesize sense extensions (e.g. the date of birth of a band might be an erroneous representation of inception (P571), or it might happen to be the date of birth of all members), whereas the latter favours automated use of the data. Cheers, Bovlb (talk) 15:48, 1 April 2019 (UTC)[reply]

@Bovlb: Agree, removing this data, thus complying with the constraint violation and getting the cases away from WD:Database reports/Constraint violations/P569#Type Q5, Q95074, Q21070568, Q16521, Q146, Q144, Q726, Q7378, Q36341, Q69581, Q19537, Q756, Q80174, Q729, Q3542731, Q30017383 (currently 17 cases of twins (Q14756018) without subclasses) sounds like a good idea. --Marsupium (talk) 17:39, 1 April 2019 (UTC)[reply]

We use members have occupation (P3989) instead of occupation (P106) for groups of people. --Infovarius (talk) 21:16, 16 August 2020 (UTC)[reply]

Inferring birth year from age and date of death[edit]

What to do when we know just the date of death and the person's age in that moment? Is there a property Age? Os should I add both possible birth years, as I did in Rafael Fragoso (Q94994352)? The Portuguese article is using this information but it displays just one of the years. Ideally it should display "1957-8". —capmo (talk) 01:34, 24 June 2020 (UTC)[reply]

Help:Dates#Inexact_dates might help you.

BTW There is the qualifier age of subject at event (P3629), but that requires an event. --- Jura 12:37, 14 November 2020 (UTC)[reply]

Thanks. I'll resort to circa (Q5727902) for lack of a better solution. —capmo (talk) 00:15, 15 November 2020 (UTC)[reply]

How to eliminate a wrong birth date once and forever?[edit]

I've come to several cases where more than one birth date has been listed, and I can identify the right one, but the wrong one(s) are also attributed to a source (e.g. VIAF, or even Library of Congress - their data quality is not very good when they deal with someone not from the U.S., and VIAF is just a little pile of horrors). E.g.: Q376410, Q12369832. I Now, I could just remove the wrong value, but then someone gathering such data via a bot could reinsert it any time. The best solution might be leaving some kind of parameter stating "this piece of data from this source is wrong, please don't reinsert". (Of course, this concerns other properties as well.) Is there any way to do it? --Ehitaja (talk) 20:06, 13 November 2020 (UTC)[reply]

Ehitaja, you can use ranks (preferred, deprecated) to signal which date is correct and which is not. See what I did in August Kitzberg (Q376410) for an example. Regards, —capmo (talk) 03:11, 14 November 2020 (UTC)[reply]

Thanks! But what's the difference between, say, lifting one statement to the preferred rank and leaving the other at normal, and leaving one to normal and lowering the other to deprecated (or even preferred/deprecated)? --Ehitaja (talk) 11:34, 14 November 2020 (UTC)[reply]

Help:Ranking tries to explain it. --- Jura 12:33, 14 November 2020 (UTC)[reply]

Remove conflict with coordinate location (P625) ?[edit]

I am using this property for instances of centennial trees. see https://w.wiki/3CRj

Given that the property is acceptable for use on for all organisms, do you think it's ok to remove the property constraint (P2302), conflicts-with constraint (Q21502838) with coordinate location (P625) ? Thanks Nikola Tulechki (talk) 13:07, 17 April 2021 (UTC)[reply]

January 1 as date[edit]

Please note Help:Dates#January_1_as_date. --- Jura 16:09, 1 February 2022 (UTC)[reply]

year unknown[edit]

Some fictional character's birth year is unknown while the day in year is known. Therefore I added day in year for periodic occurrence (P837) as a possible qualifier. Here is how I used it. – Shisma (talk) 08:12, 13 August 2022 (UTC)[reply]

@Shisma: There is the birthday (P3150) property, which was specifically made for this purpose. Dexxor (talk) 14:25, 13 August 2022 (UTC)[reply]

Characters in fictional worlds[edit]

I've noticed a pattern for characters that take place in entirely fictional worlds, and it's that they cannot have a birthday added because the dates in their world do not map neatly onto the dates in our world, and as far as I can tell, there's to property that allows us to work around this. Is there any plans to do something about this? It'd be really nice to be able to add birth dates and death dates for Cosmere characters. LiftedStarfish (talk) 06:56, 1 August 2023 (UTC)[reply]

Use date of birth (P569)<unknown value> with qualifier time index (P4895)birth date (see Eorl (Q2475930) as an example). You can create an own item for the time unit (see Third Age year (Q117906730) as a reference). Valentina.Anitnelav (talk) 12:34, 1 August 2023 (UTC)[reply]

How to change[edit]

Hello. How do I change the terms for "BC" and "AD"? The ones who originally created the template wrote unpopular terms for these. I want to change them but I can't figure it out! (Tagging some active people, sorry: @Valentina.Anitnelav, @Dexxor) Ea-Nasir (talk) 19:27, 28 August 2023 (UTC)[reply]

Found this, but even though i removed it here, it still persists on appearing. Here, for example. It is "ди лъ. я." instead of "Хьисэм ыпэкIэ" Ea-Nasir (talk) 20:07, 28 August 2023 (UTC)[reply]

Now it seems to work. Thanks to whoever fixed it. (At least there is гъэ Хьисэм, now and not ди лъ. я. I hope this is better) - Valentina.Anitnelav (talk)

Property talk:P569

Documentation

Discussion[edit]

More than one date[edit]

Animals[edit]

Date formatting[edit]

How to call the data[edit]

Century problems[edit]

Why the bad data violations?[edit]

Date of baptism?[edit]

Date of birth for fictional humans[edit]

Формат дат[edit]

Dates available at Wikipedia[edit]

Date output[edit]

Problem with century in Greek[edit]

Qualifier determination method (P459) use with date of birth (P569)[edit]

TODO : Elements that should have a date of death (P570)[edit]

Circa[edit]

"Wrong calendar" constraint not working?[edit]

Confusing comment reverted (in SPARQL for query.wikidata.org)[edit]

"instance of" removal[edit]

Century problems[edit]

Single value constraint[edit]

Examples corrected for time zone[edit]

Date and... hour[edit]

Added qualifier[edit]

Wrong uses as birthday[edit]

Unborn #5[edit]

Age fabrication (age fabrication (Q4691861))[edit]

Replacing property that may violate privacy (Q44601380)-status with property likely to be challenged (Q44597997)[edit]

Gregorian Calendar[edit]

Date of birth in a century[edit]

Twins[edit]

Inferring birth year from age and date of death[edit]

How to eliminate a wrong birth date once and forever?[edit]

Remove conflict with coordinate location (P625) ?[edit]

January 1 as date[edit]

year unknown[edit]

Characters in fictional worlds[edit]

How to change[edit]

Navigation menu

Search