Property talk:P569

From Wikidata
Jump to: navigation, search


date of birth
date on which the subject was born
Description Date of birth of a living thing, see also: date of death (P570), use date of baptism in early childhood (P1636) for date of baptism, when date of birth is unknown
Represents date of birth (Q2389905)
Data type Point in time
Template parameter Basic property used by all biographical infoboxes.
Domain person (Q215627), organism (Q7239)
Allowed values Past dates (note: this should be moved to the property statements)
Usage notes 태어난 연도가 없거나 기록이 없어 태어난 달과 일만 있는 경우 이 속성 대신 P3150(태어난 월·일)을 사용하세요.
Example Bill Thompson (Q4911143)
Pyotr Ilyich Tchaikovsky (Q7315)
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:Property P569 missing at Wikidata, but information available in Wikipedia (Q19332015), Category:Articles with Template:Bio and date of birth not in Wikidata, but available on Wikipedia (Q28858522)
See also date of death (P570), date of baptism in early childhood (P1636), birthday (P3150)
Proposal discussion Property proposal/Archive/8#P569
Current uses 2,702,136
[create] Create a translatable help page (preferably in English) for this property to be included here

Conflicts with “has part (P527); instance of (P31): twins (Q14756018), sibling duo (Q14073567), Wikimedia disambiguation page (Q4167410); coordinate location (P625): this property must not be used with listed properties and values.
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P569#Conflicts with
Conflicts with “instance of (P31): Wikimedia permanent duplicated page (Q21286738): this property must not be used with listed properties and values.
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P569#Conflicts with
Type “human (Q5), fictional character (Q95074), dog (Q144), horse (Q726), cat (Q146), giant panda (Q33602), gorilla (Q36611), chimpanzee (Q80174), elephant (Q7378), Pan troglodytes (Q4126704), polar bear (Q33609), killer whale (Q26843), American alligator (Q193327), bonobo (Q19537), brown bear (Q36341), Asian elephant (Q133006), orangutan (Q41050), Kodiak bear (Q237260), hippopotamus (Q34505): element must contain property instance of (P31) with classes Q5, Q95074, Q144, Q726, Q146, Q33602, Q36611, Q80174, Q7378, Q4126704, Q33609, Q26843, Q193327, Q19537, Q36341, Q133006, Q41050, Q237260, Q34505 or their subclasses (defined using subclass of (P279))
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P569#Type Q5, Q95074, Q144, Q726, Q146, Q33602, Q36611, Q80174, Q7378, Q4126704, Q33609, Q26843, Q193327, Q19537, Q36341, Q133006, Q41050, Q237260, Q34505
Qualifiers “instance of (P31), determination method (P459), subject of the statement (P805), earliest date (P1319), latest date (P1326), sourcing circumstances (P1480): this property should be used only with listed qualifiers.
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P569#Qualifiers, SPARQL
Pictogram voting comment.svg Wrong calendar
People born before 1582 whose birth date is registered using Proleptic Gregorian calendar (Q1985727) instead of Proleptic Julian calendar (Q1985786).
Violations query: SELECT DISTINCT ?item WHERE { ?birthclaim ps:P569 ?birth . FILTER(?birth < "+1582-10-15T00:00:00Z"^^xsd:dateTime) . FILTER(?birth > "+0001-01-01T00:00:00Z"^^xsd:dateTime) . ?birthclaim psv:P569/wikibase:timeCalendarModel wd:Q1985727 . ?item p:P569 ?birthclaim . } LIMIT 1000
List of this constraint violations: Database reports/Complex constraint violations/P569
Pictogram voting comment.svg Probably death
People born before the year 1900, but no date of death (P570)
Violations query: SELECT DISTINCT ?item WHERE { ?item p:P569 ?birthclaim . MINUS { ?item p:P570 [] } ?birthclaim ps:P569 ?birth . FILTER(?birth < "+1900-00-15T00:00:00Z"^^xsd:dateTime) . } LIMIT 1000
List of this constraint violations: Database reports/Complex constraint violations/P569
Pictogram voting comment.svg Items with P569 = "no value" (P31=Q5)
People are all born at some point in time
Violations query: SELECT ?item ?itemLabel { ?item p:P569/a wdno:P569 ; wdt:P31 wd:Q5 SERVICE wikibase:label { bd:serviceParam wikibase:language "en" } } LIMIT 100
List of this constraint violations: Database reports/Complex constraint violations/P569
This property is being used by:

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

