Topic on User talk:Jc86035

Something similar to tracklist, but for compositions of course.

• It's a concept/term that is in wide use on (English) wikipedia.

• It would function as a reverse property of Property:P2550 "recording or performance of"

• it would allow linking a musical work straight to a music track without having to go through our current, slightly ad-hoc method of Performer>statement is subject of.
• For the sake of readability properties like "performer" and "publication date" could be optional

Thoughts?

Maybe not. I think it's unlikely that any more inverse properties will be approved, regardless of topic.

Sorry if I'm harping on about this, but could Property:P1811 be used as an argument for "list of recordings" maybe?

I think you could, although discography (P358) might make more sense in this context.

huh. Maybe I'm reading that wrong, but I can't see any reason given why inverse properties are bad practise, other than the commenter not liking it?

I realize of course that inverse properties aren't technically necessary, but that ignores the fact that people will keep adding properties they can't actually read/see on the item itself. So from a UX perspective I think they absolutely serve a purpose.

P.S. "There's a piece of user-written javascript you can use to automatically see properties on an item from the reverse direction" - do you know what userscript he refers to here, it's not the "What links here"-link is it?

I think the user script is Wikidata:Tools/Enhance user interface#derived statements. It appears to be somewhat useful, although it doesn't show qualifiers or references.

I think the necessity of the inverse property primarily depends on whether the MusicBrainz review/import is completed before or after inverse property querying is enabled in MediaWiki. (Given that m:Community Wishlist Survey 2019/Wikidata/Automatically add inverse properties was doing surprisingly well until it was pointed out that the specific method of the proposal (adding all the inverses) was much more problematic than just allowing inverse database queries, I would expect a similar proposal based on querying to do well in the November 2019 survey, so I'm guessing that the implementation would be between about 15 and 24 months from now.)

Anyway, regarding ArthurPSmith's comments, DeltaBot recently added about 1,100 child astronomical body (P398) inverse statements to Sun (Q525). If I were to propose the property then I would emphasize the argument that it's stupid to allow some functional inverses but not others (though the utility of an inverse recording property would probably be higher than that of an inverse modified version property).

Finally, regarding the quality of MusicBrainz, I'm currently in the process of archiving a very large amount of Spotify albums to the Internet Archive, and extracting the ISRCs from tatsumo.pythonanywhere.com. Having a complete static database of several million ISRCs, connected to Spotify identifiers, it would probably become at least a little easier to fill out the gaps in MusicBrainz's data.

Holy Moses, that's awesome! I don't know how you find the time to do all this stuff I'm well impressed 👏👏👏

Me neither, to be honest. I said I was going to take a break soon. (Fortunately for me the archival work is largely automatic.)

I selfishly hope your break won't last very long, but you certainly deserve it ;)