Wikidata:Property proposal/value is inherited from

From Wikidata
Jump to navigation Jump to search

item inherits value from[edit]

Originally proposed at Wikidata:Property proposal/Generic

Descriptionthis value is inherited from the parent (super)class; parent class has exactly the same statement as this statement (To be used in a source field)
Data typeItem
Domainany items with subclass of (P279)
Allowed valuessuperclasses of the subject item (subject item is a subclass of (P279) of the value)
Example 1
(Note that stomach cancer (Q189588) is a subclass of stomach disease (Q175827), and P927 values of both stomach cancer (Q189588) and stomach disease (Q175827) are the same stomach (Q1029907))
Example 2
(Note that finding by heart auscultation (Q30078856) is a subclass of cardiac finding (Q53019661), and P927 values of both finding by heart auscultation (Q30078856) and cardiac finding (Q53019661) are the same heart (Q1072))
Example 3
(Note that systolic ejection murmur (Q30066258) is a subclass of systolic heart murmur (Q7663898), and P4774 values of both systolic ejection murmur (Q30066258) and systolic heart murmur (Q7663898) are the same systole (Q496359))
Example 4
(Note that hydrogen chloride (Q211086) is a subclass of hydrogen halide (Q1572088), and P527 values of both hydrogen chloride (Q211086) and hydrogen halide (Q1572088) are the same hydrogen (Q556))
Example 5
(Note that first Monday in January (Q23034740) is a subclass of first Monday of the month (Q23034736), and P2894 values of both first Monday in January (Q23034740) and first Monday of the month (Q23034736) are the same Monday (Q105))
Example 6
< chirashizushi (Q865773) View with Reasonator View with SQID > country of origin (P495) View with SQID < Japan (Q17) View with Reasonator View with SQID >
value is inherited from search < sushi (Q46383) >

(Note that chirashizushi (Q865773) is a subclass of sushi (Q46383), and P495 values of both chirashizushi (Q865773) and sushi (Q46383) are the same Japan (Q17))
See alsoWikidata:Property proposal/value is more specific than, inferred from (P3452)

Motivation[edit]

Wikidata Inheritance Model.svg

In Wikidata, subclass of (P279) is widely used. Some statements in the child (sub)class are exactly the same as those in the parent (super)class. However, we have no way of explicitly representing that the statement in the child class is inherited from its parent class. Using this property clarifies the relationship between a child and parent classes, and enhances robustness of the data structures. --Okkn (talk) 15:12, 30 July 2018 (UTC)

See also Wikidata:Property proposal/value is more specific than. --Okkn (talk) 15:11, 20 August 2018 (UTC)

Anandhisuresh (talk) 17:16, 28 February 2018 (UTC)anandhisuresh Tobias1984
Doc James
User:Bluerasberry
Wouterstomp
Gambo7
Daniel Mietchen
Andrew Su
Peter.C
Klortho
Remember
Matthiassamwald
Projekt ANA
Andrux
Pavel Dušek
Was a bee
Alepfu
FloNight
Genewiki123
Emw
emitraka
Lschriml
Mvolz
Franciaio
User:Lucas559
User:Jtuom
Chris Mungall
ChristianKl
Gstupp
Geoide
Sintakso
علاء
Dr. Abhijeet Safai
Adert
CFCF
Jtuom
Lucas559
Drchriswilliams
Okkn
CAPTAIN RAJU
LeadSongDog
Ozzie10aaaa
Sami Mlouhi
Marsupium
Netha Hussain
Abhijeet Safai
ShelleyAdams
Fractaler
Seppi333
Shani Evenstein
Csisc
Pictogram voting comment.svg Notified participants of WikiProject Medicine: This qualifier is especially useful to describe medical concepts. --Okkn (talk) 15:27, 20 August 2018 (UTC)

As per Pasleim's suggestion, we would deal with this property as a source property, instead of qualifiers. So I chaged the description. --Okkn (talk) 12:22, 12 September 2018 (UTC)

