Topic on User talk:Nono314

Hi! I've just seen that the MnM catalog 3024 related to Premiers préfets ID (P4944) has a relevant problem: a relevant number of IDs seem to have a wrong entry on MnM, causing a lot of items having misplaced IDs. Two examples:

• https://mix-n-match.toolforge.org/#/entry/83593772 has generated Augustin Claude Le Provost de Launay (Q75971375) (corrected)
• https://mix-n-match.toolforge.org/?#/entry/83593774 has generated Henry Bernard Albin Le Rat de Magnitot (Q75971393) (corrected)

Since the problem seems unfortunately widespread, I will act in the following way:

1. removal of all references containing "francearchives.fr/fr/facomponent/" in the reference URL (P854) or containing Premiers préfets ID (P4944)
2. removal of all Premiers préfets ID (P4944) IDs from items
3. deactivation of MnM catalog

Then it will be possible to recreate the MnM catalog and have correct matches.

Hi, thanks for the heads up! Can you please delay your action for 1-2 days in order to give me time to perform some checks?

Also, be aware that your action plan seems a too broad: francearchives.fr is the site for National Archives services. There are several wikidata "ids" based on the same URL pattern, and there may also be manual references to unrelated documents that may fall under it. Do not act before a more precise assessment can be performed!

Ok, I'm doing the removal of the references manually, so I will remove only the IDs related to Premiers préfets ID (P4944).

I can delay points 2 and 3 until tomorrow of course.

Anyway, all references containing reference URL (P854) should be removed because they are imprecise (references should be constructed using stated in (P248) + ID + retrieved (P813)).

After checking, it looks like the issue is not with the MnM catalog, but with the site itself...

They have removed 2 entries from the index of that series, and all following entries have just been shifted up (!) taking the previous entries' id. You can see that the last 3 examples for the property are also no wrong (the 5th example id now points to the entry for the 3rd)

So it's not items having misplaced ids, it's just the so called "ids" not being (permanent) ids at all... And recreating a catalog would probably only fix things in the very short term, until the next shift.

Among related identifiers, Personnel de l'administration préfectorale ID (P6973) suffers from the same issue with shifted "ids". Bargeton ID (P4906), seems to be plagued as well, but in a different manner: of all example ids, none is still pointing to the original entry! However, they're not pointing to other entries, but either redirect to the index page or display a "not found" page.

Unsure what to do with such totally unreliable identifiers... @Nomen ad hoc, any idea?

I suggest to close this thread and go on in Property talk:P4944#Instability of the IDs. Thanks for the precise remarks, the situation unfortunately is much worse than I thought ... and it wasn't a fault of the Mix'n'match catalog you created, excuse me for initially thinking that way! Now let's try to find a decent solution, although it seems difficult with such instability.