Wikidata:Property proposal/place of birth string
Jump to navigation
Jump to search
place of birth/death string
[edit]place of birth string
[edit]Originally proposed at Wikidata:Property proposal/Person
Withdrawn
Description | when 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 type | Monolingual text |
Domain | person |
Example | Josse van der Heyden (Q21543053) → Calmhouden |
See also | place of birth (P19), author name string (P2093) |
place of death string
[edit]Originally proposed at Wikidata:Property proposal/Person
Withdrawn
Description | when 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 type | Monolingual text |
Domain | person |
Example | Herbert Coleridge (Q5733811) → 10 Chester Place, Regent's Park |
See also | place 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)
- 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)
- 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)
- 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)
- Thank you. ChristianKl (talk) 10:35, 16 June 2017 (UTC)
- Comment How about using the actual properties with the special value "unknown" and qualify it with quote?
--- Jura 21:32, 18 June 2017 (UTC)
- That would make it harder for a bot to parse the data. If Siegmund Friedrich Dresig (Q114384) would have a sibling that was born in Vorberg (Q30334380) a bot could give add Siegmund Friedrich Dresig (Q114384) place of birth (P19) Vorberg (Q30334380) but if the sibling would be born in Vorberg (Q30334403) the bot could add Siegmund Friedrich Dresig (Q114384) place of birth (P19) Vorberg (Q30334403). ChristianKl (talk) 22:56, 18 June 2017 (UTC)
- No, it's still a string to compare. We would simply know explicitly that we don't know the exact place of birth.
--- Jura 13:07, 2 July 2017 (UTC)
- 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)
- You are right: QIDs should be used. Not some string property.
--- Jura 15:19, 2 July 2017 (UTC)
- You are right: QIDs should be used. Not some string property.
- No, it's still a string to compare. We would simply know explicitly that we don't know the exact place of birth.
- Oppose per above.
--- Jura 17:56, 22 June 2017 (UTC)- @Jura1, ChristianKl: Siegmund Friedrich Dresig (Q114384) might be a poor example, but that doesn't mean that this property isn't a good idea. Jonathan Groß (talk) 17:21, 23 June 2017 (UTC)
- It's better than the Albert Einstein one that was replaced. With or without, I think we get the general idea. One can obviously support building a parallel structure with string properties (or not). Personally, I think the alternative I suggested with unknown and quote should be equivalent.
--- Jura 09:29, 24 June 2017 (UTC)
- It's better than the Albert Einstein one that was replaced. With or without, I think we get the general idea. One can obviously support building a parallel structure with string properties (or not). Personally, I think the alternative I suggested with unknown and quote should be equivalent.
- @Jura1, ChristianKl: Siegmund Friedrich Dresig (Q114384) might be a poor example, but that doesn't mean that this property isn't a good idea. Jonathan Groß (talk) 17:21, 23 June 2017 (UTC)
- 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)
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)- @Jarekt: By "dates" I trust you mean "place names"? Jonathan Groß (talk) 13:03, 2 July 2017 (UTC)
- 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)
- @Jarekt: By "dates" I trust you mean "place names"? Jonathan Groß (talk) 13:03, 2 July 2017 (UTC)
- Oppose use special value "unknown" --Pasleim (talk) 08:29, 9 July 2017 (UTC)
- Oppose. This is not structured data. Note that author name string (P2093) was created to be a temporary measure until the strings can be converted to author (P50). --Yair rand (talk) 02:56, 25 July 2017 (UTC)
- @Yair rand: This property would be a similar temporary measure. ChristianKl (talk) 07:54, 2 August 2017 (UTC)
- 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)
- Oppose I like Jura's idea of adding quotation (P1683) to "unknown" value. --Jarekt (talk) 16:11, 9 August 2017 (UTC)