Discussion[edit]

  • Symbol support vote.svg Support. --Csisc (talk) 19:30, 20 August 2018 (UTC)
  • As far as I understand our datamodel, the subclass relationship means that there's an implicit inheritance. I don't see the point in this explicit statement. ChristianKl❫ 16:09, 23 August 2018 (UTC)
    • @ChristianKl: Thank you for your comment. I think that a subclass does not always simply inherit the value in the superclass, and often updates it. This qualifier will be useful especially when the subclass multiply inherit more than one superclasses. For example, stomach cancer (Q189588) is a subclass of both gastrointestinal system cancer (Q5526839) and stomach disease (Q175827), but the anatomical location (P927) value stomach (Q1029907) is only inherited from stomach disease (Q175827). Persons or computers who don't know well about the superclasses cannot understand where the value "stomach" comes from, without additional queries. Explicit statements clarify how the subclass and its superclass are similar or are different, and how the superclasses of a class are different. In addition, even if the value in the superclass mistakenly changed or removed, we can detect that. Regards, --Okkn (talk) 17:27, 23 August 2018 (UTC)
  • Pictogram voting comment.svg Comment My concern is that every item in every domain could potentially have dozens of these statements, inheriting or restricting the properties of all of its parent classes. Do we really want to have statements on every type of tree that it <has parts of the class> "trunk", "crown", "leaf", etc.? - PKM (talk) 19:48, 23 August 2018 (UTC)
    • @PKM: These qualifiers are similar to reference. Not all statements should have these qualifiers, but if we use them, the relations will become robust. In addition, indeed, statements we can apply these qualifiers are limited, because most of the items in Wikidata are instances (not class) and most of the statements are identifiers or peculiar values (which are not inherited by subclasses). As for the tree example, it is not needed that each types of trees have such <has parts of the class> statements in the first place, is it? --Okkn (talk) 21:00, 23 August 2018 (UTC)
  • Symbol support vote.svg Support. --Ranjithsiji (talk) 05:01, 11 September 2018 (UTC)
  • Pictogram voting question.svg Question Shouldn't that be a source property rather than a qualifier? --Pasleim (talk) 16:18, 11 September 2018 (UTC)
    • @Pasleim: This kind of data may not be a source of information, but I don't mind if we make a rule that these properties should be used as source properties, instead of qualifiers. --Okkn (talk) 07:54, 12 September 2018 (UTC)
      • It's not a source in the classical sense but the property would indicate from where a value is taken, so I would use it in source section. Basically, the proposed property is a special case of inferred from (P3452) --Pasleim (talk) 10:01, 12 September 2018 (UTC)
        • @Pasleim: I got it. I have changed the description of this peroperty and the related proposal. Thanks, --Okkn (talk) 12:22, 12 September 2018 (UTC)
        • I agree with using it as a reference rather than a qualifier. For example, if you merge two items where one has a statement with this property and the other has the same statement without this property, the statements should be merged. That will happen with references but not with qualifiers. - Nikki (talk) 09:17, 13 September 2018 (UTC)
          • I think what you say is right. Reference would be more useful. --Okkn (talk) 04:18, 14 September 2018 (UTC)
  • Pictogram voting comment.svg Comment If this is added, I think some people are likely to confuse it with inferred from (P3452). I wonder if calling it "item inherits value from" would be better in English? (i.e. phrasing it more actively, to emphasise that it continues inheriting the value) - Nikki (talk) 09:17, 13 September 2018 (UTC)
    • That sounds good! I'll adopt your suggestion. --Okkn (talk) 04:18, 14 September 2018 (UTC)

@Pasleim, ChristianKl, Ranjithsiji, Csisc, Nikki, PKM: @Okkn: ✓ Done: item inherits value from (P5852). − Pintoch (talk) 20:16, 16 September 2018 (UTC)