View source for Testwiki:Property proposal/property for implied values

=== {{TranslateThis | anchor = en
| en = value hierarchy property
| fr = transitive sur
<!-- |xx = property names in some other languages -->
}} ===
{{Property proposal
|status			= 6609
|description		= {{TranslateThis
 | en = property which specifies less precise items than the indicated value for which statements using the subject property would still be true
 | fr = propriété transitive déterminant si une entité est plus précise qu'une autre comme valeurs pour cette propriété
<!-- | xx = descriptions in other languages -->
 }}
|subject item           = <!-- item corresponding to the concept represented by the property, if applicable; example: item child (Q7569) for property child (P40) -->
|infobox parameter	= <!-- Wikipedia infobox parameters, if any; ex: "population" in [[:en:template:infobox settlement]] -->
|datatype		= property
|domain			= {{Q|18616576}}
|allowed values  	= {{Q|18647515}}
|example 1		= {{P|31}} → {{P|279}}
|example 2		= {{P|159}} → {{P|131}}
|example 3		= {{P|106}} → {{P|279}}
|example 4		= {{P|689}} → {{P|927}}
|planned use            = add to a bunch of properties and use in tools, see below
|see also               = <!-- other, related properties -->
|filter			= <!-- sample: 7 digit number can be validated with edit filter [[Special:AbuseFilter/17]] -->
|robot and gadget jobs	= <!-- Should or are bots or gadgets doing any task with this? (Checking other properties for consistency, collecting data, etc.) -->
|subpage		= property for implied values
|topic			= generic
}}

