Property talk:P5885

Type “software (Q7397), film (Q11424), television program (Q15416), product bundle (Q1020767), video game (Q7889), Windows app (Q1608344)”: item must contain property “instance of (P31)” with classes “software (Q7397), film (Q11424), television program (Q15416), product bundle (Q1020767), video game (Q7889), Windows app (Q1608344)” or their subclasses (defined using subclass of (P279)). (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P5885#Type Q7397, Q11424, Q15416, Q1020767, Q7889, Q1608344, SPARQL

Distinct values: this property likely contains a value that is different from all other items. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P5885#Unique value, SPARQL (every item), SPARQL (by value)

Format “^([a-z0-9]{14}|[a-z0-9]{12})$”: value must be formatted using this pattern (PCRE syntax). (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P5885#Format, SPARQL

Item “distributed by (P750): Microsoft Store (Q135288)”: Items with this property should also have “distributed by (P750): Microsoft Store (Q135288)”. (Help)

List of violations of this constraint: Database reports/Constraint violations/P5885#Item P750, hourly updated report, search, SPARQL

Item “distribution format (P437): digital download (Q54820071), digital distribution (Q269415), video on demand (Q723685)”: Items with this property should also have “distribution format (P437): digital download (Q54820071), digital distribution (Q269415), video on demand (Q723685)”. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P5885#Item P437, search

Allowed entity types are Wikibase item (Q29934200): the property may only be used on a certain entity type (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P5885#Entity types

Scope is as main value (Q54828448), as reference (Q54828450): the property must be used by specified way only (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P5885#Scope, SPARQL

Required qualifier “platform (P400)”: this property should be used with the listed qualifier. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P5885#mandatory qualifier, SPARQL

The property value will be transformed to lowercase automatically. Testing: TODO list

@MSMST1543: Please kindly explain why you keep returning a URL slug that might be causing problems? Please note that this url slug last time caused 503 error, so it better not to use it, please use the correct one instead that works perfectly fine. Regards Kirilloparma (talk) 14:04, 10 October 2021 (UTC)[reply]

I've seen lots of elements with dublicated Microsoft Store ID: one in upper case, one in lower case. I guess the reason behind this is that URLs are usually lower-case, and Mix'n'Match catalogue has upper-case IDs. Those IDs are identical tho. Examples: [1][2][3][4][5][6][7][8][9][10].

I guess case restrictions can solve this problem. Main question is, should we choose lower or upper case. As far as I can see, Microsoft Store normalizes game IDs to lower case (for instance, it redirects 9NLRT31Z4RWM to 9nlrt31z4rwm), but when it comes to software IDs, it keeps the original spelling even if it's in mixed case (cFq7TtC0k7Dx as an example).

I'd normalize all IDs to lower case, and looks like we already have a bot that does exactly that with other properties. We would need to change Mix'n'match catalogue to match this requirement tho. What do you guys think? Facenapalm (talk) 12:51, 20 April 2022 (UTC)[reply]

applsdev Arlo Barnes BugWarp Coloradohusky CommanderKefir CptViraj Cupkake4Yoshi Cwf97 Cynde Moya Danrok Datumizer Dexxor Diggr Dispenser Dollarsign8 DoublePendulumAttractor EdoAug Edolusill Eniehack Facenapalm Floyd-out FullyAwesome Harshrathod50 Jean-Frédéric Keplersj Kirilloparma Lewis Hulbert LotsofTheories Macocobovi Macrike Master Of Ninja Matthias M. Metafire18 Nicereddy Odjob16 Oduci Poslovitch Rampagingcarrot RampantSpirit Santer Sight Contamination SuperUltraHardCoreGamer - Joined to add things about Steam Deck verified/playable titles. Skills: Basic editing. thgiex Tomodachi94 VGPaleontologist Wd-Ryan WikiSyn YotaMoteuchi Athayahisyam

Notified participants of WikiProject Video games Facenapalm (talk) 12:53, 20 April 2022 (UTC)[reply]

So far, I've seen it also occur with speedrun.com game ID (P6783), but speedrun.com seems to handle these identifiers a bit "weirdly" (no redirects, maybe actual aliases?). Poslovitch (talk) 13:15, 20 April 2022 (UTC)[reply]

Looks like the situation is even worse for speedrun.com, [more than 500 cases. Facenapalm (talk) 13:23, 20 April 2022 (UTC)[reply]

BTW, currently there's 1361 IDs in uppercase, 848 IDs in lowecase and 4 IDs in mixed case. Facenapalm (talk) 13:29, 20 April 2022 (UTC)[reply]

I do agree for normalizing to lower case, thank you ! Floyd-out (talk) 15:28, 20 April 2022 (UTC)[reply]

I wish there was a global solution for this, maybe there should be a project chat topic. Same problem for X username (P2002). AntisocialRyan (Talk) 15:30, 20 April 2022 (UTC)[reply]

I've converted MS Store IDs to lowercase. Now we should change Mix'n'Match catalogue. @Kirilloparma, do you know the best way to do that? Facenapalm (talk) 15:58, 26 April 2022 (UTC)[reply]

@Facenapalm: Sorry for the late response. Unfortunately, we can't fix an existing m'n'm catalog, because once you have added IDs there, you won't be able to fix them until you delete catalog and create a new one. Seems like this tool is not intended for corrected entries to be uploaded there, only new ones. However, the creator of this tool Magnus Manske can fix this problem, I guess.

I can download the entire m'n'm catalog with the problematic entries and update it with correct ones, but eventually they'll just get mixed together, meaning we'll have both uppercase and lowercase IDs. This is exactly what we don't need. Here's an example of such a catalog, where I mistakenly added few uppercase identifiers (see screenshot 1 and screenshot 2), so we can't use an existing catalog to solve this problem. The solution here is:

1. I suggest adding {{Autofix}} template to the property talk page, which should help to change all problematic entries to lowercase in the main values. However, I'm not sure that the bot will also fix the affected entries in the references. We must see.
2. Purge automatches from the existing catalog and simply not using it.
3. Once automatches are purged it is recommended to remove catalog by asking Magnus Manske.
4. Ask @Xzonn2000, who periodically updates the catalog, to upload a new one this time with corrected entries. Or I can do this task. Here is the list of all corrected entries. From the moment we start using the new catalog, all new identifiers that will be added to it must be in lower case and this should be noted in the description of the catalog. Regards Kirilloparma (talk) 04:10, 18 February 2023 (UTC)[reply]

 Done the first task. Side note: if you find that two identical identifiers have been added in the values, then don't worry, the bot will fix it and remove duplicated one, as it already does in the case of GOG application ID (P2725) property. Regards Kirilloparma (talk) 04:15, 18 February 2023 (UTC)[reply]

Second task  In progress. Regards Kirilloparma (talk) 04:19, 18 February 2023 (UTC)[reply]

The second task has been  completed. Moving to the third one and notifying Magnus Manske. Regards Kirilloparma (talk) 05:06, 21 February 2023 (UTC)[reply]

The third and fourth tasks are  completed. Magnus deactivated the problematic catalog and I've created a new one with corrected IDs. Regards Kirilloparma (talk) 22:15, 21 February 2023 (UTC)[reply]

Now you can create a new catalog using this url. It will be updated automatically at 16:00 every Sunday (UTC). And product ids are converted into lower case. Xzonn2000 (talk) 05:44, 18 February 2023 (UTC)[reply]

Thank you! Now we have to wait, because once again for some unknown reason Mix'n'Match stopped working and does not allow to correctly update or upload catalogs. Regards Kirilloparma (talk) 05:27, 19 February 2023 (UTC)[reply]

@Facenapalm, Xzonn2000:  Resolved. The bot is gradually correcting the affected identifiers (including IDs in references and duplicates); a new catalog with corrected entries has been created. Regards Kirilloparma (talk) 22:26, 21 February 2023 (UTC)[reply]

In the future, when making new catalogs, keep the old catalog. Once it's marked as inactive by Magnus, RPI2026F1Bot will mark it as deprecated automatically, or it can be done manually. I added it back manually for now. RPI2026F1 (talk) 14:09, 13 April 2023 (UTC)[reply]

@RPI2026F1: The former catalog was not added, as for some reason your bot removes the preferred rank for new or updated catalogs (see [11], [12], [13]), which IMHO bot should not do. Can you explain why this happens? By the way, thank you for adding the former catalog. Regards Kirilloparma (talk) 04:00, 14 April 2023 (UTC)[reply]

The bot will overwrite a target claim's rank with the rank it has calculated, and that rank is normal unless I specifically tell it to mark a claim as deprecated/preferred. Invalid catalogs should be deprecated, but one property can have multiple active catalogs, and so the bot is unable to calculate which one is preferred. Most of the time, instead of marking a catalog as preferred, the other bad catalogs should be marked as inactive, and then the bot will deprecate them. RPI2026F1 (talk) 13:19, 14 April 2023 (UTC)[reply]

The problem here is not the preferred rank itself (which is the correct rank in this case btw), but the fact that your bot sets a normal rank, both for the outdated and the new catalog, which is not correct as it is not clear which of the two should be used. The person who uploads new or updated catalogs should be able to tell others that they should use exactly the new catalog and not the one or ones that had problems before, so the preferred rank here is a good option.

Most of the time, instead of marking a catalog as preferred, the other bad catalogs should be marked as inactive, and then the bot will deprecate them. - Well, actually I think it should be modeled differently. With deprecated rank here, we are saying that this m'n'm catalog was never correct, even though it is absolutely not true. It was used at some point which means that this is a historical catalog. See Help:Ranking#Deprecated rank for more information.

Take a look at this item as an example. Here we have 3 logos, 2 of which are no longer in use and one that has been in use since this year. The former logos as you can see have the normal, not deprecated rank, as that would be wrong, they were used before (historical logos). That's exactly why I think that the bot still should not remove the preferred ranks since such statements are correct. Regards Kirilloparma (talk) 02:26, 15 April 2023 (UTC)[reply]