Open main menu

User talk:Jc86035

About this board

Previous discussion was archived at User talk:Jc86035/Archive 1 on 2016-10-01.

Trade (talkcontribs)

Why did you made Discogs composition ID conflict with MusicBrainz recording ID?

Jc86035 (talkcontribs)

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.

Moebeus (talkcontribs)

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.

Reply to "Conflicts"
Eurohunter (talkcontribs)

You have added some parameters to access date but they are only visible in revision history. Why?

Jc86035 (talkcontribs)

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?

Eurohunter (talkcontribs)

How I can add it myself? Can I do it without QuickStatements? Can I install QuickStatements at Wikidata?

Jc86035 (talkcontribs)

You can't "install" QuickStatements; I'm using the web app to import data.

Jc86035 (talkcontribs)

What are you referring to by "parameters"? Are you referring to the edit summary text?

Eurohunter (talkcontribs)

Why I can't add it through Wikidata interface (callendar etc.)?

Jc86035 (talkcontribs)

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.

Eurohunter (talkcontribs)

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.

Jc86035 (talkcontribs)

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.

Eurohunter (talkcontribs)
Jc86035 (talkcontribs)

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.

Eurohunter (talkcontribs)

I started discussion about it in project chat.

Reply to "Q383541"
Xaris333 (talkcontribs)
Jc86035 (talkcontribs)

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.

Xaris333 (talkcontribs)

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.

Jc86035 (talkcontribs)

I've changed the constraint to accept HTTP links.

Xaris333 (talkcontribs)

Thanks.

Xaris333 (talkcontribs)

Hello again. What about webcache.google? Why they are not allowed?

Jc86035 (talkcontribs)
Xaris333 (talkcontribs)

Οκ. 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.

Jc86035 (talkcontribs)
Xaris333 (talkcontribs)

Thank you. Very useful informations.

Reply to "Problem with P1065"
Moebeus (talkcontribs)

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?


Jc86035 (talkcontribs)

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.

Moebeus (talkcontribs)

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!

Reply to "samples and plagiarism"
Moebeus (talkcontribs)

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,

Jc86035 (talkcontribs)

I can't say I would be able to contribute, but I would support efforts in this vein.

Reply to "Shape Expressions"

Thinking about a new property: "recorded versions"

10
Moebeus (talkcontribs)

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?

Jc86035 (talkcontribs)

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

Moebeus (talkcontribs)

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

Jc86035 (talkcontribs)
Moebeus (talkcontribs)

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?

Jc86035 (talkcontribs)

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).

Jc86035 (talkcontribs)

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.

Moebeus (talkcontribs)

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

Jc86035 (talkcontribs)

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

Moebeus (talkcontribs)

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

Reply to "Thinking about a new property: "recorded versions""

{{P|435}} conflicts with {{P|436}}

12
Mineo (talkcontribs)
Jc86035 (talkcontribs)

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.

Moebeus (talkcontribs)

@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?

Jc86035 (talkcontribs)

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.

Mineo (talkcontribs)
Moebeus (talkcontribs)

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.

Jc86035 (talkcontribs)

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.

Jc86035 (talkcontribs)

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.

Mineo (talkcontribs)
Jc86035 (talkcontribs)

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.

Mineo (talkcontribs)
Jc86035 (talkcontribs)

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.

Reply to "{{P|435}} conflicts with {{P|436}}"
Moebeus (talkcontribs)

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?

Jc86035 (talkcontribs)

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.

Reply to "Have you seen this?"

musical work / musical composition

4
Moebeus (talkcontribs)

regarding https://www.wikidata.org/w/index.php?title=Q1886329&oldid=prev&diff=885609086

"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?

This question comes up a fait bit (see User talk:Andrew Gray#"musical work" / "song" ) - maybe we could define it a little better over at Wikidata:WikiProject Music to avoid confusion.

Jc86035 (talkcontribs)
Jc86035 (talkcontribs)

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).

Moebeus (talkcontribs)

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.

Reply to "musical work / musical composition"
NMaia (talkcontribs)

Hey! This is sort of off-topic from the discussion so I'm sending this privately. I think there are things to be improved in the metro as can be seen in this query. Your other one seems alright.

Jc86035 (talkcontribs)

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.

Reply to "Queries as QA"
Return to the user page of "Jc86035".