This property requires better explanation and automatic checks to better differentiate from has part(s) (P527). To me it looks like both properties could be merged because the difference can be derived from context. This list of items that use both properties may help to better understand or find examples to explain: -- JakobVoss (talk) 13:09, 7 July 2016 (UTC)Reply

SELECT ?item ?itemLabel ?classPart ?classPartLabel ?part ?partLabel { 
  ?item wdt:P2670 ?classPart ; wdt:P527 ?part 
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" }
}

• Yes, has part (of the class) = has parts of the class = including = subsets: --Fractaler (talk) 09:14, 1 September 2016 (UTC)Reply
• has subsets of the set --Fractaler (talk) 14:08, 13 September 2016 (UTC)Reply
• Is this property about "parts"/composition (like has part or part of) or is it about class membership (like subclass of)? Some aliases are suggestive of one or the other, but these are completely different meanings of the property.DavRosen (talk) 19:23, 13 February 2017 (UTC)Reply

It seems to me that an inverse property is not P361 but subclass of (P279). --Infovarius (talk) 14:30, 16 February 2017 (UTC)Reply

That would make this property simply "superclass of", which would be a classification (class membership) property like subclass of or instance of, and could never apply to an instance (individual rather than class) -- an individual can't be a superclass or subclass of anything. Instead it turns out that this is *intended* to be a composition property like "has part" (and its inverse "part of"). In fact "has part" is widely used to mean what this "has parts of the class" is *intended* to mean. I asked about this because it was completely unclear to me as well: Wikidata:Project_chat#meaning_of_has_parts_of_the_class_.28P2670.29:_related_to_.22has_part.22_.28composition.29.3F_Or_more_related_to_.22has_subclass.22.2F.22has_superclass.22_.28generalization.2Fspecialization.29.3F and then Wikidata:Project_chat#has_parts_of_the_class_.28P2670.29_.28description_and_aliases.29 and along the way I changed the description and almost all of the aliases in a (perhaps hopeless) attempt to clarify. DavRosen (talk) 14:44, 17 February 2017 (UTC)Reply

If this "has parts of the class" were a subproperty of "has part", wouldn't that mean that "X has parts of the class Y" would imply that "X has part Y"? But when X is an instance and Y is a class, "X has part Y" means "The specific item X includes every instance of Y among its parts or components" according to Help:Basic_membership_properties. So for example "Andromeda Galaxy has parts of the class Star" would imply that "Andromeda Galaxy has part Star" which would mean "Andromeda Galaxy has EVERY Star among its parts", which is ridiculous -- our sun is a counterexample as a star that is not part of Andromeda Galaxy. Or am I misunderstanding what "subproperty of" means? DavRosen (talk) 18:48, 17 February 2017 (UTC)Reply

If you misunderstood, I also misunderstood. To me, "has parts of the class" makes sense if and only if it is not a sub-property of "has part" and if I can say "Solar system has parts of the class planet". FedericoMorando (talk) 01:09, 4 December 2017 (UTC)Reply

@TomT0m: what do you think about it? --Malore (talk) 07:34, 21 March 2018 (UTC)Reply

@Malore: I agree has part of the class is not a subproperty of « has part ». I removed the statement. author  TomT0m / talk page 09:15, 21 March 2018 (UTC)Reply

For example:

Scottish region (Q2138167)has part(s) of the class (P2670)Scottish district (Q21457810)

Or should it be used only on specific instances of the subject class?

Strathclyde (Q124661)has part(s) of the class (P2670)Scottish district (Q21457810)

On reflection, perhaps only the latter.

Jheald (talk) 17:47, 21 February 2017 (UTC)Reply

SubjectClass "has parts of the class" ObjClass simply means that each instance of SubjectClass has some parts [that are instances] of the class ObjClass. [Edit:] See the listed Wikidata property example: galaxy cluster has parts of the class galaxy, which means that each particular galaxy cluster is made up of (some set of particular) galaxies.DavRosen (talk) 19:49, 21 February 2017 (UTC)Reply

