Wikidata:Property proposal/necessary property for class

From Wikidata
Jump to navigation Jump to search

necessary property for class[edit]

Return to Wikidata:Property proposal/Generic

   Under discussion
Descriptionall instances of this class necessarily have the property, even if the property might not be known to Wikidata
Data typeProperty
Domainitem
Example 1human (Q5)date of birth (P569)
Example 2architectural structure (Q811979)coordinate location (P625)
Example 3geographic location (Q2221906)coordinate location (P625)
See also

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

Motivation[edit]

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[edit]

  • @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)

--Micru (talk) 21:46, 24 August 2014 (UTC) Tobias1984 (talk) TomT0m (talk) Genewiki123 (talk) Emw (talk) 03:09, 9 September 2014 (UTC) —Ruud 16:15, 9 December 2014 (UTC) Emitraka (talk) 14:32, 14 October 2015 (UTC) Bovlb (talk) 19:10, 21 October 2015 (UTC) Peter F. Patel-Schneider (talk) 22:21, 23 October 2015 (UTC) ArthurPSmith (talk) 15:51, 5 November 2015 (UTC) --Daniel Mietchen (talk) 20:53, 3 January 2016 (UTC) --Harmonia Amanda (talk) 22:00, 27 February 2016 (UTC) --Lechatpito (talk) --Andrawaag (talk) 14:42, 13 April 2016 (UTC) --ChristianKl (talk) 16:22, 6 July 2016 (UTC) --Cmungall Cmungall (talk) 13:49, 8 July 2016 (UTC) Cord Wiljes (talk) 16:53, 28 September 2016 (UTC) DavRosen (talk) 23:07, 15 February 2017 (UTC) Vladimir Alexiev (talk) 07:01, 24 February 2017 (UTC) Pintoch (talk) 22:42, 5 March 2017 (UTC) Fuzheado (talk) 14:43, 15 May 2017 (UTC) YULdigitalpreservation (talk) 14:37, 14 June 2017 (UTC) PKM (talk) 00:24, 17 June 2017 (UTC) Fractaler (talk) 14:42, 17 June 2017 (UTC) Andreasmperu Andreasmperu Diana de la Iglesia Jsamwrites (talk) Finn Årup Nielsen (fnielsen) (talk) 12:39, 24 August 2017 (UTC) Alessandro Piscopo (talk) 17:02, 4 September 2017 (UTC) Ptolusque (.-- .. -.- ..) 01:47, 14 September 2017 (UTC) Gamaliel (talk) --Horcrux (talk) 11:19, 12 November 2017 (UTC) MartinPoulter (talk) Bamyers99 (talk) 16:47, 18 March 2018 (UTC) Malore (talk) Wurstbruch (talk) 22:59, 4 April 2018 (UTC) Dcflyer (talk) 07:50, 9 September 2018 (UTC) Ettorerizza (talk) 11:00, 26 September 2018 (UTC) Ninokeys (talk) 00:05, 5 October 2018 (UTC) Buccalon (talk) 14:08, 10 October 2018 (UTC) Jneubert (talk) 06:02, 21 October 2018 (UTC) Yair rand (talk) 00:16, 24 October 2018 (UTC) Tris T7 (talk) ElanHR (talk) 22:05, 26 December 2018 (UTC) linuxo Gq86 Gabrielaltay Liamjamesperritt (talk) 08:44, 21 June 2019 (UTC) ZI Jony Ivanhercaz (Talk) 11:07, 15 July 2019 (UTC) Gaurav (talk) 22:39, 24 August 2019 (UTC) Meejies (talk) 04:38, 29 August 2019 (UTC) SilentSpike (talk) Tfrancart (talk) Luis.ramos.pst.ag TiagoLubiana (talk) 15:12, 2 December 2019 (UTC) Albert Villanova del Moral (talk) 15:43, 6 February 2020 (UTC) Clifflandis (talk) 15:10, 18 February 2020 (UTC)

Pictogram voting comment.svg Notified participants of WikiProject Ontology ChristianKl❫ 20:04, 17 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. see also (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 property documentation (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). Symbol oppose vote oversat.svg 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)

Pictogram voting comment.svg Comment I believe that is a good property, and arguably clearer than using has quality (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)