Manually update chart
WQS | PetScan | YASGUI | Find images

This property is being used by:

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

This property is being used by:

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

This property is being used by:

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

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)

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)
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)
If you want, change the values Face-smile.svg. There is no problem. Tpt (talk) 16:58, 30 May 2013 (UTC)


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

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)

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)

Symbol support vote.svg 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)
Wikidata talk:WikiProject Visual arts/Item structure Date should be best place. --Oursana (talk) 11:10, 2 December 2013 (UTC)
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)
I am with you. Danke und LG--Oursana (talk) 20:22, 2 December 2013 (UTC)

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)

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)
And is there any LuaModule done with this? -Theklan (talk) 10:38, 17 September 2013 (UTC)
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)
Which project are we talking about? -- Lavallen (talk) 13:24, 17 September 2013 (UTC)
eu:wp, for example. -Theklan (talk) 15:46, 17 September 2013 (UTC)
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)
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)
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)
Which is the Translatewiki section for Wikidata? Is it inside mediawiki? -Theklan (talk) 16:26, 7 October 2013 (UTC)
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)
Ok... so what could/should I make? -Theklan (talk) 21:58, 9 October 2013 (UTC)

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)

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)

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)

It should rather come from {{Constraint:Conflicts with}} currently with has part (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)
Q1515154 does have an incorrect date format. --- Jura 07:44, 20 September 2014 (UTC)
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)

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 no label (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)

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

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)

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)
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)
@Jc3s5h: But not allowing them also leads to constraint violations. --LydiaPintscher (talk) 11:40, 17 April 2015 (UTC)

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

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

Where to change the date format. here It must be so 1949 шаран 15 апрель. -- Дагиров Умар (talk) 22:47, 15 June 2015 (UTC)
@Дагиров Умар: here:Модуль:Dates . -- Vlsergey (talk) 07:41, 16 June 2015 (UTC)
Спасибо. -- Дагиров Умар (talk) 10:08, 16 June 2015 (UTC)

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)

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)

currently renders as "12. century" (12. century). Eventually this might be localized.
For now, I think one is expected to use
which currently renders as "XII sec." (XII sec.) --- Jura 16:46, 17 June 2015 (UTC)
Thank you, Jura. Even that, in turn, must be localized somewhere. Here? Translatewiki? StevenJ81 (talk) 17:29, 17 June 2015 (UTC)
Maybe: --- Jura 17:33, 17 June 2015 (UTC)

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)

{{#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 --- Jura 19:26, 4 July 2015 (UTC)

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)

  • @Jura1: what is "educational cursus"? can you give me a link to this method, please? -- Vlsergey (talk) 09:44, 21 August 2015 (UTC)
Click on whatlinkshere to find two samples. --- Jura 09:51, 21 August 2015 (UTC)
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)
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)
@Jura1: thanks, that makes sense. -- Vlsergey (talk) 10:37, 21 August 2015 (UTC)
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)
Feel free to edit label and/or description. --- Jura 05:07, 3 October 2015 (UTC)

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

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)

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)
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)


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

@Davidpar: You can use sourcing circumstances (P1480) as qualifier. Example: Galen (Q8778).--Micru (talk) 07:06, 9 March 2016 (UTC)
Thanks! --Davidpar (talk) 09:14, 9 March 2016 (UTC)

"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)

--- Jura 18:54, 26 February 2016 (UTC)
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)
@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)
Changed it to January 1st, 1AD. Mbch331 (talk) 06:34, 9 March 2016 (UTC)
Jc3s5h, I wonder when they will sort out the calendar problems
--- Jura 07:07, 9 March 2016 (UTC)
@Jura1: Is this tracked in phabricator? --Micru (talk) 07:44, 9 March 2016 (UTC)
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)
phab:T87764. It's mentioned in phab:T99674. The behavior is said to be consistent with ISO.
--- Jura 09:27, 9 March 2016 (UTC)
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)
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)

Confusing comment reverted (in SPARQL for[edit]

This comment was added by Jura1 (talkcontribslogs) 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):

  1. Calendrical Calculaitons (w:Nachum Dershowitz and w:Edward Reingold
  2. 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)

Which URL do you think people use to view this comment ?
--- Jura 13:34, 11 August 2016 (UTC)
In the meantime, you seem to have changed your opinion on . Can we restore it?
--- Jura 07:13, 14 August 2016 (UTC)
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)

"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)

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)

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)