Wikidata talk:WikiProject Music

From Wikidata
Jump to navigation Jump to search

New property proposal: "m3db.com lyrics ID"[edit]

Hi everyone, I have submitted a new proposal for the inclusion of lyrics from Malayalam films and album songs, which can be found at Malayalam Movie & Music DataBase.- ❙❚❚❙❙ GnOeee ❚❙❚❙❙ ✉ 09:16, 24 November 2023 (UTC)[reply]

Pre-proposal: More in-depth ISRC model[edit]

I was thinking of making additional items and proposing additional properties for International Standard Recording Code (Q1148336)/ISRC (P1243), primarily one for the two-letter “country” code (which mostly lines up with ISO 3166-1 alpha-2 code (Q1140221)s, but not entirely) and also a Q+P set for ISRC Managers’ Registrant/Prefix codes.

For the latter, I’m not sure whether these should be 3 or 5 character ones. E.g., Gramex (Q12314192) will tell you that your Registrant Code (“producentkode”) is "XXX" but that any ISRCs you delegate should be in the format of DKXXXAABBBBB – ie., with the country code prepended to your Registrant Code.[1] IFPI Sverige (Q28000675) on the other hand will tell you that your Registrant Code (“bolagskod”) is "SEXXX" .[2] International Federation of the Phonographic Industry (Q826858) only talks about “Prefix Codes” and “Registrant Codes” but doesn’t really differentiate the two or indicate whether they consider there to be any difference between the two terms that I can find.[3][4][5] Maybe ISO 3901:2019 (Q124249287) details this relationship more, but I’m not about to pay for access to it and I’m not going to go out of my way (right now) to hunt down a liberated version of it, but I may put in more work to acquire a copy later.

Would anyone be opposed to either of these Q+P pairs before I spend more time researching and start making the items and requesting properties?

—Freso (talk) 00:34, 11 January 2024 (UTC) Freso (talk) 00:34, 11 January 2024 (UTC)[reply]

Support start with the country codes. Registrant seems to be three-letter, but depends on the country-code that has been used (e.g. USA uses US and QM, because the registrant codes where exhausted [so says en WP, no idea if that is true.]) So, the country code should go into a qualifier statement, probably using the country code property, which means that must exist when storing the registrant codes into the registrant property. CV213 (talk) 22:03, 17 February 2024 (UTC)[reply]

Can I upload these Sakha-Yakutia folk music files using metadata files?[edit]

Hi all, the SOAS University of London published this series of Sakha shaman music recordings licensed under CC BY-NC-ND. There're 8 tracks in total and covers a variety of vocal styles/techniques of the Sakha. Individual tracks are made downloadable in the this SOAS digital collection. I think it'd be nice to upload them to wikidata, but I'm quite new here and still figuring thinks out. So for each of their listings they also provide a corresponding METS/MODS metadata file and a converted MARC XML file. I wonder if I can upload audio files using their associated metadata files?

To be more specific, for example, this resource has downloads to all 8 tracks in different audio formats. If you go to the description > metadata tag, you can also find links to its METS and MARC metadata files. I suppose these metadata are written in some agreed-upon controlled vocabulary, so I'm wondering if wikidata will be able to extract the list of downloads from either of the metadata file above?

Thank you.

Arachnikhan (talk) 20:27, 29 January 2024 (UTC)[reply]

Unify partOf and memberOf under memberOf[edit]

The current setting is problematic:

  1. Wikidata:WikiProject Music#Person properties
    1. part of || P361 || Item || part (piece): object of which the subject is a part (if this subject is already part of object A which is a part of object B, then please only make the subject part of object A), inverse property of "has part" (P527, see also "has parts of the class" (P2670)) || Richard Rodgers <part of> Rodgers and Hammerstein || has part(s)
    2. member of || P463 || Item || member and group member: organization, club or musical group to which the subject belongs. Do not use for membership in ethnic or social groups, nor for holding a political position, such as a member of parliament (use P39 for that) || John Lennon <member of> The Beatles
  2. Wikidata:WikiProject Music#Group properties
    1. has part(s) || P527 || Item || has part, consist of and meronymy: part of this subject; inverse property of "part of" (P361). See also "has parts of the class" (P2670). || The Beatles <has part(s)> Paul McCartney || part of

The groups fall under music organization (Q32178211). Organizations don't cease to exist just because a "part" leaves. Maybe it is true for fixed member groups of humans (e. g. musical duo), but then are these organizations? It looks like cleaner modelling would be to use memberOf. Some "musical groups" are commonly called "band", the band has member not parts, the members can change.

Also partOf is defined as inverse of hasParts. It is done that way for musical duos, but not for larger orchestras that exist longer than humans can live. It consumes more storage space to state the same thing twice. memberOf doesn't seem to have an inverse.

In the examples Lennon is memberOf Beatles, but Beatles hasPart McCartney.

It would be much easier and ensure consistency to just use memberOf all the time, as is done commonly in Wikidata for humans that are "member_parts" of organizations. CV213 (talk) 15:16, 5 February 2024 (UTC)[reply]

Q58125755 several claims partOf and several claims memberOf, sometimes or each time with same object. CV213 (talk) 17:59, 6 February 2024 (UTC)[reply]

