Wikidata:Property proposal/member of musical group

‎member of musical group

Originally proposed at Wikidata:Property proposal/Person

   Not done

Description	member of musical group
Represents	musical group member (Q52630241)
Data type	Item
Domain	human (Q5)
Allowed values	instances of musical group (Q215380)
Example 1	John Lennon (Q1203) → The Beatles (Q1299)
Example 2	Anni-Frid Lyngstad (Q201908) → ABBA (Q18233)
Example 3	Freddie Mercury (Q15869) → Queen (Q15862)

Motivation

Per discussion at Wikidata_talk:WikiProject_Music/2022_review_proposal#Re:_band_members as "subproperty of (Property:P1647)" "member of (Property:P463)", other subproperties "member of" exist:

1. member of sports team (Property:P54) - value type: sports team (Q12973014) and others - each(?) a subclass of organization (Q43229)
2. member of political party (Property:P102) - value type: political party (Q7278) and others - each(?) a subclass of organization (Q43229)
3. member of cabinet (Property:P5054) - as qualifier
4. member of the crew of (Property:P5096) - value type: vehicle (Q42889) [physical entity], flight (Q206021) [process]

TangoAF (talk) 09:44, 31 July 2026 (UTC) - Add some information regarding the existing subproperties after comment by Yirba below. TangoAF (talk) 13:27, 31 July 2026 (UTC)

member of and subproperties thereof

property label	property ID	usage main	subject type	value type
member of	Property:P463	714,079	person, organization and others	organization (Q43229) and others
member of family	Property:P53	139,807	human and others	family (Q8436) (subclass of organization (Q43229)) and fictional family (Q15331236)
member of sports team	Property:P54	1,768,812	human and others	sports team (Q12973014) and others - each(?) a subclass of organization (Q43229)
member of political party	Property:P102	655,082	human and others	political party (Q7278) and others - each(?) a subclass of organization (Q43229)
member of airline alliance	Property:P114	317	airline, exception Deutsche Bahn	airline alliance (Q465909) - subclass of organization (Q43229)
member of ethnic group	Property:P172	151152	person and others	ethnic group (Q41710) and others - subclass of group of humans (Q16334295)
member of chivalric order	Property:P550	95	person	order of chivalry (Q2003221) - subclass of organization (Q43229)
member of religious order	Property:P611	49,746	human, organization, geographical feature(!) and others	religious order (Q2061186) and others - each(?) a subclass of organization (Q43229)
member of the deme	Property:P2462	208	human	(none given in property)
gens	Property:P5025	9,021	human and others	gens (Q899409) (subclass of clan, subclass of family)
member of political coalition	Property:P5832	233	political party and others	political coalition (Q6138528) - a subclass of organization (Q43229)
member of military unit	Property:P7779	10,328	human, fictional human	military unit (Q176799) (a subclass of organization (Q43229)) and others
member of Roman tribe	Property:P11491	113	human and others	tribus (Q938560) (a subclass of organization (Q43229)) and others
member of musical group	-proposed-	(100000+)	human	musical group (Q215380)

Table added TangoAF (talk) 08:17, 4 August 2026 (UTC); Usage main statement added, for the proposal estimated using https://qlever.dev/wikidata/JbXFz5 TangoAF (talk) 09:42, 4 August 2026 (UTC); Estimate for usage increased to 100000+, cf. https://qlever.dev/wikidata/ITVwUz - instances of musical group - 99663 lines found. TangoAF (talk) 12:18, 4 August 2026 (UTC); add rows for: 1) member of the deme / Property:P2462 and 2) member of Roman tribe / Property:P11491 TangoAF (talk) 10:18, 5 August 2026 (UTC); add row for member of ethnic group / Property:P172 TangoAF (talk) 13:36, 5 August 2026 (UTC)

Discussion

WikiProject Music has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. and ping recent contributors to the discussion at the WikiProject Musik talk page : @Moebeus, Amadalvarez: TangoAF (talk) 09:44, 31 July 2026 (UTC)

---

1. Support. TangoAF (talk) 09:44, 31 July 2026 (UTC)

   Note: The above vote was from the property proposer. Yirba (talk) 12:16, 31 July 2026 (UTC)

