Hi! A little question about catalogs connected to MuseScore artist ID (P8334), MuseScore artist IDs (63913 IDs) and MuseScore artists (139198 IDs): is the first just a part of the second (so it could be deleted), or are there IDs in the first which are not present in the second? Thank you very much!
User talk:Jc86035
Jump to navigation
Jump to search
They are exactly the same dataset, which I unintentionally imported twice. I asked Magnus Manske to delete 3639, but it looks like that hasn't happened yet.
As you created items for notes of strike tone (P8331), would it be possible to add the notation used on it:Campane_dell'arcidiocesi_di_Milano (column "Tonalità") as Italian (it) label?
I'm running the QuickStatements batch for it. I've just replaced the English note names with the Italian solfège note names, so there might be inconsistencies if I haven't understood the usage correctly (particularly for the double sharps and double flats).
Hi there, just got an email (but no return address). Very exiting, we should talk. Are you on Telegram? I'm @moebeus over there
I wasn't, but I've signed up for an account.
Why did you made Discogs composition ID conflict with MusicBrainz recording ID?
I added the constraint around the time that I was rewriting WD:MUSIC to make the MusicBrainz-style ontology more "official". For obvious reasons, a Discogs composition should almost always be matched to a MusicBrainz work rather than a MusicBrainz recording. Nevertheless, if it's not helpful, just remove it.
I think it's helpful! It's a nice way to quickly spot if a Q Item is mixing data types and some of the information perhaps should be moved/separated out.
You have added some parameters to access date but they are only visible in revision history. Why?
I can see the reference on Q383541 without any issues; the intended result was that the only text would be "retrieved – 9 August 2019". Are you not seeing this text?
How I can add it myself? Can I do it without QuickStatements? Can I install QuickStatements at Wikidata?
You can't "install" QuickStatements; I'm using the web app to import data.
What are you referring to by "parameters"? Are you referring to the edit summary text?
Why I can't add it through Wikidata interface (callendar etc.)?
If you're referring to the "Timestamp +2019-08-09T00:00:00Z ..." text, this is displayed for all diffs which include the time datatype and isn't specific to QuickStatements. You can actually change some of those things by clicking on the text box when editing a date (e.g. setting a date as Julian), though usually it's not necessary.
Schouldn't retrieved (P813) be used as qualifier instead of reference? There are some ids which requiere reference so it would be kinda missleading with other properties.
I'm not sure. This isn't one of those properties, though, and other forms of unsatisfactory but accepted sourcing (e.g. Wikimedia import URL (P4656)) can also satisfy that constraint.
In any case, using the site itself as a reference (which is implied by the lack of other data) wouldn't be misleading, because I used the linked MusicBrainz IDs from both Wikidata and acharts.co to automatically match all of the imported data.
I mean shouldn't be access date added to id (as qualifier) instead of reference (as part of reference which de facto doesn't exists).
Right. I'm not sure if that would be acceptable for identifiers, and I've only seen this sort of usage as references rather than as qualifiers. I think it would be appropriate to have a project chat discussion about this.
I started discussion about it in project chat.
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.
Thanks.
Hello again. What about webcache.google? Why they are not allowed?
The Google cache is not an archival service and should never be used as such (unless e.g. saved through archive.is). According to w:en:Wikipedia:List of web archives on Wikipedia, "links quickly expire".
Οκ. Thanks. I had a problem with a reference that wasn't archive anywhere else and I use Google cache. I have to find another solution.
Save the Google cache pages in archive.is or use the beta version of Save Page Now (login required) to save the original. The former should almost certainly work, and the latter may have a better chance of not messing up any formatting.
Thank you. Very useful informations.
Hola!
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!
Hi there!
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.
- 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 ;)
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.
And the example for MusicBrainz work ID (P435) is Bohemian Rhapsody (Q187745). There's really more cleanup needed here.
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.