Please see for example, Q65705957#P39
I get a constraint about http://archive.fo/gJYiw
Please see for example, Q65705957#P39
I get a constraint about http://archive.fo/gJYiw
I deliberately set the constraint so that only HTTPS links would be considered valid wherever possible (since there's basically no reason for us not to link to the HTTPS versions of the sites instead of the HTTP versions). Partly also why it's only a suggestion constraint right now. The rest of the URL is fine and should be accepted.
It's better to have a bot change all HTTP to HTTPS first and then add the constraint. I get many references expanded now because of the constraint. It difficult for me to contribute now. And it's not my fault, I am not doing something wrong... So please or leave the constraint or with a bot make the needed changes.
I've changed the constraint to accept HTTP links.
I've been working on an interesting case (from a WD standpoint, not musically ;-) ), the song 19 by Paul Hardcastle. This became a massive hit in 1985, and was in large part based on samples of dialogue from the documentary film Vietnam Requiem. As a result the director and screenwriter of that film were awarded CA (composer/Author) credits by an American court. To add insult to injury, Mike Oldfield then claimed the song plagiarized parts of his original composition Tubular Bells, Pt. 1 and again Hardcastle lost out.
In order to model this I have created legal credit and sample credit, but it still feels a little wonky and I'm not quite sure what should go where. What I'm looking for is someone to critique it, do you have the time?
I'm not sure. object has role (P3831) could be a safer route than nature of statement (P5102) here, but what you're doing might make more sense. I might expand this in some way so that it would be possible to indicate things like "unofficial", "in name only" and "legally required" for any given statement (independent of the indication that the statement is because of sampling), but I don't know how that would be done.
There's also Property:P1773 (attributed to), but what I'm focused on here are the "official" attributions as found in ASCAP, BMI, ISWC-Net, etc. Anyways, thx for having a look!
I just read about shape expressions coming to WD and it got me super excited. I would very much like Project:Music to get in front of this - we have some well understood, tried and tested models ready to be deployed as schemas and their not not all that complicated so should be ideal as one figures out the technology. Would you be at all interested in working together to shape some initial schemas?
I know you're busy/overworked and music is not your only area of interest, so completely understand if you're not feeling it. That said, I believe this could be interesting exercise and a lot of fun!
have a great day,
I can't say I would be able to contribute, but I would support efforts in this vein.
Something similar to tracklist, but for compositions of course.
Maybe not. I think it's unlikely that any more inverse properties will be approved, regardless of topic.
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.
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 ;)
You added a conflicts statement between MusicBrainz work ID (P435) and MusicBrainz release group ID (P436) in https://www.wikidata.org/w/index.php?title=Property:P435&diff=772715575&oldid=755172086&diffmode=source. Was that intentional? According to https://www.wikidata.org/w/index.php?title=Property_talk:P435&diff=215225728&oldid=212698347&diffmode=source, both of those properties were not meant to conflict.
My decision was intentional, yes. The 2015 omission was also a presumably unilateral decision, by Nikki, and this was several years before Moebeus (and I) began separating singles into items which would be one-to-one matches with MusicBrainz entities. All Wikidata users, including unregistered users, can add or remove property constraints.
While Wikidata may not in practice distinguish songs from singles (except when noting covers of a song), it is probably beneficial nevertheless to have different Wikidata items for the distinct entities. (See also the deletion discussion for B-side (DEPRECATED) (P1432).) Unfortunately, the data is terribly inconsistent at the moment, because there are more than 80,000 items for singles, and so far all of the several hundred separations have been done manually. In the meantime, data reusers will have to deal with it or use other databases.
@Mineo There is another issue with your bot: It updates WD not only based on WD links on MusicBrainz, but also based on wikipedia-links. This breaks a lot of stuff, and I think your updates should be limited to WD-item<>MB item. The reason for this is that Wikipedia articles will often cover several subjects (song, cover versions, releases) and MusicBrainz editors will link wikipedia articles to display relevant text on their items, which is fine. The problem comes when these links are imported back into Wikidata, like what happened here: Q7428899 - in this example two versions of the same song are correctly tagged with WD items, but the wikipedia article (which covers both versions) causes problems. Could you have a look at your script?
This is a known issue. I believe the answer is that because Wikidata has functional constraints and querying infrastructure and MusicBrainz does not, the error-fixing should occur on our end and the same fixes should then occur on MusicBrainz.
Just to clarify this for me: is MusicBrainz work ID (P435) on items with instance of (P31) single (Q134556) now officially wrong? Since it seems the constraint process doesn't require any approvals or reviews, I'm not sure how to interpret the current situation. If that's the case, I'll just prevent the bot from adding any MusicBrainz work ID (P435) statements in the future.
Would it be possible to check if an MB Release/MB Release group ID is already present on the item before adding a MB Work ID? Personally I think the biggest problem is items with more than one/conflicting MB IDs, but that's just my opinion.
If you go to a random category like w:en:Category:1988 singles and check the Wikidata items, you'll find that basically all the data was imported from the English Wikipedia infoboxes in 2012 and 2013. I don't think a lot of those are linked to MusicBrainz at all.
I think adding them will still be beneficial, since (depending on your point of view) the item represents the recording and composition as well as the single, since all of the English Wikipedia articles are supposed to have the song as the primary topic unless the single has more than one track (I think?). (The data is already polluted, in any case, so MineoBot won't be breaking anything that wasn't already broken.) I don't think there's anything official, and there are few active contributors in this area, but for now I think adding it should be okay until someone comes around to clean up all of the items.
According to https://www.wikidata.org/wiki/Property_talk:P435, the domain of MusicBrainz work ID (P435) are indeed single (Q134556)s. It would be super awesome if you could create a consistent view for this property, @Jc86035, because at the moment, the property page and its documentation are clearly in conflict.
The template parameter was added by Laddo in 2014, which was shortly after the Dexbot import in 2013. At the time this would have been accurate, and at the time property documentation was always stored in the template on the property talk pages instead of being indicated in the Property namespace. I didn't even notice that text until you mentioned it.
I've removed the template parameters on the talk page, since they are redundant to and/or contradict the information stated in the property entity itself. Everything here was done unilaterally (I think), and a revert and a discussion should be enough to establish consensus.
As always. I think Wikidata right now is a bit like an emptier 2006 Wikipedia (no references, everything is a bit messy). I wasn't there in 2006, but Wikidata's about the same age as Wikipedia was in 2006.
I think this comment I made yesterday might be relevant. Essentially, there are 80,000 to 500,000 items to fix (across music and books), and I don't really know how that would be done because I haven't learned how to run a Wikidata bot and don't know if it would be possible for me to do it.
Just saw this linked on the project chat: Talk:Q14211, never seen that done before. Wouldn't that be a great way to list cover versions without cluttering up the Item with the "performer/statement is subject of" model? Haven't really thought it through or anything, do you see any immediate drawbacks implementing something like this?
In the short term, I think the template itself could be beneficial, although bot code had to be written for it and I don't know if anyone will want to do that. Item talk pages are still mostly a barren wasteland.
On the other hand, removing the statements would probably have some knock-on effects. Since it would currently prevent infoboxes from using the related data, it does depend on whether it's likely that inverse statement access (phab:T209559) will be implemented before Wikidata infoboxes gain steam. (It's likely that inverse statement access could get top 10 in the community wishlist survey (see task comments), which would effectively put its deployment around late 2020; and I don't see Wikidata infoboxes gaining steam at all in the big (i.e. relevant) Wikipedias until there's a consistent level of adequate referencing, which would probably take several years even with supporting efforts like GlobalFactSync.) It's impossible for us to know one way or the other.
Anyway. You already have User:Pasleim/derivedstatements.js installed, so you can already easily check whether there are any inverse statements and go from there. I probably wouldn't rely on waiting for any of the aforementioned things to be resolved.
"I'm not totally sure how the ontology works here, but using musical work (Q2188189) breaks some identifier constraints, and it's sort of strange to imply that somehow this isn't a composition"
What constraints are broken? I've noticed there has been a bit of activity with edits and reverts on musical work and musical composition. In theory, they should be almost synonymous but that might have changed recently. Any item with an ISWC-identifier is, per definition, a musical work?
I noticed it with Discogs composition ID (P6080) but didn't check the others. musical composition (Q207628) is currently a subclass of musical work (Q2188189), so no information is lost through use of the former.
There's no English Wikipedia article for musical work (Q2188189). The German Wikipedia article states that "Musikalisches Werk" encompasses both compositions and collections of such compositions (such as albums). The second paragraph essentially states that any work containing music is also considered a musical work, including those that also include sound or imagery (e.g. an album).
I'll look into that constraint later, that definitely shouldn't be triggered.
I don't mind using musical composition (rather than work) or in any way think it's wrong, my main thing is that just using "song" is not enough as long as song and single are so intertwined.
For the first query, those are indeed the only metro stations in Tsuen Wan District (Q878514). All of the adjacent stations are in other districts. I tried changing the query to use MTR station code (P1377) (which is definitely used on all MTR stations) and that worked a bit better, although I haven't read through the whole query so I don't really know how it works.
Do you have any ideas how to best model mashups?
Have a look at this if you have time, I can't get seem to get it right: Q7459782
Yeah, I've leaning on statement is subject of (P805) way too much, almost like a catch-all, after someone told me "instance of" shouldn't be used as a qualifier. I've come to over-use/misuse "object/subject has role" as well.
re your flexi disc edit: is it em dash (—) or horizontal bar (―) you're using? I didn't know about this convention, will stick to that going forward, thanks.
En dash (–). I'm not sure how common it is in languages other than English, though, so it might not be appropriate to use it in all of the labels.