@Meisam: you seem to work on music, what do you think about moving all partOf to memberOf for musical groups, so that there is only one way of stating the same fact? CV213 (talk) 23:11, 15 February 2024 (UTC)[reply]

I see the problem. IMO, "The Beatles <has part(s)> Paul McCartney" is wrong and most of the <part of> properties should be replaced by <member of>. Even a musical duo like Boy has no parts. But "Grethe and Jørgen Ingmann <has part(s)> Grethe Ingmann" and "Grethe Ingmann <part of> Grethe and Jørgen Ingmann". You cannot swap-out a "part" and keep the name/identity. -- Meisam (talk) 23:41, 15 February 2024 (UTC)[reply]
The Grethe and Jørgen Ingmann (Q241520) currently is instance of musical duo and married couple. But that is wrong. The existence of the married couple "Grethe and Jørgen Ingmann" has nothing to do with the existence of the musical group "Grethe and Jørgen Ingmann". Regarding the name - probably modelling should not depend on the name - maybe Grethe finds another Jørgen or Jørgen another Grethe and they continue the "group". If a musical duo (Q9212979) is only two humans, then it shouldn't be a subclass of music organization (Q32178211), which it currently is.
For humans it isn't said instanceOf singer, so why for a group of two humans there is instanceOf musical duo? It should be hasRole/hasOccupation musical duo. CV213 (talk) 23:53, 15 February 2024 (UTC)[reply]

@Moebeus, Amadalvarez: just found Wikidata_talk:WikiProject_Music/2022_review_proposal#Re:_band_members - can this be finally done? It causes a lot of problems when checking human items for correctness, because humans are not partOf organizations but memberOf them. CV213 (talk) 15:34, 19 February 2024 (UTC)[reply]

VI.BE platform ID[edit]

Please see here. Sjoerd de Bruin (talk) 18:47, 10 February 2024 (UTC)[reply]

ISWC format[edit]

It has been proposed to change the format of ISWC (P1827). Comments welcome: Property talk:P1827#ISWC format. --Epìdosis 15:37, 16 February 2024 (UTC)[reply]

Omit catalog prefix in P528 (catalog code)[edit]

Hi, all,

I recently read over an old property chat discussion regarding P528 (catalog code) after noticing how inconsistently values in P528 are applied to musical works. For example, when browsing Mozart's works, you can find many variations in how editors have entered codes: K.###, K###, K ###, KV###, ###, etc.

I will repeat my thoughts from the property chat here: Structured data in Wikidata should be language agnostic. Because abbreviations for certain catalog numbers (such as the Köchel catalog) are different depending on the language (German: KV, English: K), I would argue that the prefix should be omitted from P528. As others have stated (in the property chat), it is also redundant if the qualifier P972 (catalog) is used correctly.

Please chime in if you have thoughts on this. The variety of approaches to using P528 make it difficult to query a specific catalog number. Thanks! Fuchsiaflute (talk) 17:56, 15 May 2024 (UTC)[reply]

Catalog codes are exported to infoboxes in wikipedias and prefixes are important to be filled in, otherwise it will be displayed there as just a list of numbers (some works have 3+ numbers from different catalogues). And in sources these codes are mostly specified with a letter prefix, rather than without it. In the case you described - the correct approach is to choose and stick to a single approach for each catalog where several designations are used. Solidest (talk) 19:41, 15 May 2024 (UTC)[reply]
When an infobox sees Eine kleine Nachtmusik (Q12025)catalog code (P528)525catalog (P972)Köchel catalogue (Q162478) and sees Köchel catalogue (Q162478)short name (P1813)K. (English), it should be able to display K. 525. It’s just a matter of some lines of Lua code someone needs to write. (I know, this is the theory, and the practice may be that there is nobody who’s able and willing to write those lines of Lua code.) —Tacsipacsi (talk) 00:00, 16 May 2024 (UTC)[reply]
Thank you both for the input! I now understand the current issue Solidest described with the infoboxes (thanks for pointing that out!). However, I would still argue that the prefix is not a part of the code, but rather a separate designation of what catalog is being referenced. That's partially why there is a separate property for the catalog (P972).
I realize the example I'm about to use is a bit of a stretch, but if you look at the tables in the Wikipedia entry Köchel catalogue, each code is listed only by its number because the prefix is already implied by the label in that column. It's done the same way in tables in Grove. If P972 is properly applied as a qualifier, the data is already there stating the prefix should be "K" or "K6" (albeit via a few intermediary statements that Tacsipacsi described).
As they also implied in their message, it is a separate issue that the metadata not being used to its full potential in the infoboxes. I understand leaving out prefixes now would not solve that issue, but I think it would make the data cleaner both for querying and for implementing in (hopefully more thought-out) infoboxes in the future. Fuchsiaflute (talk) 13:41, 16 May 2024 (UTC)[reply]
  1. ↑ https://gramex.dk/jeg-udgiver-musik/isrc/isrc-kodens-opbygning/
  2. ↑ https://www.ifpi.se/musikbolag/isrc/
  3. ↑ https://isrc.ifpi.org/en/isrc-standard/structure
  4. ↑ https://isrc.ifpi.org/en/get-isrc
  5. ↑ https://isrc.ifpi.org/en/isrc-standard/national-agencies
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata_talk:WikiProject_Music&oldid=2155992631"