•  Initial oppose I see no reason to have a separate property. member of (P463) does the job fine. Sure, we have P54 and P102, but they were created before P463, and I'm not sure that their existence is a good reason for creating this property. member of cabinet (P5054) is a qualifier only, so serves a different purpose.member of the crew of (P5096) is also different in that it's connecting a person to a vehicle or flight. I don't see what problem the proposed property will solve. -- Yirba (talk) 12:37, 31 July 2026 (UTC)

  So, the cabinet and crew properties are only a subproperty of memberOf according to the settings in the property's WD page, not according to the meaning of "subproperty", contradicting the definition in the WD property page for subproperty.

  Regarding: "I see no reason to have a separate property." - What can be done about that and why does that matter?

  Regarding: "member of (P463) does the job fine." - could it be that the reasons for keeping subproperties for sports and politics could be reasons for creating a subproperty for music?

  TangoAF (talk) 13:35, 31 July 2026 (UTC)

  Yes, it could be that they're not strictly speaking subproperties of member of (P463). Property proposals need to have a rationale, otherwise there would be numerous duplicate properties and lack of clarity of the purpose of each property. The point of a property is so that it can be used on items. If there's no reason for a property to be used on an item, why create it?

  So far, the only rationale you've provided is that some other properties already exist. But you haven't explained why the proposed property should be created or what problem it will solve. What can be done is you can update the motivation to explain why the property is needed. Or we can close this proposal if there's no reason to create this property. Yirba (talk) 13:48, 31 July 2026 (UTC)

  Linked P1647 https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/member_of_musical_group&diff=prev&oldid=2525191380 - anything else needed? TangoAF (talk) 13:56, 31 July 2026 (UTC)

  The proposal still needs to explain why this property should exist in addition to member of (P463).

  What use case cannot be adequately modelled with P463? What concrete problem would this property solve? For example, would it enable queries, constraints, or data validation that are not reasonably possible with P463?

  Simply pointing to existing subproperties isn't, by itself, a rationale, since those properties have their own histories and purposes. The proposal should explain why musical groups warrant a dedicated membership property rather than using the existing general one. Yirba (talk) 14:14, 31 July 2026 (UTC)

  "What use case cannot be adequately modelled with" any superproperty of any subproperty? TangoAF (talk) 14:34, 31 July 2026 (UTC)

  @TangoAF: For example, illustrator (P110) is a subproperty of creator (P170). We have statements like Matilda (Q1426188)illustrator (P110)Quentin Blake (Q453980). Although it may be technically true to say that Quentin Blake is a creator of Matilda, it's important to note the specific role he played in the work's creation (to avoid confusion with the author, for example). Therefore, creator (P170) is not adequate for describing that relationship and illustrator (P110) is needed to convey that additional information. But I don't see what additional information the statement "John Lennon was a member of the the musical group the Beatles" provides over "John Lennon was a member of the Beatles" except for the fact that the Beatles were a musical group -- a fact that can already be discerned from the fact that the Beatles is an instance of musical group. Yirba (talk) 16:52, 31 July 2026 (UTC)

  So, to reveal the role there should be:

  1. singing member of musical group / singing member of
  2. guitar playing member of musical group / ...
  3. piano playing member of musical group / ...
  4. ... any other type of role ...

  TangoAF (talk) 13:23, 1 August 2026 (UTC)

  That would at least convey more information, but given the absurdly huge number of instruments out there, I reckon it would be better to use a qualifier such as subject has role (P2868)guitarist (Q855091) or instrument (P1303)guitar (Q6607). Yirba (talk) 13:54, 1 August 2026 (UTC)

  "instrument" doesn't convey a role, and fails for conductor/director. On the other hand there are already occupation (P106) and position held (P39) each of them having scope main value and qualifier. Is there somewhere an overview of how all these are used? Usage seems at least to depend on availability of items, e.g. the above mentioned crews don't have an item, while the musical groups have, and the position guitarist of group A doesn't have an item, while president of country B has. A person can also have several positions in a musical group, at the same time or in consecutive time frames, but it seems qualifiers cannot have qualifiers, so for each position/occupation a new main statement could be required. TangoAF (talk) 13:48, 2 August 2026 (UTC)

  Those seem like modelling questions about representing a person's role within a musical group, and I agree they are worth discussing. However, I don't see how the proposed property addresses them. It would still only express membership, not whether someone was a vocalist, guitarist, conductor, etc., nor how those roles changed over time. So I'm still unclear what problem this particular property is intended to solve that member of (P463) does not. Yirba (talk) 17:20, 2 August 2026 (UTC)

  It is common practice to create subproperties of memberOf, you failed to explain or didn't intend to explain, why member of musical group would be an exception for which no subproperty would be created. TangoAF (talk) 08:23, 4 August 2026 (UTC)

  I've already explained my reason extensively. At any rate, the onus is not on me to justify why this property shouldn't be created. The onus is on the property proposer to justify why it should be created. Yirba (talk) 09:53, 4 August 2026 (UTC)

  Extensively doesn't imply sufficiently. Re "At any rate, the onus is not on me to justify why this property shouldn't be created." - But you voiced against its creation, without any substantiation.

  "The onus is on the property proposer to justify why it should be created." - Can you show where this is laid out? TangoAF (talk) 12:14, 4 August 2026 (UTC)

  The process is described at Wikidata:Property creation. Proposals must receive consensus in favour of creation for the property to be created. If this proposal doesn't receive such consensus, the property will not be created. Yirba (talk) 12:25, 4 August 2026 (UTC)

  There is a consensus in favor. There might also be a consensus against, but why would those being against not have "the onus [...] to justify why this property shouldn't be created"? TangoAF (talk) 10:21, 5 August 2026 (UTC)

  A single vote from the proposer is not consensus. Please refer to Wikidata:Property creation. Yirba (talk) 11:31, 5 August 2026 (UTC)

  A single vote from an opposer is? TangoAF (talk) 13:37, 5 August 2026 (UTC)

  No. Yirba (talk) 13:50, 5 August 2026 (UTC)

  Then, a single vote from whom is consensus? TangoAF (talk) 13:57, 5 August 2026 (UTC)

  Please refer to the property creation criteria at Wikidata:Property creation. Yirba (talk) 14:08, 5 August 2026 (UTC)

  The term "single vote" doesn't appear there. So, what is your source? TangoAF (talk) 14:23, 5 August 2026 (UTC)

  "The proposal was made by somebody other than the property creator." Even if you had the right to create properties, you may not create a property that you yourself proposed. Therefore, a property requires multiple people to support the proposal for it to be created. Yirba (talk) 15:42, 5 August 2026 (UTC)

  I also  Strong oppose for the same reason. People are too ready to propose new properties for classes of object where a more general property is fine. "Member of" could have so many variants, we don't need to encode them all. Vicarage (talk) 07:30, 4 August 2026 (UTC)

  It is common practice to create subproperties of memberOf, you failed to explain or didn't intend to explain, why member of musical group would be an exception for which no subproperty would be created. TangoAF (talk) 08:23, 4 August 2026 (UTC)

  Simply, we don't need any more subproperties, adding to the already too long list you quote Vicarage (talk) 08:27, 4 August 2026 (UTC)

  "Simply, we don't need" is not an explanation. TangoAF (talk) 08:36, 4 August 2026 (UTC)

  Can you quantify how many uses of member of (P463) would need to be changed, how many WP templates, how many downstream users would need to re-write there queries. Your proposal would cause a wave of disruption to no benefit. Vicarage (talk) 08:42, 4 August 2026 (UTC)

  Now you come up with additional claims, and rephrase "Simply, we don't need" into "to no benefit" - this act didn't change the status "isn't an explanation". TangoAF (talk) 09:15, 4 August 2026 (UTC)

  https://qlever.dev/wikidata/JbXFz5 - 56992 lines found. TangoAF (talk) 09:32, 4 August 2026 (UTC)