It should be disjoint union of (P2738) or another variant, not 2670. d1g (talk) 18:02, 6 September 2017 (UTC)Reply

Wrong. disjoint union of (P2738) specifically is only for instances not parts of a class. --SCIdude (talk) 07:28, 18 October 2022 (UTC)Reply

What about a roof organization (like a national football association) that has members (local clubs), all of the class "football club"? Same for many professional associations (an engineer's association having members that are all engineers, and so on). Would it be right to use P2670 or is there (or do we need) another property? --Anvilaquarius (talk) 09:44, 23 January 2018 (UTC)Reply

I agree with this confusion; another recent example of this is Q785745 (tank locomotive); tank locomotives include all of the parts of Q171043 (steam locomotive), apart from a tender, which is explicitly excluded in the page's Property:P3113. Should this property should be able to be used in such circumstances? WT79 The Engineer (talk) 21:08, 17 April 2020 (UTC)Reply

@Romaine:, I see you added an inverse constraint to this property. Was that discussed somewhere? My understanding was that this property specifically did not have an inverse constraint. Thanks. - PKM (talk) 00:34, 5 June 2018 (UTC)Reply

I re-added it as I noticed someone removed it without discussion. Romaine (talk) 13:46, 5 June 2018 (UTC)Reply

Fair enough. I still think an inverse constraint on an asymmetric property is incorrect. Tagging the constraints team for comments.

  Notified participants of WikiProject property constraints

The description for this property says

object class having some instance(s) that are «part of (P361)» the subject individual(s).

In other words, X«P2670»Y iff ∃z:(z«P31»Y ∧ z«P361»X).

However, the Basic membership properties help page says

the specific item X includes every instance of class Y among its parts or components,

i.e., X«P2670»Y iff ∀z:(z«P31»Y ⇒ z«P361»X).

These two statements are not logically equivalent. Which one (if either) is P2670 supposed to be?? 78.73.97.76 18:54, 29 June 2018 (UTC)Reply

I looked at the usage of the property and the reasonable uses all are for the exists reading. I'm going to change the Basic membership properties help page. Peter F. Patel-Schneider (talk) 07:59, 27 October 2019 (UTC)Reply

In the initial proposal it was not meant « every instance of the class are part of the subject». This would imply that we have a dedicated class for the parts of each item (of a certain kind), this would not be practical. author  TomT0m / talk page 09:47, 27 October 2019 (UTC)Reply

Русское описание: «класс, элементы которого являются составными частями указанного класса», английское "the subject instance has parts of the object class (the subject is usually not a class)". Кому верить? — Vort (talk) 06:16, 15 July 2019 (UTC)Reply

See Help_talk:Basic_membership_properties#"Hospital_XYZ"_has_part_"helipad". --- Jura 14:30, 29 June 2020 (UTC)Reply

I find the examples highly confusing.

May 1896 tornado outbreak sequence <has part(s) of the class> tornado outbreak

clearly means that all of the things in the item on the left-hand side are of type right-hand side.

But in

Missouri Senate <has part(s) of the class> member of the State Senate of Missouri

the left-hand side is MORE than a collection of things on the right-hand side. There are sessions in the Missouri Senate and these have member of the State Senate of Missouri. In the sense of a programming language, the left-hand is a collection or an array of the right-hand side. This is much stricter than <has part(s)>, which implies that the left-hand side has lots of parts of different types. --WiseWoman (talk) 08:47, 14 July 2020 (UTC)Reply

• Both are "instance-class" combinations: have a look at "Differences among has part (P527) and has parts of the class (P2670)" at Help:Basic_membership_properties. --- Jura 08:51, 14 July 2020 (UTC)Reply

This constraint should do here: property constraint (P2302)item-requires-statement constraint (Q21503247)property (P2306)instance of (P31). 2001:7D0:81F7:B580:DDF8:CA1:6CFE:FA22 15:37, 21 October 2020 (UTC)Reply

  Done SilentSpike (talk) 21:49, 11 January 2022 (UTC)Reply

@Lectrician1: Following your deletion proposal of this property I have clarified its usage with a new constraint, clearer description and correct inverse label item. I was actually mislead before by your description (it's not class -> class, it's instance -> class), but now even moreso believe this property should remain (see Help:Basic_membership_properties#Examples_2 for clear table showing difference in allowed domain/codomain of properties). --SilentSpike (talk) 21:48, 11 January 2022 (UTC)Reply

Does it really work? Wouldn't we end up having "part of" statements for all objects of "has part"-statements?

@TomT0m: who came up with it. --- Jura 23:01, 11 January 2022 (UTC)Reply

I'm afraid I don't understand your question, can you clarify? SilentSpike (talk) 14:53, 12 January 2022 (UTC)Reply

@SilentSpike If has part(s) of the class (P2670) is only supposed to be used on instances, I think we should rename the property to "instance has parts of the class" so that it indicates that it is not supposed to be used on classes. Lectrician1 (talk) 14:56, 13 January 2022 (UTC)Reply

@Lectrician1: I'd be fine with that, I think the "has" in English label subtly implies the same thing (grammatically it only makes sense following an instance) so no harm in us explicitly clarifying it. SilentSpike (talk) 17:10, 13 January 2022 (UTC)Reply

@Theknightwho: I've undone your removal of the item-requires-statement constraint (Q21503247) constraint on this property because the constraint is following our help pages which seems to be consensus and the original proposal's intention for the property. Can you explain why you believe this not to be the case? SilentSpike (talk) 11:53, 16 January 2022 (UTC)Reply

The reason for my removal is that the description says that the subject is usually not a class, but in my experience it sometimes is. While it's possible to get around this by creating a "type of X" metaclass and then stating that it's an instance of that, that feels quite contrived. Theknightwho (talk) 19:24, 17 January 2022 (UTC)Reply

@Theknightwho The fact is that this property is never supposed to be used on classes (see Help:Basic_membership_properties#Examples_2). Only has part(s) (P527) is. I had this same confusion which is what led me to create a property deletion request for this property. That mistakened confusion is reason these constraints were added in the first place.

If you believe otherwise, please give an example where this property should be used on classes. Lectrician1 (talk) 19:40, 17 January 2022 (UTC)Reply

So as one example that I've used myself, it seems to me that Unicode plane (Q10853148) has parts of the class Unicode code point (Q109615047). In fact, the example item given in that discussion, triathlon (Q10980), is a class. Theknightwho (talk) 19:47, 17 January 2022 (UTC)Reply

@Theknightwho Unicode plane (Q10853148) is a class and Unicode code point (Q109615047) is a class so it should use has part(s) (P527). triathlon (Q10980) is also a class and its parts are classes so it should use has part(s) (P527).

The thing you have to grasp is that has part(s) (P527) is the only "has part" property supposed to be used on classes. I know it's confusing that has part(s) of the class (P2670) can't be because it's name has "has parts of the class" in it, but that's why we added the constraints and changed the property name to include "instance". Lectrician1 (talk) 19:54, 17 January 2022 (UTC)Reply

While I understand your point, removing has part(s) of the class (P2670) from triathlon (Q10980) would remove independent information that is clearly distinct from that being shown by has part(s) (P527) at the moment. The item currently has both. Quite honestly, the ontology around has part(s) (P527) and has part(s) of the class (P2670) feels incomplete. With instances, you have the very straightforward choice of:

1. "X has part Y"

2. "X has parts of the class Y"

This is fine. However, with classes, you have several different ways of interpreting what either of these could mean.

1. "X has subclass Y"

2. "X has facet Y" - something that is an inherent part of the concept

3. "each instance of X has Y"

4. "each instance of X has parts of the class Y"

So to use Act of the Parliament of the United Kingdom (Q4677783) as an example, it has subclass Public General Act of the Parliament of the United Kingdom (Q105774620), it has the facet parliamentary sovereignty (Q1813642), each instance has text (Q234460), and each instance has parts of the class section (Q108149998). None of these are interchangeable (though admittedly, it feels quite unusual for a class to have a facet that its instances don't). The difference between countable and uncountable nouns seems to play a role here, too. Theknightwho (talk) 20:31, 17 January 2022 (UTC)Reply

I agree with you that the ontology around these properties feels incomplete. I actually don't like that has part(s) (P527) has two different meanings depending on whether it is used on a class or an instance - inherently introducing data ambiguity in the case where the subject is both a class and an instance. I consider this to be something of an antipattern as noted on my userpage.

As for the examples you provide. As it currently stands, this property has no defined meaning on class items so unless we want to introduce the same kind of conditional relationship I think the constraint should stand to highlight the ontological issue (too often on Wikidata constraints are removed only to suppress their purpose of revealing data issues). SilentSpike (talk) 22:23, 17 January 2022 (UTC)Reply

Yeah I really don't know how to solve this issue as of now and agree that there being 2 definitions for has part is suboptimal. I'll come back to this. Lectrician1 (talk) 20:53, 18 January 2022 (UTC)Reply

As I understand it, instances are inherently classes. They are particular members of a class. "Instance of" is a kind of something, otherwise it isn't "of" anything. This is contradictory to the reasoning of the constraint.

Also "Instance of" implies singleness rather than multiplicity therefore the use of part(s) would not be applicable unless referring to a group instance.

• "Has part(s) of the class" only restricts the value to being a type of something contained within.
  • This is simply a way of indicating certain types of components are part/s of the item.
• "Has part of the class"
  • denotes containing a single component of a certain type (Einstein's brain (component) of type/class brain) so Einstein had a part of the class brain.
• "Has parts of the class"
  • denotes multiple components sharing a common class (component set type) (Einstein's brain would not be "parts" of the class brain because it is not a set. You would not say he has parts of the class brains (at least in the technical sense, although this would allow a better sense of describing having "brains" :)

This is important as part specifically refers to being a particular component of something rather than a kind of something which is denoted by class.

These should probably be separated and refined to hopefully sort out the differences better. This may help pan out some of the confusion regarding the use of "instance of" and so on as well. AHIOH (talk) 01:15, 7 December 2023 (UTC)Reply

As an aside, I have changed the English description to the subject instance has parts of the object class (the subject is not a class). It doesn't make sense to use words like "usually" or "normally" if classes are specifically excluded. Theknightwho (talk) 17:21, 18 January 2022 (UTC)Reply

I added the samples from Help:Basic_membership_properties here as well. Better ones may be found, but let's keep them in sync. --- Jura 22:49, 11 January 2022 (UTC)Reply

@Swpb @Jura1 @SilentSpike @Theknightwho Could we please this property's English label back to "instance has parts of the class"?

Jura I think unintentional reverted the name change when removing some constraints I also earlier added.

I still see people getting confused and using it on classes despite the property's description and the constraint warning of "this item needs a instance of (P31) statement".

Also Swpb, if you want to keep the "has part or parts" part of the English label, could we just simplify it to "has part(s)"?

Lectrician1 (talk) 21:56, 17 February 2022 (UTC)Reply

Also, I think the discussion is done that this should only be used on instances. Could we just undo Jura's edit and re-add the constraint that stated that the property shouldn't be used on subclass of (P279)? Lectrician1 (talk) 21:59, 17 February 2022 (UTC)Reply

I can go for "instance has part(s) of the class". Swpb (talk) 22:42, 17 February 2022 (UTC)Reply

I'm good with the above proposed label yeah. Unsure about that constraint, but I can't think up a concrete counter example so no objection unless anyone can. SilentSpike (talk) 23:21, 17 February 2022 (UTC)Reply

I find the label "instance has part(s) of the class" too much of a mouthful, and more likely to confuse than clarify readers encountering the property. The original "has parts of the class" was better. The additional word "instance" contributes nothing, and just makes the property seem more difficult and more confusing. As the adage goes, better to Keep It Simple. Jheald (talk) 20:37, 25 February 2022 (UTC)Reply

@Jheald the reason the name was changed because people were continuing to use this on classes when it should only be used on instances. Including "instance" in the property lets editors know that they should only use it on instances. Lectrician1 (talk) 01:48, 26 February 2022 (UTC)Reply

I'd be ok with dropping the word "instance" in the label, given the presence of the conflicts-with constraint for P279. Swpb (talk) 18:12, 28 February 2022 (UTC)Reply

@Jura1 so @Swpb and I want to add a conflicts-with constraint (Q21502838) subclass of (P279). I don't think we need a "proposal". The plan is for users to clean up everything that violates the constraint when they come across it. It's not like we can run a bot to do this for us or that we should have the responsibility of cleaning it up. It is nobody's single effort to clean up constraint violations. This is a community project. If something is wrong, the community should be notified (through constraint violations), and as a collective and optional effort, they should clean it up. Lectrician1 (talk) 01:41, 3 March 2022 (UTC)Reply

Yes, indeed, it's not up to you to do so, but we do need a plan how to deal with the constraint violations. If someone else can, that would be sufficient. The list is [1]

The proposed constraint goes against a key outline about the use of basic Wikidata properties: so, no, it's not a good idea to add a constraint just to notify the community that you added a constraint and want them to develop a plan for you. Maybe revising that outline first would even be the preferable. --- Jura 08:24, 3 March 2022 (UTC)Reply

@Jura1 What outline does it violate? I'm confused.

I also still don't get why we need a "plan" and what that would even involve... The situation is pretty basic to me: stuff's broken, there's an explanation why, so editors will fix it. Lectrician1 (talk) 12:35, 3 March 2022 (UTC)Reply

I also don't know what "outline" Jura is talking about (certainly not Help:Basic membership properties, which says the exact opposite), and the "plan" (so simple as to barely merit that label) is explicitly laid out in this property's usage instructions, the property example, and (now more explicitly) in the constraint clarification (P6607): if an item uses has part(s) of the class (P2670) but has a subclass of (P279) statement, it should use has part(s) (P527) instead. The consensus on that, and by extension on the validity of this constraint, has already been established at Help:Basic membership properties, and should be challenged there if at all. And even if it weren't for that, support here for the constraint stands at 2 (or possibly 3 or 4) for to 1 against, so reversion is also not justifiable on that basis. The number of constraint violations does not affect the validity of the constraint, and for what it matters, the migration of violating statements is one easily doable by a bot. Swpb (talk) 15:15, 3 March 2022 (UTC)Reply

Can you provide quote from Help:Basic membership properties that supports your view?

What would be the added value of the constraint?

It's clear that one should be able to explain how existing statements should be fixed if one considers the constraint as needed. Isn't it? Otherwise the fix will just end up being the deletion of the constraint. --- Jura 16:40, 3 March 2022 (UTC)Reply

@Jura1

Quote: "has part(s) of the class (P2670) not used because <body> and <head> are both classes" Link

The value is that people would use the property correctly.

The explanation was provided as a constraint clarification, and furthermore, the property description, and label both also clarify that the property should not be used on classes and only instances. Lectrician1 (talk) 21:39, 3 March 2022 (UTC)Reply

Your quote seems to come from an explanation of a specific sample (not sure which one).

I understand that Wikidata properties aren't necessarily easy to use and adding constraints isn't that simple and shouldn't be done lightly.

You seem to have been confused about this property's definition (Wikidata:Properties_for_deletion/Archive/2022/2#P2670: "This property is supposed to be used on classes and it's values should be classes. However, people who do not realize that an item is a class sometimes use has part (P527) instead or both properties. It would be much more simple to use has part (P527) and enforce that the value should be a class when used on classes and an instance when used on instances.".

Maybe it's easier to just look at specific usecases and help you apply it there correctly. What statements do you want to add to Wikidata and where do you hesitate about the properties to use? --- Jura 10:33, 4 March 2022 (UTC)Reply

@Jura1 My understanding of the definition of this property has changed since the deletion discussion. Community members have informed me and I have agreed that has part(s) of the class (P2670) is supposed to be used for instance-class part relationships and has part(s) (P527) for instance-instance and class-class part relationships - just as Help:Basic membership properties describes. Therefore, if has part(s) of the class (P2670) is supposed to only be used on instances, the item it's used on should not be a class and therefore should not have has part(s) of the class (P2670) - thus justifying the constraint.

This discussion seems really weird Jura. I feel like you don't understand the definition of this property if you can't see why this constraint is valid... Lectrician1 (talk) 14:31, 4 March 2022 (UTC)Reply

It seems we don't agree on the change. If you have a usecase you attempt to solve, please outline it. --- Jura 15:41, 4 March 2022 (UTC)Reply

The use case is that it's the correct way to use the property. Why else do constraints exist? Lectrician1 (talk) 16:23, 4 March 2022 (UTC)Reply

@Jura1: The "quote" you can't seem to find is in the third and fourth lines of the table Help:Basic_membership_properties#has_part_(P527)_vs._instance_has_part(s)_of_the_class_(P2670): "instance has part(s) of the class not used because <X> and <Y> are both classes". If you can't (or won't) see how that directly and unequivocally entails the conflicts-with constraint, I can't help you. I also very clearly laid out how existing statements should be fixed, despite this already being incredibly clear, which you seem to be intentionally ignoring. You're also revert warring for a definitely non-consensus position, and from this point forward that matter will be addressed here: Wikidata:Administrators'_noticeboard#Warring_by_User:Jura1_on_instance_has_part(s)_of_the_class_(P2670) Swpb (talk) 15:27, 4 March 2022 (UTC)Reply

Apparently you couldn't find the quote either, as you provide two locations. --- Jura 16:19, 4 March 2022 (UTC)Reply

It's the explanation for a sample. It doesn't mean you should add a constraint here.

I think the constraint you are looking for is an "item requires statement" constraint. --- Jura 15:34, 4 March 2022 (UTC)Reply

That "explanation of a sample" is obviously meant as an instruction that the same logic applies to all such cases. No, we are not looking for an "item requires statement" constraint. Many items are instances in one sense and classes in another. It is the presence of subclass of (P279), not the absence of instance of (P31), that violates the guide. Swpb (talk) 15:49, 4 March 2022 (UTC)Reply

I don't think there is a sample that covers the hypothesis. --- Jura 15:53, 4 March 2022 (UTC)Reply

(Pretty) new to this discussion. I fail to see how the proposed constraint is motivated, but I do see that there are ~12k (or so) potential constraint violations. Can someone please quickly summarize, or point to related previous discussions? —MisterSynergy (talk) 18:55, 4 March 2022 (UTC)Reply

@MisterSynergy The constraint is motivated by the policy that this property is supposed to be used only for instance-class part relationships. Not for class-class relationships. For examples, see Help:Basic_membership_properties#has_part_(P527)_vs._instance_has_part(s)_of_the_class_(P2670). This means that it should not be used on items that are classes and therefore should not have a subclass of (P279) statement. Lectrician1 (talk) 19:42, 4 March 2022 (UTC)Reply

First of all, Help:Basic membership properties is not a policy page. However, it is important (including its revision history and talk page) to understand the discussion. I have two concerns:

1. The separation between instances and classes is not always super easy and obvious, which is why we have that concept of metaclasses. There are simply situations which can be modelled either way, and we do not do this consistently in Wikidata. This is good in some sense since different topics can be modeled with somewhat individual solutions, but we should IMO not let the data model dictate too much which other properties we may use on that particular item.
2. Looking at this query, there are some thousand potential constraint violations that should be fixable when this constraint is being implemented. I do not expect you to do this by yourself if you lack the technical skills to make edits, but I do expect you to analyse the situation and come up with a migration plan for the majority of cases. Someone has put a lot of effort into these claims and they do indeed seem useful, so please do not simply render them invalid.
   I would also like to mention that further above, you claim that passers-by should simply fix the constraint violations when they stumble upon them on item talk pages. This is a terrible idea that will not work for sure: there is no guidance how to fix such a violation (and this really isn't an easy case), there is no coordinated plan for similar cases which might result in pure chaos, and finally it is known that this is not a way to reduce the amount of violations in any meaningful way.

In my opinion, the item carrying has part(s) of the class (P2670) can either be a class or an instance item, but the claim value needs to be a class item. This is useful for situations where the "parts" do not have individual Wikidata items, but we do want to express how they conceptually look like. —MisterSynergy (talk) 20:08, 4 March 2022 (UTC)Reply

@MisterSynergy

1. If you know the distinction between items that are classes that have "instance of: metaclass" and are just "normal" instances, you should know which is a class and which is not and whether this property should be used.
2. Like above, if you understand what an instance is and what a class is, you are likely to and should know when to remove the statement. There is extremely specific and easy guidance on when to remove this: it shouldn't be used on classes. If you don't know exactly what a class is, chances are you're not going to touch such a violation. If you learn what a class is, you will be able to know when you should remove it. This will not result in any chaos. The constraint was in place for like 2 weeks already and we didn't see any "chaos". Finally, there's no possible way to formulate a "plan" to fix this. This is not like of (P642) where the property is conflated and has multiple but common use cases. In almost all improper usages of this property it's just used wrong and likely the value statement is supposed to use a has part(s) (P527) statement instead. If you have any idea on how to formulate a "plan", please let Swpb and I know because we don't.
3. If you say it can be used on a class than it duplicates what has part(s) (P527) does (has part(s) (P527) is supposed to be used on a class with class values). This is bad. This confusion that is exactly what prompted me to propose deleting the property in the first place. Either the guidance at Help right now is correct (which is why the deletion proposal was closed), or we still have the problem that this property and has part(s) (P527) are used for conflating purposes. Lectrician1 (talk) 20:44, 4 March 2022 (UTC)Reply

I am not happy with the notion that you recommend a plain removal as a default solution. These claims are there for a reason—conceptually correct but technically (maybe) flawed—so they should by default be migrated to some other property or to a completely different model. This is actually the migration plan I was asking for. If you look at the query result I posted earlier, you’ll realize that plenty of cases look very similar in fact; which means that the very same solution should be applied to subsets of cases, and this should be done with automation in order to prevent erratic and exhaustive manual editing. Setting up a migration plan does require to somehow identifiy these subsets and their individual solution. As much as I understand, "move to P527" could be deemed the default solution that fits a majority of cases, but I am not sufficiently into this in order to make such claims here. —MisterSynergy (talk) 20:59, 4 March 2022 (UTC)Reply

@MisterSynergy Okay, couldn't we just recommend "move to P527" as part of the constraint clarification then? Lectrician1 (talk) 21:27, 4 March 2022 (UTC)Reply

Real life calls, but I want to make it clear that no one is calling for removal of statements. Migration to has part(s) (P527) is the fix for all cases where the item has subclass of (P279). There is a long-standing consensus, recently reaffirmed, that that is how the two "parts" properties should be used: instance–class statements use this property, instance–instance and class–class use has part(s) (P527). To me, that consensus mandates this constraint, without exception, which makes migration easily automatable. Swpb (talk) 21:37, 4 March 2022 (UTC)Reply

User:Lectrician1 phrased it earlier as if removal was the default option.

If the migration was that easy—move to P527—I’d not oppose such a constraint (but I would not endorse it either). However, out of the ~12k cases which seem to violate the proposed constraint, a whopping 5.4k have both P31 and P279 [2]. What’s the solution for them? —MisterSynergy (talk) 22:07, 4 March 2022 (UTC)Reply

The solution is to fix them. Lectrician1 (talk) 23:16, 4 March 2022 (UTC)Reply

Not sure what this means—do you imply that either P31 or P279 should be removed for those cases and this should be assessed individually? —MisterSynergy (talk) 23:28, 4 March 2022 (UTC)Reply

It should be determined whether they are classes or instances and then use the appropriate property for parts. Lectrician1 (talk) 00:15, 5 March 2022 (UTC)Reply

If this doesn't resolve the violation of the hypothetical constraint, what then? --- Jura 12:09, 5 March 2022 (UTC)Reply

Why wouldn't it resolve the constraint? Lectrician1 (talk) 15:18, 5 March 2022 (UTC)Reply

If you use P2670 (given the P31), this will still conflict with the P279 on the same item. --- Jura 15:26, 5 March 2022 (UTC)Reply

Right, which means the usage of has part(s) of the class (P2670) is on a class, which is wrong. Likely, the item should use has part(s) (P527) instead. If the user changes it to that, the constraint will go away. Lectrician1 (talk) 15:30, 5 March 2022 (UTC)Reply

So you are saying that if an item has both, P527 should be used? --- Jura 15:37, 5 March 2022 (UTC)Reply

Yes. Or, it's possible (but not extremely uncommon) the item is incorrectly a class and subclass of (P279) should be removed. Lectrician1 (talk) 15:38, 5 March 2022 (UTC)Reply

If so, can you add it to Help:Basic_membership_properties? This way it's clear for other people what you plan. --- Jura 22:11, 5 March 2022 (UTC)Reply

I think this is already very clear. See the "explanation" and "why not use..." columns of the table. Lectrician1 (talk) 22:35, 5 March 2022 (UTC)Reply

Why wouldn't you want to add it explicitly? Seems you go to great lengths to explain to me and MisterSynergy what's clear to you, but you don't seem to want to write it down as guidance for the 5000 statements added by Wikidata contributors. --- Jura 11:30, 6 March 2022 (UTC)Reply

@Jura1 @MisterSynergy @Swpb   Done Help:Basic_membership_properties#has_part_or_parts_(P527)_vs._instance_has_part(s)_of_the_class_(P2670).

Is it now okay to add the constraint and an explanation clarifying the constraint and link to further explanation? Lectrician1 (talk) 17:53, 6 March 2022 (UTC)Reply

Maybe it's just me. I don't think constraints need be explained there, but it still doesn't clearly state that if it has P279+P31 then P527 is to be used. --- Jura 23:04, 6 March 2022 (UTC)Reply

Well then metaclasses would have to be explained and I don't want to get into that. Lectrician1 (talk) 02:24, 7 March 2022 (UTC)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ What needs to be said about metaclasses? They aren't handled any differently. If an item is any level of class, it shouldn't use this property. Items with instance of (P31) and subclass of (P279) shouldn't use this property. This property is only for use on items that are only instances; otherwise it overlaps has part(s) (P527). I've added even further clarification of that to Help:Basic membership properties. Ok, @MisterSynergy, Jura1:? Swpb (talk) 16:35, 7 March 2022 (UTC)Reply

@MisterSynergy: Please respond. Swpb (talk) 14:39, 9 March 2022 (UTC)Reply

See this discussion, we are trying to sort out some cases inserting more focused examples for the properties of the "has part of" family.--Alexmar983 (talk) 01:09, 25 April 2022 (UTC)Reply

We just had a big discussion here that settled these use questions. Swpb (talk) 14:59, 25 April 2022 (UTC)Reply