Topic on User talk:Nvrandow

This is rather annoying, because adding part of (P361) is fine for most music release items because they're not formalized into the MusicBrainz-style entity structure; but for the 100 or so items which are split up I have to revert the same edits from Harvest Templates every time. I don't really think there's a good solution which doesn't involve breaking something for either group of items.

@Moebeus: do you think there's a constraint violation which could be added temporarily to part of (P361) to prevent this?

This is tricky indeed, because a composition can be "part of" larger works, like a musical or song cycle. Would it be possible to say that a composition can only be part of another composition/musical work, and not be part of a release, perhaps? Or are you only talking about releases being part of other releases? I'm afraid I might be missing the start of this conversation :(

I think the easiest solution would be to change the convention to always using published in (P1433) for albums (somehow), get everyone using Harvest Templates to use published in (P1433) instead of part of (P361) (again, somehow), and then add a constraint violation based on ISWC or MusicBrainz work ID.

You're not missing the start of the conversation. Nvrandow just (probably) hasn't noticed that I've reverted a hundred of their edits yet, and their batch only finished three minutes ago. (You might need to check your watchlist as well.)

Should I revert my edits?

I've gone through most of the problematic ones for now.

I tried reverting the whole batch for another user's Harvest Templates import, and ended up having to self-revert on about half of the items.

It can be reasonably assumed that most of the "fixed" items have been edited by either Moebeus or myself (pretty much no one else bothers right now, even though there has been some consensus for using a structure somewhat like or exactly like MusicBrainz's), so if he checks all of your recent edits that have shown up on his watchlist then it should be fine.

It took a minute but I'm finally done going through the list, should be okay now.

The best way to change uses of P361 to P1433 is probably somewhere in Wikidata:Tools/For programmers, although I've never used any of them before. I think as long as there's a short project chat discussion it shouldn't be anywhere near problematic.

Changing to P1433 would also require fixing calls in a few existing Wikidata infoboxes, although this would just be changing the number.

Could we perhaps use Property:P5008 and make a corresponding "Music Clean-Up Project 2019" or something?

I don't know if that would have much of an effect. Also, using it to prevent imports would require a complex constraint violation, which Harvest Templates might not be able to handle or recognize.

The right tool for this is probably https://tools.wmflabs.org/quickstatements/#/batch.

The syntax is for example:

-Q1<tab>P361<tab>Q2

Q1<tab>P1433<tab>Q2

I don't want to do this, because it would cause statements to lose qualifiers, ranks and references.

I've posted at Wikidata:Project chat#Converting P361 uses to P1433.