Wikidata:Property proposal/necessary property for class

necessary property for class

Originally proposed at Wikidata:Property proposal/Generic

   Withdrawn

Description	all instances of this class necessarily have the property, even if the property might not be known to Wikidata
Data type	Property
Domain	item
Example 1	human (Q5) → date of birth (P569)
Example 2	architectural structure (Q811979) → coordinate location (P625)
Example 3	geographic location (Q2221906) → coordinate location (P625)
See also	properties for this type (P1963): when this subject is used as object of “instance of”, the following properties normally apply

This should be a subproperty of properties for this type (P1963).

Motivation

I'm thinking about how to make our conception of instance of (P31) and subclass of (P279) more clear and with being more clear also one uniform. It seems to me a key feature of the instance of relationship is that it implies that instances have certain properties. Every human was born at a specific point in time. Every architectural structure has a coordinate location.

I derivate from the wording of "property for this type" here because I believe it's easier to understand Wikidata if we use class in relation to subclass and don't add the additional word type into our vocabulary to describe the entities in our data model. I would then also seek to rename into "property for this class". ChristianKl ❪✉❫ 16:30, 16 January 2020 (UTC)

Discussion

• To clarify, is the difference between this and properties for this type (P1963) just that these would be more "mandatory" versus "usually present"? --Yair rand (talk ) 17:18, 16 January 2020 (UTC)

• @Yair rand: It's similar to that distinction but not exactly. The term mandatory implies that it would be mandatory for each item to have a statement. Ontologically it's necessary to have a date of birth to be a human. At the same time that date of birth might be unknown to Wikidata and thus there will be items for people that don't have date of birth filled and that would be fine. ChristianKl ❪✉❫ 19:52, 17 January 2020 (UTC)
• @ChristianKl: I guess they could have the values unknown (Q24238356) or not yet determined (Q59496158) if it was the case to have mandatory statements, though. TiagoLubiana (talk) 15:21, 4 February 2020 (UTC)

• @TiagoLubiana: unknown (Q24238356) and not yet determined (Q59496158) aren't to be used as values differectly but for qualifiers. Using them directly as values is going to produce constraint violations. You could have a bot that adds date of birth (P569) <UnknownValue> Qualifer nature of statement (P5102) not yet determined (Q59496158) but I don't see how having such a bot would be desireable. ChristianKl ❪✉❫ 16:19, 4 February 2020 (UTC)

•  Support. Nomen ad hoc (talk) 17:18, 17 January 2020 (UTC).

WikiProject Ontology has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. ChristianKl ❪✉❫ 20:04, 17 January 2020 (UTC)

•  Oppose you can do the same with qualifiers on properties for this type (P1963), e.g. already at Q46190676#P1963. --- Jura 09:57, 20 January 2020 (UTC)

There's no community consensus on what "has quality: requirement" means. It could plausibly mean "should", "must" or "necessity" (analog to this property). I believe that it's useful to well defined ways to map relations like this. ChristianKl ❪✉❫ 08:27, 21 January 2020 (UTC)

1. How would these three be different (if they are).
2. How would you indicate the meaning of "necessary" in a structured way on the property you propose? Would it be just in the label (i.e. unstructured)? --- Jura 08:30, 21 January 2020 (UTC)

1. When talking about policy I see the difference about must and should as the one defined in RFC2119. Should implies room for reasoned expections.

If we have an entity A and an item about A named I(A) then necessity in the way I propose means that A has the property but I(A) might not have the property as the relevant information might not be known to Wikidata or otherwise publically known. ChristianKl ❪✉❫ 14:40, 21 January 2020 (UTC)

So a concept that could get a different item and you would (or could) use on the proposed property? --- Jura 15:47, 21 January 2020 (UTC)

• Hello @ChristianKl:, I wish you a happy new year 2020 to start. I have time to write. Unfortunately for you, because it falls on you, but it is precisely because I have time. Don't worry, you're not alone (by far). You have to understand the concepts, as you write in your sub-pages. I am writing now, right away, because the contributors seem in a hurry to create nonsense on WD, even if they are asked for time to develop a coherent response on a strongly negative opinion (I take as witness URN formatter (P7470)).

If I summarize, and tell me if I am wrong: "if use of this class" = "necessary presence of this/these property/ies". I have underlined the term "necessary" which I take from your description. From your first example, we say that Albert Einstein (Q937) is part of Q5, so, as it belongs to this class, we need date of birth (P569) in Albert Einstein (Q937). Does my demonstration reflect your proposal? You give as an example properties for this type (P1963) for identical operation on instance of (P31). Before giving you my opinion, I humbly take you to consider the following, because it will also be useful in the future.

