WikiData fix please?

+4 votes
239 views
I think William Montagu's son Bishop Simon is linked with Montagu-17, but should be Montacute-14.
WikiTree profile: William de Montague
in Genealogy Help by Living Horace G2G6 Pilot (635k points)
retagged by Maggie N.

Hm feels like a mess or?


Now we have Q7262160 = Montagu-40 William (Montagu) de Montague 2nd Baron (1275 - 1319)

2 Redirects is that not a signal that WikiTree has a problem? Looks like a candidate for Project Database Error? 

The idea to merge to lowest number doesnt work when people change LNAB

Now I'm confused.  The problem is that on this page

https://www.wikidata.org/wiki/Q7519369

the WikiTree ID says Montagu-17 (without an e) but should say Montacute-14.

WikiTree's dates aren't necessarily right.  But Montagu-17 was the bishop's uncle.

 

Now Q7519369 is set same as Montagu-17 see change log

Feels like some WikiTree task force need to review this with Redirects

I update cca 20 profiles on Wikidata each week, that were Merged / Renamed on Wikitree. A list is created by my program, so I do it in 5 minutes.

I do expect for this number to decrease, since things are getting corrected.

@Aleš my comment about redirect is WikiTree redirects.

The idea that we should always merge to lowest number is good BUT if I guess as above people start merging to new LNAB then you get 

Montacute-17 --> Montagu-67 --> Montacute-35 

if we look at the change log 

01:43: John Schmeeckle edited the data for Alice (Montacute) Daubeney. (Merged Montagu-67 into Montacute-35) [Thank John for this]

i.e. my guess 

  1. someone thought LNAB Montacute
  2. then someone thought LNAB Montagu
  3. and then someone thought LNAB Montacute again 

my understanding from trying to understand Chris is that more redirects are bad as search engine like Google see that WikiTree change URLs and WikiTree get lower ranking


I feel it's impossible for a human to correct this it should be fixed with a maintenance program walking through all profiles and see that we just get no chains of redirects like we have above for....

I think rewriting redirects would have to go through the change-logging system.  If a bot can't do it, it probably can't be done.

That doesn't explain why the server doesn't resolve the chain before responding to the client.

@RJ Horace yes it should be done on the server

But I guess WikiTree just use standard Wikimedia #REDIRECT command

when a merge is done I guess just #REDIRECT is added to the profile ==> no logic is on the server ==> 

TO BE DONE walkthrough all profiles with REDIRECT and see that the REDIRECT points on the last profile in the chain

The change log can be found also for merged profiles ==> the history of the above case is

  1. Montacute-17
    1. 3 May 2013 merged  J Pictet Merged Montacute-17 into Montagu-67
  2. Montagu-67
    1. 3 Jul 2015 merged John Schmeeckle Merged Montagu-67 into Montacute-35

==> 3 jul 2015  Montacute-17 should have been changed to redirect directly to Montacute-35

Is there not a way for a wiki-bot to change the chain by omitting/ removing the intermediate step? Then the search-bot might never notice it had once been there? Just a thought.

@Sir William Arbuthnot

Yes that is my suggestion since a year ago but I don't get any feedback... its impossible to set up rules how to merge because some people in the example above think Montacute is ok and then someone change to Montagu.... and then some change back to Montacute

Ps. I spent some time with Macfie-431 he introduced Curling to Sweden!!



and Macfie-553 was a golddigger and introduced Canadian canoe to Sweden


MacFie canoe

The MacFie Canoe club http://www.hmcc.se/

Please log in or register to answer this question.

Related questions

+5 votes
1 answer
182 views asked Feb 18, 2017 in Genealogy Help by Living Sälgö G2G6 Pilot (298k points)
+2 votes
1 answer
+7 votes
0 answers
+6 votes
1 answer
+7 votes
2 answers
+4 votes
1 answer
234 views asked Jan 13, 2023 in Policy and Style by Lori Dosser G2G6 (8.5k points)

WikiTree  ~  About  ~  Help Help  ~  Search Person Search  ~  Surname:

disclaimer - terms - copyright

...