Wikidata:Property proposal/founder of
Jump to navigation
Jump to search
founder of[edit]
Return to Wikidata:Property proposal/Generic
Under discussion
| Description | Organization, religion, or place that was founded or co-founded by subject. Inverse of P112. |
|---|---|
| Data type | Item |
| Example 1 | Steve Jobs (Q19837)→Apple (Q312) |
| Example 2 | Joseph Smith (Q47102)→The Church of Jesus Christ of Latter-day Saints (Q42504) |
| Example 3 | London Company (Q1061207)→Jamestown (Q323813) |
Motivation[edit]
This would be the inverse of the existing property "founded by" (P112). P112 can not be transitively inverted, meaning, existing links for "B founded by A" cannot be inverted to say "A founded by B". Therefore, it will be helpful for knowledge applications leveraging this ontology to provide a proper inverse, such that "B founded by A" can be rewritten and queried as "A founder of B".
Discussion[edit]
Oppose precisely because this is merely an inverse. @Hellwigt-eq: the item to which you refer is not an "inverse property", but an "inverse label item" (or rather, an item that primarily exists to contain labels); that is, for tools like MediaWiki:Gadget-relateditems.js, the item provides to the tool possible values in different languages for the name of the "property" in the "derived 'founder' statements"—obtained from finding links from other items to a given item using "founder"—that the tool displays. Mahir256 (talk) 20:44, 26 April 2024 (UTC)
- Since P112 is not invertible, can you propose an alternative way of expressing that Entity A is founder of Entity B? If not, does this not add value to the semantic graph? Hellwigt-eq (talk) 20:54, 26 April 2024 (UTC)
- Oppose You express it by placing a statement on the item of Entity B. ChristianKl ❪✉❫ 23:57, 28 April 2024 (UTC)
- Valid, but not ideal for our downstream application, or even for the average Wikidata user I would think, as incoming links are more expensive to query for than outgoing, and the incoming links aren't discoverable in Wikidata's UI. Is there harm to be avoided by limiting creation of inverses? Hellwigt-eq (talk) 15:23, 29 April 2024 (UTC)
- When it comes to database design storing data only once instead of multiple times, is general 101 advice. Wikidata is more constraint by it's ability to store data and manage the data then by the cost of queries.
- In general, if you have a downstream application and want to create a property proposal for it's sake, it would make sense to write it in the motivation field. Not being straightforward about your motivations is not very helpful. ChristianKl ❪✉❫ 21:28, 29 April 2024 (UTC)
- Valid, but not ideal for our downstream application, or even for the average Wikidata user I would think, as incoming links are more expensive to query for than outgoing, and the incoming links aren't discoverable in Wikidata's UI. Is there harm to be avoided by limiting creation of inverses? Hellwigt-eq (talk) 15:23, 29 April 2024 (UTC)
- Good catch on the distinction between inverse property and inverse label item, I will edit the motivation accordingly. But inverse property does exist (P1696), what is that for if not for this? Hellwigt-eq (talk) 20:57, 26 April 2024 (UTC)
- To demonstration consistency with existing Wikidata practice, here are just a few examples of the numerous inverse property pairs that exist within Wikidata: (P1376:P36), (P1308:P39), (P8810:P40), (P137, P121), (P4969:P144), (P156:P155), etc. Since being "merely an inverse" was not sufficient reason to keep these other inverse properties from being created, could you further elaborate on why it is sufficient grounds to block creation of this particular property? Hellwigt-eq (talk) 21:13, 26 April 2024 (UTC)
- Basically, there are reasons for having some properties. Often it's when the relationship is notable in one direction but not notable in the other direction. parent (P8810) exists because we have mother (P25) and father (P22). ChristianKl ❪✉❫ 23:56, 28 April 2024 (UTC)
- I don't know that I see how this example relates to the examples Hellwigt-eq provided above. For capital of/capital, the relationship is notable in both directions. Can you suggest an alternative formulation of the capital of/capital relationship pair that doesn't rely on this duplication? If so, can that example be applied through analogy to the case of "founder of"? Hildrethd-eq (talk) 20:27, 29 April 2024 (UTC)
- At the current time we likely wouldn't create the "capital of/capital" relationship in both ways. Deleting one of them would at this time break templates in multiple wiki's and the ability to query inverses from Wikipedia isn't yet ready. In one or two years when that ability might be ready, there will be good reason to delete on of them. ChristianKl ❪✉❫ 21:36, 29 April 2024 (UTC)
- I don't know that I see how this example relates to the examples Hellwigt-eq provided above. For capital of/capital, the relationship is notable in both directions. Can you suggest an alternative formulation of the capital of/capital relationship pair that doesn't rely on this duplication? If so, can that example be applied through analogy to the case of "founder of"? Hildrethd-eq (talk) 20:27, 29 April 2024 (UTC)
- Basically, there are reasons for having some properties. Often it's when the relationship is notable in one direction but not notable in the other direction. parent (P8810) exists because we have mother (P25) and father (P22). ChristianKl ❪✉❫ 23:56, 28 April 2024 (UTC)
- Since P112 is not invertible, can you propose an alternative way of expressing that Entity A is founder of Entity B? If not, does this not add value to the semantic graph? Hellwigt-eq (talk) 20:54, 26 April 2024 (UTC)
Support sounds good to me; furthermore, I used to think that this property missed on some items. YotaMoteuchi (talk) 22:19, 26 April 2024 (UTC)- Support Great property suggestion; we have needed this for some time. Lindsaya1234 (talk) 15:47, 29 April 2024 (UTC)
- Previously discussions: 2013, 2016, 2016, 2017, 2023.--GZWDer (talk) 10:59, 27 April 2024 (UTC)