I have never used properties for this type (P1963) and for the following causes. Do you notice the Data type of P1963? This means that this property is used in other properties. However this is not the case, it is a property used in Items. You get the explanation of this type under Special:ListDatatypes (titled: Property (Wikibase entity id)). The examples can be obtained under Special:ListProperties/wikibase-property. related property (P1659) illustrates my point well: this property is used in the other properties to indicate additional information (similar properties for example, a property on football in connection with a property on football). In short, according to the debate and the description of properties for this type (P1963), the Data type to use must be Items, as here.

Do you also notice the term "occupation" in the Description of P1963? Well, nothing is introduced on this point in this property.

Continuing, P31 from P1963 is Wikidata property for documentation of properties (Q19820110). It is still not the right information (value) for the purpose sought in the debate. formatter URL (P1630) documents properties for example, QED.

The examples of P1963 give more or less the desired goal: when an Item is "of this nature", it is of a class, and one or more properties can be introduced into the Item.

We get to the constraints. Why use value-requires-statement constraint (Q21510864) in this property? Needless. value-type constraint (Q21510865) is an Item that may interest you, as it may be useful for your proposal. The relationship can and should be instance or subclass of (Q30208840) as described. Another problem on item-requires-statement constraint (Q21503247), it is not always possible on an Item to have subclass of (P279), or it should be a suggestion. Last constraint, multi-value constraint (Q21510857) should still be a suggestion constraint (Q62026391).

Another blunder and not the least: by taking one of your examples at random (I write at random, because it is valid for all the examples that you have put or that you will put), Q5 must necessarily have date of birth (P569). So if we follow this reasoning woman (Q467) must have a date of birth. Impossible. And it’s even more obvious if we used classes. Concerning the classes, we cannot attribute to them characteristics which would impact the subclasses.

In summary: Data type incorrect, infeasible and comparison (or suggestion of subproperty) with a bad property which is at the beginning an idea almost identical to this proposition (see the proposition of P1963).  Strong oppose and I suggest you already withdrawn in status. Cordially. —Eihel (talk) 21:44, 28 January 2020 (UTC)

@Eihel: One point of this exercise is to become more clear about what instance of (P31) means. woman (Q467) is not instance of (P31) human (Q5). woman (Q467) subclass of (P279) human (Q5). If this property would exist as proposed a new user who asks themselves is woman (Q467) instance of (P31) human (Q5) or woman (Q467) subclass of (P279) human (Q5) could know that it has to be woman (Q467) subclass of (P279) human (Q5) because human (Q5) has no date of birth.

The fact that you currently think that woman (Q467) instance of (P31) human (Q5) might be valid even through you are an established user, shows that it's important that we produce clarity here. Apart from woman (Q467) and human (Q5) there are plenty of cases in Wikidata where it's even harder to decide about whether to use instance of (P31) or subclass of (P279) and thus more importent to have clearer policy. properties for this type (P1963) alone doesn't allow you to reason as easily about whether to use instance of (P31) or subclass of (P279) because an item like woman (Q467) might have some of the properties for this type (P1963) but not others in both the case where it's a subclass and the case where it's an instance. ChristianKl ❪✉❫ 08:17, 29 January 2020 (UTC)

 Comment I believe that is a good property, and arguably clearer than using has characteristic (P1552) for properties for this type (P1963). But it seems quite similar to properties for this type (P1963) in the sense that they would have an overlap Just thinking out loud, maybe the "mandatory" idea, in the ontological sense, could also be achieved with a new property to qualify properties for this type (P1963). Something in the likes of an "ontological prevalence" with values as "total", "often" or "total for subclass", representing how often the instances of such a class harbor the value of these properties in the real world, regardless of whether we have this information in Wikidata or not. An example of "mandatory for subclass" would be for example, human (Q5) - properties for this type (P1963) - date of death (P570) as all humans that are deceased have a date of death (P570) . TiagoLubiana (talk) 19:21, 4 February 2020 (UTC)

 Oppose because I think properties for this type (P1963) is more flexible. However, if there is a difference between both with respect to enforcability of the constraint then I'm in favor of the more enforcable property. --SCIdude (talk) 17:46, 21 March 2020 (UTC)

 Support Iwan.Aucamp (talk) 20:04, 21 March 2020 (UTC)

•  Oppose per Jura1 and SCIdude. --Tinker Bell ★ ♥ 16:51, 22 March 2020 (UTC)