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.
According to this template: person (Q215627), organism (Q7239)
According to statements in the property:
human (Q5), fictional character (Q95074), dog (Q144), horse (Q726), cat (Q146), Ailuropoda melanoleuca (Q33602), gorilla (Q36611), chimpanzee (Q80174), elephant (Q7378), Pan troglodytes (Q4126704), polar bear (Q33609), killer whale (Q26843), American alligator (Q193327), Bonobo (Q19537), Ursus arctos (Q36341), Asian elephant (Q133006), orangutan (Q41050), Kodiak bear (Q237260) and hippopotamus (Q34505)
When possible, data should only be stored as statements
Allowed values Past dates (note: this should be moved to the property statements)
Usage notes 태어난 연도가 없거나 기록이 없어 태어난 달과 일만 있는 경우 이 속성 대신 P3150(태어난 월·일)을 사용하세요.
Example Jude Law (Q160432)
Isaac Newton (Q935)
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), no label (Q32866007)
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), Category:Creator templates with Wikidata link: item missing birthdate (Q39599131)
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,798,083
[create] Create a translatable help page (preferably in English) for this property to be included here
Conflicts with “has part (P527): 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 P527, SPARQL
Conflicts with “instance of (P31): twins (Q14756018), sibling duo (Q14073567), Wikimedia disambiguation page (Q4167410): 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 P31, SPARQL
Conflicts with “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 P625, SPARQL
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 P31, SPARQL
Type “human (Q5), fictional character (Q95074), dog (Q144), horse (Q726), cat (Q146), Ailuropoda melanoleuca (Q33602), gorilla (Q36611), chimpanzee (Q80174), elephant (Q7378), Pan troglodytes (Q4126704), polar bear (Q33609), killer whale (Q26843), American alligator (Q193327), Bonobo (Q19537), Ursus arctos (Q36341), Asian elephant (Q133006), orangutan (Q41050), Kodiak bear (Q237260), hippopotamus (Q34505): element must contain property “instance of (P31)” with classes “human (Q5), fictional character (Q95074), dog (Q144), horse (Q726), cat (Q146), Ailuropoda melanoleuca (Q33602), gorilla (Q36611), chimpanzee (Q80174), elephant (Q7378), Pan troglodytes (Q4126704), polar bear (Q33609), killer whale (Q26843), American alligator (Q193327), Bonobo (Q19537), Ursus arctos (Q36341), Asian elephant (Q133006), orangutan (Q41050), Kodiak bear (Q237260), hippopotamus (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, SPARQL
Qualifiers “instance of (P31), determination method (P459), subject of the statement (P805), earliest date (P1319), latest date (P1326), sourcing circumstances (P1480), criterion used (P1013), reason for deprecation (P2241), statement disputed by (P1310): 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#Allowed qualifiers, SPARQL
Range from “77986” to “now”: values should be in the range from “77986” to “now”.
Exceptions are possible as rare values may exist. Known exceptions: James T. Kirk (Q16311), Spock (Q16341), Leela (Q121841), Benjamin Sisko (Q546404), Chakotay (Q766141), Doraemon (Q1186309), Honor Harrington (Q1333382), Maxim Kammerer (Q1509471), Amy Wong (Q1990492), SHODAN (Q2079562), Batman (Q2601118), no label (Q3489729), Gennady Komov (Q4135491), Lev Abalkin (Q4256149), Rudolf Sikorski (Q4399733)
List of this constraint violations: Database reports/Constraint violations/P569#Range
 Testing to see how much implausable dates there are.  For future dates, try the "future dates" of the property description template -->
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.)

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)

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)

  • 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)
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)
  • It is rare case, and can be handled using "exceptions" parameter. — Ivan A. Krestinin (talk) 17:56, 30 May 2017 (UTC)
  • There is just a risk that some bot-like edit removes it .. Another one: Q706363#P569.
    --- Jura 18:00, 30 May 2017 (UTC)
  • What is an "exceptions" parameter? Jc3s5h (talk) 19:19, 30 May 2017 (UTC)
  • 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)
  • I suppose that it's not a very rare case. Exceptions will be listed by thousands... Infovarius (talk) 14:44, 31 May 2017 (UTC)
@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)
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)
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)
  • 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)
  • Lets use sampling to investigate current situation. For example this piece of report:
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)
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)
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)
I think you might have misread the sample. The 2nd, deprecated date isn't referenced to Wikipedia.
--- Jura 10:32, 2 June 2017 (UTC)
I know, but the first one is. Steak (talk) 10:44, 2 June 2017 (UTC)
What would be the action based on such a constraint?
--- Jura 04:06, 3 June 2017 (UTC)

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)

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)

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