•  Comment I was on the verge of opposing this property too, because the proposer failed to give a good reason for its creation (in my eyes, some other subproperties for membership may also be insufficiently motivated, even if they got created). However, @Amadalvarez provides a potential reason in this comment on the talk page linked in the property motivation. I interpret its essence as follows: Many musicians use member of (P463) with values that aren't musical groups. So, for reusing the data, e.g. in infoboxes, it is easier to access a dedicated property for musical group membership, than to access general membership filtered on musicians as subjects and musical groups as values. I don't know whether this reason is sufficient, but at least now there's an argument to discuss. --Volvox (talk) 12:36, 4 August 2026 (UTC)

  This is a much better argument for creating the property than what has previously been provided in this discussion. That said, I'm still not convinced. I understand the hypothetical scenario, but I wonder if there are real use cases where you'd have an infobox that should only list musical groups or only list musicians. Even if there are, if it's an infobox about a musician, then you only need to filter for musical groups. If it's an infobox about a musical group, you only need to filter for musicians. I don't think there would be a need to filter at both ends at the same time. And would it mean that we'd need to create separate properties for every subclass of group of humans (Q16334295)? I suggest we keep things simple and stick to the property we already have. Yirba (talk) 13:11, 4 August 2026 (UTC)

  This is why we don't want to extend the mess for someone who's a member of a combination of band, political party, learned society, etc. who once served in the army etc. Some areas you'd use a particular property, others you'd do a member of (P463)/instance of (P31)/subclass of (P279) filter. Few people would know all the possible properties, but they'd know if they wanted a general list of involvements or a particular field. We are in danger of considering musicians of only practising music, not the other arts. I think the downstream users can better decide on member of (P463) filtering than maintaining property lists. Vicarage (talk) 13:14, 4 August 2026 (UTC)

  There are many possible sub-properties that differ only in argument constraints on the subject or object. I can see that the sub-property (if properly populated) might make it easier to design infoboxes, but we need to balance that against the fact that editors already struggle to find the right property and adding more will make this worse. Bovlb (talk) 13:40, 4 August 2026 (UTC)

  Re "that differ only in argument constraints on the subject or object" - this one would differ on subject and object constraints. TangoAF (talk) 10:34, 5 August 2026 (UTC)

  This counterargument seems reasonable enough for me to vote  Oppose --Volvox (talk) 13:59, 4 August 2026 (UTC)

  Which counterargument? TangoAF (talk) 10:34, 5 August 2026 (UTC)

