Wikidata:Property proposal/negates property

negates property

Originally proposed at Wikidata:Property proposal/Generic

Done: negates property (P11317) (Talk and documentation)

Description	this property negates the specified property
Data type	Property
Example 1	does not have part (P3113) → has part(s) (P527)
Example 2	does not have characteristic (P6477) → has characteristic (P1552)
Example 3	does not have effect (P7167) → has effect (P1542)
Example 4	does not have cause (P9353) → has cause (P828)
Example 5	has part(s) (P527) → does not have part (P3113)
Example 6	has characteristic (P1552) → does not have characteristic (P6477)
Example 7	has effect (P1542) → does not have effect (P7167)
Example 8	has cause (P828) → does not have cause (P9353)
Single-value constraint	yes

Motivation

If we want non-human data consumers to be able to understand the meaning of our negating properties, we have to express which properties they negate in Wikidata.

We currently link these properties with complementary property (P8882) which does not imply negation e.g. start time (P580)complementary property (P8882)end time (P582).

The semantics of the proposed property are:

AP₁B ∧ P₁negates propertyP₂ then the statement AP₂B can be inferred to be false and must not be made (if both statements have none or the same restrictive qualifiers).

The following would apply to the new "negates property" property:

negates propertysubproperty of (P1647)complementary property (P8882)
negates propertyinstance of (P31)symmetric property (Q18647518)
negates propertyproperty constraint (P2302)symmetric constraint (Q21510862)
negates propertyproperty constraint (P2302)single-value constraint (Q19474404)

--Push-f (talk) 08:28, 25 November 2022 (UTC)[reply]

Discussion

WikiProject Properties has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.. --Push-f (talk) 08:30, 25 November 2022 (UTC)[reply]
Why not use "negates property" in both directions?

does not have part (P3113)negates propertyhas part(s) (P527) looks to me just as valid as has part(s) (P527)negates propertydoes not have part (P3113) ChristianKl ❪✉❫ 12:24, 25 November 2022 (UTC)[reply]

I did think about that. I ended up proposing two properties because data consumers probably want to differentiate "truthy" properties from properties that express the absence of something. E.g.

has characteristic (P1552)Wikidata item of this property (P1629)quality (Q1207505) & has effect (P1542)negates propertydoes not have effect (P7167)
does not have characteristic (P6477)Wikidata item of this property (P1629)quality (Q1207505) & does not have characteristic (P6477)negates propertyhas characteristic (P1552)

How are non-human data consumers supposed to figure out which of these properties expresses the presence of a quality (Q1207505) and which of these properties expresses the absence of a quality (Q1207505) if both properties are linked together with "negates property"?

--Push-f (talk) 14:17, 25 November 2022 (UTC)[reply]

I just created Wikidata property to express the absence of something (Q115449020) to express this via instance of (P31). This makes the inverse "negated by property" property I initially proposed redundant and I have dropped it from this proposal and updated the motivation accordingly, making "negates property" a symmetric property, like you suggested :) --Push-f (talk) 07:36, 26 November 2022 (UTC)[reply]

Sounds, good to me. I

Support the proposal in the new form where it goes in both directions. ChristianKl ❪✉❫ 12:08, 26 November 2022 (UTC)[reply]

OH NOOOOOO. Don't do that. We don't need any more instance of (P31)s in properties. Figure out how to do it with a statement. Lectrician1 (talk) 17:58, 26 November 2022 (UTC)[reply]

@Lectrician1: This is getting slightly off-topic but could you please enlighten me about what you think is wrong with instance of (P31) statements on properties? You are aware that claims using instance of (P31) are also statements, right?

I think I actually prefer making these statements with instance of (P31) instead of another property because it reduces the number of properties data consumers need to understand to reason about Wikidata.

We currently express that properties are transitive via instance of (P31)transitive Wikidata property (Q18647515), I don't see any reason to change that or why we shouldn't also use instance of (P31) to state that a property expresses the absence of something. --Push-f (talk) 19:11, 26 November 2022 (UTC)[reply]

We have two ways to express transitivity. We have that P31 and we also have value hierarchy property (P6609). The second is a bit harder to understand but also more precise because properties that are transitive usually aren't transitive over everything.

Here it's worth thinking about whether we have an existing qualifier that we could put on "negates property". ChristianKl ❪✉❫ 21:35, 26 November 2022 (UTC)[reply]

I disagree with your suggestion of expressing this as a qualifier on "negates property" because the fact whether a property expresses the absence or presence of something is entirely independent of its relationship to other properties. --Push-f (talk) 10:27, 27 November 2022 (UTC)[reply]

The problem with perpetuation of using P31 to categorize properties is that over time as we add more and more P31s, querying properties will actually become harder. Data consumers would need to look for and traverse classes instead of just querying for a property when they're looking for a property of with a specific attribute. Also, the number of P31 statements on properties nowadays is getting extremely long and out-of-hand. I'm a firm believer that entities should have at most one P31 statement that defines their most fundamental type. That type for properties would be Wikidata property (Q18616576). The rest of the categorizations should be described through properties. We don't give a bunch of P31s to most items for the same reasons. Lectrician1 (talk) 19:12, 27 November 2022 (UTC)[reply]

I am suggesting that instance of (P31)Wikidata property to express the absence of something (Q115449020) should be added directly on properties, so there is no need to traverse anything.

I assume what's bothering you are the 575 instances of type of Wikidata property (Q107649491). These are just used to categorize properties by topic, most of them afaik don't imply any important semantics, which is very much different from Wikidata property to express the absence of something (Q115449020) which does imply a very important semantic aspect. --Push-f (talk) 19:47, 27 November 2022 (UTC)[reply]

Still, it's another P31 we don't need. I actually was fine with the inverse property. Lectrician1 (talk) 14:53, 28 November 2022 (UTC)[reply]

Why not opposite of (P461)? Lectrician1 (talk) 15:06, 25 November 2022 (UTC)[reply]

That is an item data type and can't have properties as values. -wd-Ryan (Talk/Edits) 16:04, 25 November 2022 (UTC)[reply]

start time (Q24575110)opposite of (P461)end time (Q24575125) so it would only be logical that the same would apply to the same-named properties. --Push-f (talk) 16:07, 25 November 2022 (UTC)[reply]

Support Most interesting proposal I've seen in a while. Infrastruktur (talk) 23:43, 26 November 2022 (UTC)[reply]
Support — The Erinaceous One 🦔 07:02, 27 November 2022 (UTC)[reply]
Support Assuming I'm not missing an existing property that covers this ArthurPSmith (talk) 18:44, 28 November 2022 (UTC)[reply]
Support per Arthur. --99of9 (talk) 23:33, 29 November 2022 (UTC)[reply]
Support -wd-Ryan (Talk/Edits) 17:14, 15 December 2022 (UTC)[reply]
@Push-f, ChristianKl, Lectrician1, Wd-Ryan, Infrastruktur, The-erinaceous-one:@ArthurPSmith, 99of9: Done--GZWDer (talk) 17:20, 18 December 2022 (UTC)[reply]