Wikidata

Wikidata:Property proposal/place of birth string

< Wikidata:Property proposal

place of birth/death string edit

place of birth string edit

Originally proposed at Wikidata:Property proposal/Person

   Withdrawn
Descriptionwhen the source states the name of the place of birth but possibly multiple different places share the same name, this property can be used instead of P19
Data typeMonolingual text
Domainperson
ExampleJosse van der Heyden (Q21543053) → Calmhouden
See alsoplace of birth (P19), author name string (P2093)

place of death string edit

Originally proposed at Wikidata:Property proposal/Person

   Withdrawn
Descriptionwhen the source states the name of the place of death but possibly multiple different places share the same name, this property can be used instead of P20
Data typeMonolingual text
Domainperson
ExampleHerbert Coleridge (Q5733811) → 10 Chester Place, Regent's Park
See alsoplace of death (P20), author name string (P2093)
Motivation

Just like author name string (P2093) can be useful when importing data about work (Q386724)s where an ambiguous string is the only information we have the author, in many case we only have the string of the name of a place of birth when importing the place of birth from sources that only list the city name. The same goes for the place of death.

Having the property will make it easier to import authority control data from sources that just store the names of the places of birth and death as strings. ChristianKl (talk) 19:38, 14 June 2017 (UTC)[reply]

Discussion
  Weak support do you have some examples where the place name is actually ambiguous and this would really be helpful? Otherwise I'm not sure allowing more unstructured data is a good thing here. ArthurPSmith (talk) 16:59, 15 June 2017 (UTC)[reply]
I remember entering biographical data where the place of birth was labeled as "Washington". That could be Washington state. It could also be Washington DC. There were also other cases where I don't remember the specifics.
In cases, where there's zero ambiguity, a bot might add place of birth (P19) and place of death (P20). When a GLAM partner uploads a larger set of authority control data and only has strings for the place of birth/death it would be helpful for the GLAM partner to not have to worry about matching the strings to Wikidata items the same way that the GLAM partner doesn't have to worry about choicing the right author when uploading authority control data about scientific papers. A bot that's specifically designed to do the task of turning the string into Wikidata items well, would likely do a better job than whatever ad-hoc solution a GLAM partner would use. ChristianKl (talk) 10:35, 16 June 2017 (UTC)[reply]
  •   Support I could think of a bunch of use cases. Think of all the homonymous cities in the U.S., or of obscure historical villages which don't exist anymore or can't be identified properly. Jonathan Groß (talk) 09:29, 16 June 2017 (UTC) Edit: I took the liberty of changing the datatype from "string" to "monolingual text", and replaced the Albert Einstein example with an actual use case. Jonathan Groß (talk) 09:36, 16 June 2017 (UTC)[reply]
Thank you. ChristianKl (talk) 10:35, 16 June 2017 (UTC)[reply]
  • It's not a solution that has a form where it's likely to be used by everybody the same way, the way a specific property standardizes the information to be always entered in the same way. Standardization is important to allow bots to work well. ChristianKl (talk) 13:28, 2 July 2017 (UTC)[reply]
  Support I just came across this yesterday when I was annotating a letter written in 1918. It listed several locations in France and a place where a body was buried and Wikipedia gave me a disambiguation page for that name, eventually I was able to firm it up with research that they were in Ardennes from the context. I also come across locations that were probably farm names or hamlets that never became census designated places in old New York Times obituaries. They are not in the GNIS database. --Richard Arthur Norton (1958- ) (talk) 16:38, 24 June 2017 (UTC)[reply]
  Weak support as a temporary structure where text dates are then converted to proper dates. Text dates especially in languages I do not speak are not useful to infoboxes and I would Template:Strongly oppose to structure where we have dozens of text dates written in different languages. But I can see it as a temporary storage space which would be regularly converted to regular dates. --Jarekt (talk) 13:01, 2 July 2017 (UTC)[reply]
@Jarekt: By "dates" I trust you mean "place names"? Jonathan Groß (talk) 13:03, 2 July 2017 (UTC)[reply]
No I Goofed up and misread the proposal topic. Thanks for noticing. I will strike it for now and write new reply. --Jarekt (talk) 13:15, 2 July 2017 (UTC)[reply]
  Oppose use special value "unknown" --Pasleim (talk) 08:29, 9 July 2017 (UTC)[reply]
@Yair rand: This property would be a similar temporary measure. ChristianKl (talk) 07:54, 2 August 2017 (UTC)[reply]
  Oppose Please avoid unstructured data like strings. "author (text)" is a very bad precedent. Matěj Suchánek (talk) 17:38, 8 August 2017 (UTC)[reply]
  Oppose I like Jura's idea of adding quotation (P1683) to "unknown" value. --Jarekt (talk) 16:11, 9 August 2017 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/place_of_birth_string&oldid=534561388"