•  Comment Heads-up that there's now a discussion over at Wikidata:Project chat#Subproperty of member of - member of musical group. -- Yirba (talk) 13:55, 4 August 2026 (UTC)
•  Oppose per Yirba and Vicarage. The infobox coding argument is not, to me, sufficient justification for a new property, to say nothing of the proposer's worthless "similar properties exist" argument. I would usually seek a gentler synonym for "worthless", but the proposer's combative approach in light of their misunderstanding of process really rubs me the wrong way. Swpb (talk) 14:57, 4 August 2026 (UTC)

  Deceptive comment; the string "similar properties exist" appears for the first time on that page, even the word "similar" hasn't been used on that page before. TangoAF (talk) 10:31, 5 August 2026 (UTC)

•  Neutral I don't have a strong opinion, but while I see its value for infoboxes, I'm concerned this could set a precedent for creating too many specialized subproperties of member of (P463) -- JhowieNitnek (talk) 06:25, 5 August 2026 (UTC)

  What do you mean by "precedent", given that at least 11 subproperties already exist? Why should music be treated differently? How would you define "too many specialized subproperties of member of (P463)", especially given the fact that memberOf has usage as main statement = 714,079 and the proposed one would have main statement usage 50000+ based on current usage and several thousands more over time. TangoAF (talk) 10:26, 5 August 2026 (UTC)

  Like I said I don't have a strong opinion as I can see the value so you don't need to convince me I am neutral JhowieNitnek (talk) 18:09, 13 August 2026 (UTC)

•  Support Since membership of a musical group is semantically different to membership of an organization; properties should be "as specific as possible" An alternative would be a new property band member which would be stored on the musical group in a similar way to cast member (P161) Piecesofuk (talk) 07:59, 6 August 2026 (UTC)

  Regarding the inverse: See Wikidata:Property proposal/has Member - before creating a new subproperty of hasMember, it might be good to create hasMember first. hasMember is even found in RO (http://purl.obolibrary.org/obo/RO_0002351), for which an external ID property exists (Relations Ontology ID (Property:P3590)).

  Regarding specificity: one could create "personal member of" to be used on human items, and "organizational member of" to be used on organization items. So, one would have two main subproperties of "member of". That would already bring several benefits of the proposed "member of musical group". TangoAF (talk) 10:37, 8 August 2026 (UTC)

•  Comment copy from Property_talk:P527#Band_members_in_timelines:_allow_qualifiers_"instrument"_and_"pseudonym": "Although I generally dislike inverse properties, I would support creating a dedicated inverse property for band members here because people are already creating inverse statements and a dedicated property would allow us to have better constraints. - Nikki (talk) 17:51, 20 October 2018 (UTC)" -- @Nikki: FYI. TangoAF (talk) 10:15, 8 August 2026 (UTC)
• @Amadalvarez, Bovlb, JhowieNitnek, Yirba: Would you like to give your final opinion based on the response? -- Regards, ZI Jony ^(Talk) 17:22, 13 August 2026 (UTC)

  Thanks. Given how the proposal ended up going, I downgrade my vote to a  Strong oppose. --Yirba (talk) 18:16, 13 August 2026 (UTC)

   Oppose by the given arguments. Thanks ! Amadalvarez (talk) 06:33, 14 August 2026 (UTC)

•  Not done, @Amadalvarez, Bovlb, JhowieNitnek, Piecesofuk, Swpb, TangoAF: @Vicarage, Volvox, Yirba: No consensus of proposed property at this time based on the above discussion. -- Regards, ZI Jony ^(Talk) 07:39, 14 August 2026 (UTC)
• It seems the discussion is deemed to be over now but Imho I think this is a property that should exist.StarTrekker (talk) 05:06, 20 August 2026 (UTC)