'''Note''': we have considered various labels for this property: "property for implied values", "transitive over", "refinement hierarchy" and currently "value hierarchy property". All these variations are used in the discussion below. − [[User:Pintoch|Pintoch]] ([[User talk:Pintoch|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 21:40, 15 January 2019 (UTC)

====Motivation====

I would be interested in expressing that a given property (such as {{P|279}}) is used to determine how values of another property ({{P|31}}) can be refined. This is a pattern that we use at various places in Wikidata:
* {{statement||P31|Q4830453}} is more precise than {{statement||P31|Q43229}}, because there is a chain of {{P|279}} statements between {{Q|4830453}} and {{Q|43229}}. This would be expressed by {{statement|P31|property for implied values|P279}}.
* {{statement||P159|Q239}} is more precise than {{statement||P159|Q240}}, because there is a chain of {{P|131}} between the two values. This would be expressed by {{statement|P159|property for implied values|P131}}.

Potentially this property could be multi-valued if there are multiple refinement hierarchies in place (but I can't think of an example right now). I am not very happy with the label so I hope others have better ideas.

The idea behind introducing such a property would be to make it easier for data import tools (such as [[Wikidata:Tools/OpenRefine|OpenRefine]]) to respect these hierarchies natively (for instance, when adding {{statement||P159|Q239}} to an item, any unsourced {{statement||P159|Q240}} statement could be safely deleted, I think).

This could also potentially improve the constraint system: for instance, if we have an {{Q|21503247}} which requires {{statement||P159|Q90}}, then the constraint system could also accept {{statement||P159|Q259463}} (because it is more precise). As far as I am aware this behaviour is only available for {{P|31}}/{{P|279}} via {{Q|21503250}} currently. {{Ping|Lucas Werkmeister (WMDE)}} I have no idea if it is feasible (and in which case you could prefer another syntax for this information)?  − [[User:Pintoch|Pintoch]] ([[User talk:Pintoch|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 15:09, 8 January 2019 (UTC)

{{notify project|Ontology}}

:{{Ping|Jean-Frédéric|Olivier LPB}} you have requested this feature at [[Help_talk:Property_constraints_portal/Item]] − [[User:Pintoch|Pintoch]] ([[User talk:Pintoch|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 15:14, 8 January 2019 (UTC)

===={{int:Talk}}====
* {{s}} would a label something like "property over which this is transitive" make sense? But yes, this seems like a very useful abstraction to provide a structured mechanism for. [[User:ArthurPSmith|ArthurPSmith]] ([[User talk:ArthurPSmith|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 19:36, 8 January 2019 (UTC)
**Thanks, yes that could be clearer, especially if we can get rid of the "this". − [[User:Pintoch|Pintoch]] ([[User talk:Pintoch|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 06:59, 9 January 2019 (UTC)
***Given {{U'|Yair rand}}'s phrasing below ({{tq|{{P|106}} is only transitive over {{P|279}}}}), I have renamed to {{tq|transitive over}}. − [[User:Pintoch|Pintoch]] ([[User talk:Pintoch|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 07:28, 10 January 2019 (UTC)
* This can get complicated. {{P|106}} is only transitive over {{P|279}} until outside the occupation class tree. --[[User:Yair rand|Yair rand]] ([[User talk:Yair rand|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 23:45, 8 January 2019 (UTC)
**Good point. But values outside the occupation class tree are already forbidden by a {{Q|21510865}}, so maybe we can say that the implication only holds if the broader value is acceptable with respect to other constraints? Or we could indicate the containing class with a qualifier? Anyway, for both applications mentioned (data import and constraint violations), this should not be an issue. − [[User:Pintoch|Pintoch]] ([[User talk:Pintoch|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 06:57, 9 January 2019 (UTC)
*{{S}} [[User:ديفيد عادل وهبة خليل 2|David]] ([[User talk:ديفيد عادل وهبة خليل 2|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 12:53, 9 January 2019 (UTC)
*{{comment}} New label ("transitive over") works for me! [[User:ArthurPSmith|ArthurPSmith]] ([[User talk:ArthurPSmith|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 16:28, 10 January 2019 (UTC)
**{{Re|ArthurPSmith}} given MisterSynergy's reaction below, I have the feeling that this label is too close to "transitive" and might cause confusion for others. Maybe something like "refinement hierarchy" would be better - it would also rule out values like {{P|3373}} which are symmetric properties. − [[User:Pintoch|Pintoch]] ([[User talk:Pintoch|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]])
*{{Wait}} How do other ontologies handle this? Where is prior art? Especially, when it comes to naming this relationship?
 [[User:ChristianKl|<font color="#0000EE">'''ChristianKl'''</font>]] ❪[[User talk:ChristianKl|✉]]❫ 18:23, 10 January 2019 (UTC)
:*{{Re|ChristianKl}} yes indeed surely this has been formalized in other places. I will investigate. − [[User:Pintoch|Pintoch]] ([[User talk:Pintoch|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 20:12, 10 January 2019 (UTC)
::*{{Re|ChristianKl}} I have asked around and it does not seem to have a particular name, it is just a particular case of an OWL construct: [https://www.w3.org/TR/owl2-primer/#Property_Chains property chains]. People in graph theory or other fields of math might have names for that particular relation, but I am not sure how to look for it (and it is likely to be as obscure as any other name we come up with, TBH). − [[User:Pintoch|Pintoch]] ([[User talk:Pintoch|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]])
{{Ping project|Properties}}
* (Thanks for the ping.)<br><s>{{tl|Oppose}}</s> (see below). For all given examples, the value properties {{P|P279}}, {{P|P131}}, and {{P|P927}} have already an explicit relation {{P|P31}}: {{Q|Q18647515}}. This transitivity is valid for any kind of use, not just the ones which should use the property proposed here. As only {{Q|Q18647515}} values should be allowed according to the proposal, we do not gain anything with this proposed property which is not already there. —[[User:MisterSynergy|MisterSynergy]] ([[User talk:MisterSynergy|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 19:22, 10 January 2019 (UTC)
**{{Re|MisterSynergy}} sorry, it looks like I did not pick the best examples. Please consider this case:
::{{statement|Q207191|P39|Q11699}}
::{{statement|Q11699|P361|Q48525}}
::{{statement|P361|P31|Q18647515}}
::However, it would be wrong to say that {{statement|Q207191|P39|Q48525}}.
::So, {{P|39}} is transitive over {{P|279}} but not over {{P|361}} (and both {{P|279}} and {{P|361}} are transitive).
::So this notion of "X transitive over Y" is distinct from "Y transitive". Do you agree? Maybe the new label is causing confusion? − [[User:Pintoch|Pintoch]] ([[User talk:Pintoch|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 20:12, 10 January 2019 (UTC)
:::If you prefer symbolic statements over prose:
:::* Q is '''transitive''' when <math>\forall x y z, x Q y \land y Q z \Rightarrow x Q z</math>
:::* P is '''transitive over''' Q when <math>\forall x y z, x P y \land y Q z \Rightarrow x P z</math>
:::− [[User:Pintoch|Pintoch]] ([[User talk:Pintoch|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 20:58, 10 January 2019 (UTC)

::::Another counterexample found by sparqling around: {{P|3373}} is transitive. {{P|40}} is transitive over {{P|3373}} (if X has child Y and Y has sibling Z, then X has child Z), but {{P|25}} is not transitive over {{P|3373}} (if X has mother Y and Y has sibling Z, then surely Z is is not X's mother!). − [[User:Pintoch|Pintoch]] ([[User talk:Pintoch|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 23:47, 10 January 2019 (UTC)
:::::{{re|Pintoch}} I don't think so. Halfsiblings frequently are siblings.  [[User:ChristianKl|<font color="#0000EE">'''ChristianKl'''</font>]] ❪[[User talk:ChristianKl|✉]]❫ 07:16, 11 January 2019 (UTC)
::::::{{re|ChristianKl}} yes that is true − this example is not something we would want to have anyway for the two applications mentioned above (because {{P|3373}} is symmetric, so it cannot be seen as a refinement hierarchy like the other examples). I just hope it helps {{U'|MisterSynergy}} grasp the difference with transitivity a bit better (in particular, the fact that {{P|25}} is not transitive over {{P|3373}} is still a counterexample of his claim, I think). − [[User:Pintoch|Pintoch]] ([[User talk:Pintoch|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 07:52, 11 January 2019 (UTC)
:::Yeah, I understand. However, this is the same problem that User:Yair_rand mentioned above and which you acknowledged, just in a much more obvious sense. Transitivity of a property ''Y'' (e.g. {{P|P361}}) used in value items of property ''X'' (e.g. {{P|P39}}) holds only as long as you stay within the ''range'' of ''X'' ({{Q|Q21510865}} we say at Wikidata). It works for a couple of steps for occupations and then breaks down, but barely for ''parthood relations'' which are typically very messi at Wikidata. It works practically always for the proposed {{P|P159}} → {{P|P131}}, as the range of the latter is completely contained within the range of the former; the problem does not really matter for the proposed {{P|P31}} → {{P|P279}}, as {{P|P31}} does not have a defined range.
:::There is another, independent problem with parthood relations in particular, in contrast to other transitive properties ({{Q|Q1194916}} is the research field that studies parthood relations). For parthood relations transitivity is typically assumed within mereology, but there is research in the community about whether this is generally valid or not ([https://scholar.google.de/scholar?q=parthood+transitivity see here]). Consider for instance these (fictional) claims:
:::* {{Claim|Pintoch's big toe|P361|Pintoch}}
:::* {{Claim|Pintoch|P361|Wikidata admin corps}}
:::Although both claims would be acceptable for Wikidata and {{P|P361}} is transitive, you clearly would not infer that {{Claim|Pintoch's big toe|P361|Wikidata admin corps}}. The problem is that parthood relations are only transitive under certain circumstances, for example in a local meronomy (such as “Pintoch's body parts” or “Wikimedia project entites”). However, parthood relations are not generally transitive.
:::I still do not think that this proposed property should be created. The range problem raised by Yair_rand would have to be addressed with extra efforts based on existing {{Q|Q21510865}} claims on properties anyway (so the proposed property does not add new value), and the parthood problem would rather be solved by removing the transitivity from {{P|P361}}/{{P|P527}}. (I still have to have a look at the {{P|P3373}} problem, though.) —[[User:MisterSynergy|MisterSynergy]] ([[User talk:MisterSynergy|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 10:30, 11 January 2019 (UTC)
::::{{Re|MisterSynergy}} you rightly point out that transitivity itself is often messy. I would argue that this is not just true for {{P|361}}: very often, long chains of {{P|279}} also give nonsensical results when we follow them high up into very abstract concepts. That's inevitable: we are building a knowledge graph, not a math textbook.
::::Let's step back and look at the motivation of the proposal. What I mean with this proposal is that many properties tend to have one designated property for their refinement hierarchy. It seems to me that this pattern is pretty pervasive, but we tend to only acknowledge this for the {{P|31}}/{{P|279}} pair. Why?
::::It would be [[Help_talk:Property_constraints_portal/Item|massively useful]] if the constraint system could handle other such hierarchies. Typically when working with {{Q|5}}, the fact that we discourage subclasses of {{Q|5}} makes the type system useless there. Have you ever wanted to enforce things like "every item with an {{P|496}} should have {{P|106}} {{Q|1650915}}, or any subclass of it"? Now, I could propose to add a parameter to the constraints definition so that we could provide {{P|279}} there, but I think this would be misguided as this information is really determined by the property used for the required statement. So I think this should be stored in a generic way, outside the constraint system. Now I would very much welcome any other suggestion about how to represent this. − [[User:Pintoch|Pintoch]] ([[User talk:Pintoch|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 10:54, 11 January 2019 (UTC)
:::::Also (sorry for the long reply!), it seems to me that there might still be a conceptual misunderstanding here: in the abstract, the fact that a property Q is transitive really does not mean that "x P y Q z" implies "x P z" for any property P. This is wrong both in mathematics and in ontology design. So there is nothing to "fix" about {{P|361}} being transitive in this regard. It turns out that most of the transitive properties we have in Wikidata are containment relations, where this tends to hold often,, but that does not have to be the case. For instance, imagine we had a property called "hates". The fact that "MisterSynergy hates {{Q|23900272}}" really does not imply that "MisterSynergy hates {{Q|11004}}", even if the chain of {{P|279}} is totally correct. − [[User:Pintoch|Pintoch]] ([[User talk:Pintoch|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 11:41, 11 January 2019 (UTC)
:: Now {{Neutral}}, as I do not want to stand in the way too much. I changed my mind after a second read of this proposal and its comments. The transitivity does no longer seem to be the critical aspect of this property, and I really hope that this term does not appear in the potential property label. It is also worth to mention that it may be useful for refinements, i.e. looking *down* along a hierarchy for potentially better/more specific values, which pretty much avoids the discussed problems that arise when going *up* a hierarchy towards more general values. —[[User:MisterSynergy|MisterSynergy]] ([[User talk:MisterSynergy|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 11:53, 13 January 2019 (UTC)
:::Yes, it could be interesting to have something for implications which are going down a hierarchy. I cannot think of an example though (beyond my "hates" example above, maybe). − [[User:Pintoch|Pintoch]] ([[User talk:Pintoch|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 15:21, 14 January 2019 (UTC)
: I'm not sure if the above can of worms is what ChristianKl intended to open, but the question of how other ontologies deal with this again seems relevant. I remember some peculiarities with transitivity in SKOS - there are both the relations "broader" and "broaderTransitive", and "broaderTransitive" is declared as a ''superproperty'' of "broader" (and note this does NOT make "broader" transitive, despite the fact that "superproperty" like "superclass" is itself transitive). There's a discussion of some of this (in a more general case) [http://ontogenesis.knowledgeblog.org/1376 here]. It all kind of hurts the brain a bit... [[User:ArthurPSmith|ArthurPSmith]] ([[User talk:ArthurPSmith|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 14:06, 11 January 2019 (UTC)
:{{re|ArthurPSmith}} I don't think that properties like this should be trivally created. We should generally follow existing standards and only invent our own if we have good reasons to invent the wheel anew.  [[User:ChristianKl|<font color="#0000EE">'''ChristianKl'''</font>]] ❪[[User talk:ChristianKl|✉]]❫ 10:46, 13 January 2019 (UTC)
::{{re|ChristianKl}} I totally agree. That being said, it seems to me that there is no established RDF predicate for this in the usual namespaces. The reason for that is that this information is best expressed in OWL, not in RDF directly. Wikidata has not engaged much with OWL so far - the project has followed a different route by storing ontological information in the same data model as the data itself. For instance we have {{P|1696}}, and we use statements such that {{statement||P31|Q18647515}}, which intrinsically don't do anything (Wikibase does not give them any special meaning, the query service does not infer any triples from them, and so on). Storing property constraints as statements on the property is another example. So this is why I proposed this property: it seems to be in line with the current customs of storing ontological information as statements on properties. That being said, it would obviously be much better if we had generic support for constructs like [https://www.w3.org/TR/owl2-primer/#Property_Chains property chains], which would be much more expressive. But that is a much larger project, and we might want to think twice before construing these concepts in the Wikibase data model (maybe this is something we want to store elsewhere?) − [[User:Pintoch|Pintoch]] ([[User talk:Pintoch|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 11:03, 13 January 2019 (UTC)

* {{comment}} Ok, it sounds like we need to settle on a non-confusing label (and if we can find a label somebody else has used, all the better). I was looking at a sample of the item-valued properties we have; for many of them this whole discussion simply does not apply (there's no "refinement hierarchy" or transitivity that would be associated with person-valued properties like {{P|6}} or {{P|57}}, and I can't think of one that would apply for unitary entity values like {{P|17}} either.) For the ones associated with a physical location, for example {{P|19}}, then we're clearly interested in the location-based hierarchy that Wikidata manages via {{P|131}}. For some others, {{P|279}} seems to apply (for example for language-valued properties like {{P|37}}). For {{P|108}} I am not sure if we have a consistent refinement hierarchy - {{P|749}} perhaps, but also {{P|361}}, {{P|127}}? Fundamentally I think what we're looking for is the way in which the domain of the property value (class, place, language, organization, etc.) is hierarchically modeled in Wikidata. So would a label like "domain hierarchy property" make sense? [[User:ArthurPSmith|ArthurPSmith]] ([[User talk:ArthurPSmith|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 14:20, 14 January 2019 (UTC)
::Yes, I also expect that {{P|279}} and {{P|131}} would be the most common values for this property. Concerning the label, does "domain" generally refer to the target value? Intuitively, for me it would refer to the subject item. (Maybe by a vague mathematical analogy with the domain of a function, although statements aren't functions) So it would be more intuitive for me to have something else like "range", "value" or "target". − [[User:Pintoch|Pintoch]] ([[User talk:Pintoch|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 15:21, 14 January 2019 (UTC)
::: Oh! Yes, I was thinking "domain" in the generic sense of type of item. Maybe "value hierarchy property"? [[User:ArthurPSmith|ArthurPSmith]] ([[User talk:ArthurPSmith|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 17:10, 14 January 2019 (UTC)
::::I think that would be quite clear indeed! − [[User:Pintoch|Pintoch]] ([[User talk:Pintoch|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 17:21, 14 January 2019 (UTC)
::::: I attempted to update the label and description in English in the proposal - ok now? [[User:ArthurPSmith|ArthurPSmith]] ([[User talk:ArthurPSmith|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 20:33, 15 January 2019 (UTC)
::::::Yes, thanks! I am adding a note to explain the variations of labels in the discussion. − [[User:Pintoch|Pintoch]] ([[User talk:Pintoch|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 21:40, 15 January 2019 (UTC)
* {{comment}} as far as constraint checks are concerned: any kind of transitivity hurts performance (“type” and “value type” are among the most expensive constraint checks by far) and caching (we can’t invalidate all cached results if an item buried somewhere in the chain is edited, that’s why you’ll see “this result may be outdated” on some type / value type check results). --[[User:Lucas Werkmeister (WMDE)|Lucas Werkmeister (WMDE)]] ([[User talk:Lucas Werkmeister (WMDE)|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 17:27, 14 January 2019 (UTC)
::Thanks! Yes I can imagine this would be expensive to run. So it makes all the more sense to store this information outside the constraint system. I would still be interested in this to ease data imports. − [[User:Pintoch|Pintoch]] ([[User talk:Pintoch|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 20:07, 14 January 2019 (UTC)

===Wrapping up===
It seems to me that the remaining issues are:
* How to indicate the scope of the "transitivity" by restricting it to the descendants of a particular item. In my opinion this information is already stored in the property constraints so it is not worth duplicating. {{U'|Jklamo}}, what do you think? Otherwise we could indicate the bounding class for transitivity with a qualifier, such as {{P|2308}} or {{P|1012}} (such as {{statement|P106|value hierarchy property|P279|P2308|Q12737077}}. Or with the target property as qualifier: {{statement|P106|value hierarchy property|P279|P279|Q12737077}}.
* Finding previous work on the issue. {{U'|ChristianKl}}, are you satisfied with my take on this above?
− [[User:Pintoch|Pintoch]] ([[User talk:Pintoch|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 14:10, 3 February 2019 (UTC)
* {{Support}} [[User:ChristianKl|<font color="#0000EE">'''ChristianKl'''</font>]] ❪[[User talk:ChristianKl|✉]]❫ 14:47, 4 March 2019 (UTC)
**Thanks! I'm marking this as ready then, unless anyone has other concerns. − [[User:Pintoch|Pintoch]] ([[User talk:Pintoch|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 17:12, 4 March 2019 (UTC)
* If we're going to have a qualifier for constraining to a particular class, I think {{P|2308}} would be a better choice than {{P|279}}, as {{P|279}} is a widely-used main-value-only property, while {{P|2308}} is already a qualifier used on properties pages. --[[User:Yair rand|Yair rand]] ([[User talk:Yair rand|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 04:55, 14 March 2019 (UTC)
**Makes sense! − [[User:Pintoch|Pintoch]] ([[User talk:Pintoch|{{int:Talkpagelinktext}}]]) 15:39, 22 March 2019 (UTC)

* {{ping|Pintoch|Yair rand|ديفيد عادل وهبة خليل 2|ChristianKl|MisterSynergy|Lucas Werkmeister (WMDE)}} {{done}} [[User:ArthurPSmith|ArthurPSmith]] ([[User talk:ArthurPSmith|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 21:00, 22 March 2019 (UTC)