Wikidata:Property proposal/applies to property - Wikidata

Originally proposed at Wikidata:Property proposal/Generic

Model items can at the moment be either for P31 or for other properties. To automatically work with them it's good when it's specified with structured data to which property a given statement refers. I formulated this property open enough to be also used in other contexts. If anyone has suggestions on how to improve the description I'm happy to hear them. ChristianKl ❪✉❫ 14:51, 7 January 2023 (UTC)[reply]

•   Comment Do we actually need another property merely to indicate which properties should be considered to have a particular characteristic, such as "similar to instance of" or whatever? Couldn't we simply use an item "Wikidata property similar to instance of" and make the properties instance of (P31) this class, then refer to this class in constraint checking, list creation, model item evaluation etc? We would have to have to create a separate Wikidata class per property we intend to mimic, but right now I can't think of any other property of that kind besides instance of (P31). Sorry, I didn't read your proposal properly. Maybe a good idea then, need to think about it. --SM5POR (talk) 15:32, 7 January 2023 (UTC)[reply]

  I'm still skeptical, but on other grounds:

  • It requires more care to get each model item statement right. What do we do if the qualifier is missing? Do we have a default interpretation, or should the qualifier be mandatory?
  • Since the qualifier must match existing relationships such as politician being an occupation, it opens a door to numerous non-functional (and possibly misunderstood) configurations, say politician (Q82955)model item (P5869)Nelson Mandela (Q8023)applies to use with propertysubclass of (P279)

  Maybe we can put this proposal on hold while we sort out current usage and learn what editors have tried to do? There are half a dozen cases of model item being assigned to properties, and a few hundred as qualifiers (hence constraint violations). SM5POR (talk) 16:04, 7 January 2023 (UTC)[reply]

  Rather than adding a qualifier to each model item claim, I'd prefer putting it as a main statement on the class item itself (politician (Q82955)property of model itemoccupation (P106)) and make instance of (P31) the default if this property is missing. All model items for a class item should relate to the same property. SM5POR (talk) 16:24, 7 January 2023 (UTC)[reply]

  Using value hierarchy property (P6609) we could make the property of model item inherited so that putting it on "professional" will apply to all occupations etc. SM5POR (talk) 16:36, 7 January 2023 (UTC)[reply]

  In order not to tie it to model item (P5869) specifically, rather than "property of model item" I suggest calling it "item descend property" (the implicit understanding of this being "property by which we descend down the item tree"; I hope that makes sense).

  While I appreciate your effort to make it as flexible as possible by expressing it with a qualifier, that flexibility would actually be counter-productive here. The whole idea of model items is based on the notion of equivalence, congruence and similarity to neighbor items. By allowing different model items to relate to different property hierarchies, you will potentially end up with each model living in its own structural universe, unrelated to every other item.

  Today we have model items on 700 different classes. I anticipate a situation where we have model items on perhaps 70,000 different classes, many of them automatically created using meta-model templates. To make this manageable, not only entire classes will have to refer to the same tree descend property, but entire branches such as "professionals", "science", "business", "arts" etc. That can be accomplished via transitive properties (not only subclass of (P279)) and value hierarchy property (P6609). SM5POR (talk) 18:30, 7 January 2023 (UTC)[reply]

  There's the general wisdom of explicit is better than implicit. There's no reason to have defaults. There are currently only around 1000 model items. In the beginning after the property is created, we manually add all qualifiers for non-P31 and then add P31 to the remaining items. Afterward a constraint can get the user who creates new model item claims to apply the qualifier. Choosing model items require thought. Requiring an additional qualifier doesn't make the work overly complex.

  Having the information on every model item statement is useful for creating queries. If you have to track down an inherited "item descend property" that's a lot of work for the writing of the SPARQL query or other automatic processes.

  "All model items for a class item should relate to the same property" I see no reason for why we should enforce such a rule. While those cases might not be very common, having syntax that allows users to document model items with different properties seems to me a clear plus.

  For items that have both items that relate to them with P31 and items that relate to them with P279 having model items for both would help make it more clear to users whether they should link to them with P31 or P279. ChristianKl ❪✉❫ 21:26, 7 January 2023 (UTC)[reply]

  Okay, you have some valid general points, while I'm trying to short-cut the process by leaving out those options I doubt will be of general use and aim for end result right away. Your advantage is actually getting to try everything out instead of making assumptions. I'm still skeptical about those experiments, but I'd rather be proven right than merely assumed so, wherefore I'm passing the ball to you.   Support SM5POR (talk) 21:46, 7 January 2023 (UTC)[reply]

  Here is another example for your proposal: Minnesota (Q1527)model item (P5869)Chisago County (Q486309)applies to use with propertylocated in the administrative territorial entity (P131) SM5POR (talk) 22:10, 7 January 2023 (UTC)[reply]

  Another one: Jupiter (Q319)model item (P5869)Europa (Q3143)applies to use with propertyparent astronomical body (P397) SM5POR (talk) 22:17, 7 January 2023 (UTC)[reply]

  Haplogroup K (Q1544376)model item (P5869)Haplogroup K1 (Q45768221)applies to use with propertyfollows (P155) SM5POR (talk) 22:25, 7 January 2023 (UTC)[reply]

  water (Q283)model lexeme (P11464)Wasser (L2098)applies to use with propertyitem for this sense (P5137) SM5POR (talk) 22:43, 7 January 2023 (UTC)[reply]

  Lyra (Q10484)model item (P5869)Vega (Q3427)applies to use with propertyconstellation (P59)

  Delta Scuti variable (Q836976)model item (P5869)Vega (Q3427)applies to use with propertytype of variable star (P881)

  A-type main sequence star (Q471805)model item (P5869)Vega (Q3427)applies to use with propertyinstance of (P31)

  navigational star (Q108171565)model item (P5869)Vega (Q3427)applies to use with propertyinstance of (P31)

  Castor Moving Group (Q1049735)model item (P5869)Vega (Q3427)applies to use with propertypart of (P361)

  Hipparcos Catalogue (Q537199)model item (P5869)Vega (Q3427)applies to use with propertycatalog (P972)

  --SM5POR (talk) 09:47, 8 January 2023 (UTC)[reply]

  Adding an example for model lexeme (P11464) is a good idea. When it comes to the others, I think it makes sense to use model item (P5869) when the model items for the context include statements that are not typical for what you would expect given the instance of (P31) model items. Without having domain knowledge in astrology its unclear to me whether that's a case of your examples around Vega (Q3427). I think having three clear examples based on the existing examples for model item and model lexeme is enough. ChristianKl ❪✉❫ 18:21, 8 January 2023 (UTC)[reply]

  Fine; I'm aware that I may be trying to illustrate issues that are still beyond our immediate scope of action, so these need not be in the examples. The idea with listing six different model item statements pointing at Vega (Q3427) is that there may ultimately be competition between different model groups over which item "neighborhood" individual items will align with, in case they evolve differently, a little like having different ethnic communities interact with each other in the same geographic area. But invoking sociology to discuss relationships between semantic data structures may be stretching it a bit too far... And astronomy (Q333) is different from (P1889) of astrology (Q34362) :-) SM5POR (talk) 20:36, 8 January 2023 (UTC)[reply]

  I can imagine that there will be in the future cases where that's the case. It's however not the case for Vega, so Vega doesn't make a good example for it. ChristianKl ❪✉❫ 20:56, 8 January 2023 (UTC)[reply]

  The example isn't Vega, the example is the intersection between different aspects on the study of astronomical objects. If you group Vega with other A-type main sequence stars anywhere in the galaxy you will likely get an astrophysical focus on mass, spectrum, age and absolute brightness, but if you instead group it with other objects (not necessarily stars) in a particular part of the northern hemisphere you may instead get an observational focus on visibility to the naked eye, occultations (not likely that far from the ecliptic though), best time of year for observations, mythology and navigation in ancient times.

  You are right in the sense that Vega is already in the database, a star is a star no matter why we look at it, and we will most likely record whatever data we have on it regardless. It's just the focus of the model groups that will be different, and maybe Vega won't even be a model item for some of them. Anyway, I'm way ahead of myself here, and we have issues of more immediate concern to resolve. As already said, you have my support for the creation of the property as specified. SM5POR (talk) 23:19, 8 January 2023 (UTC)[reply]

  National Aeronautics and Space Administration (Q23548)model item (P5869)New Horizons (Q48461)item descender propertyoperator (P137)

  Alfred Hitchcock (Q7374)model item (P5869)The Birds (Q110043)item descender propertydirector (P57)

  Digital Equipment Corporation (Q690079)model item (P5869)PDP-11/73 (Q7118842)item descender propertymanufacturer (P176)

  Homo sapiens (Q15978631)model item (P5869)Protein tyrosine phosphatase non-receptor type 22 (Q21114040)item descender propertyfound in taxon (P703)

  You may want to limit your examples to a selection of these. Note that one example involves the new model lexeme (P11464) property. I'm retracting my label suggestion, however, as yours sounds more generic. I suggest allowing the property both as a qualifier and as a main statement on the group (class) item, as a hint or suggestion when the editor doesn't have an idea of what property to use. Related property: instance of (P31). --SM5POR (talk) 11:01, 8 January 2023 (UTC)[reply]

• @ChristianKl, SM5POR:   Done: applies to use with property (P11527). Regards Kirilloparma (talk) 16:53, 23 January 2023 (UTC)[reply]