Wikidata

Wikidata:Requests for comment/Redirect vs. deletion

< Wikidata:Requests for comment

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

There is support that items should be redirected when merging. Generally speaking, items should not be deleted when merging.
  1. Deleting is however appropriate if an item has not been existed longer than 24 hours and if it's clear that it's not in use elsewhere.
  2. "Real duplicates" — the items that have exactly the same sitelink(s) in one or more items — should be redirected as well.
  3. Wikidata:Requests for deletions can keep its name, since there will always be pages that requires deletion.

--Stryn (talk) 18:55, 3 December 2014 (UTC)[reply]

An editor has requested the community to provide input on "Redirect vs. deletion" via the Requests for comment (RFC) process. This is the discussion page regarding the issue.

If you have an opinion regarding this issue, feel free to comment below. Thank you!


THIS RFC IS CLOSED. Please do NOT vote nor add comments.

Since slightly more than a month it is possible to create a redirect bewteen items, so that when merging two items the source item can be turned into a redirect to the target item. At the moment this creating redirects can not be done through the user interface, but only through an API (if I use terminology correctly here). Ways to create redirects are for instance by the merge.js tool, WiDaR ("The game", "Quick statements") or the enhancementes administrators have at WD:RfD.

Administrators have to deal with the question whether one should delete or should create a redirect in stead. This may be in question at WD:RFD, where in fact deletion is questioned, but of course also in handling own mergings or other deletions not asked for.

Central question in this RfC is in what cases creating a redirect is preferred over deletion.

Arguments edit

Main arguments in favour of preferring redirects are:

  • The stability of links - especially links from outside wikimedia-sites still point to something useful.
  • It is more easy to revert a merge, as no admin is needed to undelete.

Main arguments against preferring redirects are:

  • In many cases redirects are useless (new items <24h, items with links to pages which are unlikely to be interesting outside wikimedia sites like Category:User de-2 (Q6396356), ...)
  • Wikidata gets more messy with the many redirects
  • Deletion is requested at RfD, not redirecting

Issues

  • The interface is not working flawless
  • By the fact that every user can perform merges resulting in redirects, it is hard to keep track of what is happening and hence to find and repair wrong merges.

These issues may seem not directly related to the central question, which does not mean they are unimportant.

Discussions on this matter can be found at:

During the first week of this RfC it should be possible to add options to the 3rd paragraph on "Exceptions"

--Lymantria (talk) 12:24, 21 September 2014 (UTC)[reply]

See also Help:Redirects which I drafted some time ago. -- Bene* talk 20:52, 21 September 2014 (UTC)[reply]

Comments/Discussion edit

Comments on the arguments against redirects:

  • In many cases redirects are useless (new items <24h, items with links to pages which are unlikely to be interesting outside wikimedia sites like Category:User de-2 (Q6396356), ...)
    • How can we determine they are useless? How do we know that nobody depends on those identifiers? If we can achieve stable identifiers everywhere we should also doo that.
  • Wikidata gets more messy with the many redirects
    • How that?
  • The interface is not working flawless
    • Redirects are already included in the merge gadget and some other gadgets. This is an issue we can easily fix.
  • By the fact that every user can perform merges resulting in redirects, it is hard to keep track of what is happening and hence to find and repair wrong merges.
    • We might restrict merges and redirects to logged-in users/confirmed accounts only and we can keep an eye on the recent merges just like we currently review them on RfD by tags etc.

-- Bene* talk 16:11, 27 September 2014 (UTC)[reply]

Do we want to restore items deleted as a result of merging and make redirects, under the same reasons for preferring redirects above? I believe we have thousands of merged items already deleted. whym (talk) 05:06, 5 October 2014 (UTC)[reply]

Make it tens of thousands, and that will make it elaborate and also difficult to find and restore the items to restore. Kind regards, Lymantria (talk) 18:52, 5 October 2014 (UTC)[reply]
I think it's more of the issue of whether we want it or not. It's true that something like 440,000 (warning: 30 secs or more to load the results) is a sheer number, but if we are determined that we want them to serve as redirects, a bot to automate undeletions wouldn't be too difficult to create. (Assuming most of them contain the target item number in the deletion comment.) Still, the required efforts wouldn't be zero, and I'm not sure the merit of restoring long-abandoned ones will outweigh the cost, though. whym (talk) 01:29, 11 October 2014 (UTC)[reply]

Hey :) I wanted to give some perspective from the development side and how it fits into the bigger picture. One of the big arguments for using Wikidata is that it has stable identifiers. Every day more and more people rely on the fact that we have stable identifiers. You want to refer to a concept independent of its language? You just use its Q-ID. Through this amazing things like q-label are possible. Or Wikidata becoming the one true gene database? If our identifiers are not stable this will not work. If someone creates a new item and uses its Q-ID in their database to do something they need to be able to rely on that number being available and stable from the moment they create it - not 24h later - not 2 weeks later. Redirects are the way to get stable identifiers for such use cases. We will see more and more of this usage of Wikidata coming up and it is super important that we support it if we really want Wikidata to become a central place in the open data web and beyond. Hope that helps to put this into a bigger picture. --Lydia Pintscher (WMDE) (talk) 15:59, 28 November 2014 (UTC)[reply]

1. Merging edit

Redirecting is the preferred result of merging of two items. Administrators should not delete the source item but turn it into a redirect to the target item.

Votes edit

  •  Support --ValterVB (talk) 12:36, 21 September 2014 (UTC)[reply]
  • TomT0m (talk) 12:49, 21 September 2014 (UTC)[reply]
  •  Support Lymantria (talk) 13:03, 21 September 2014 (UTC)[reply]
  •  Support -- Bene* talk 20:57, 21 September 2014 (UTC)[reply]
  •  Oppose - To general. --Succu (talk) 21:30, 21 September 2014 (UTC)[reply]
  •  Oppose. Allan J. Aguilar (Ralgis) 22:25, 21 September 2014 (UTC)[reply]
  •  Support More simple for the admin. --Fralambert (talk) 23:25, 21 September 2014 (UTC)[reply]
  •  Oppose --Epìdosis 05:08, 22 September 2014 (UTC)[reply]
  •  Support--GZWDer (talk) 10:35, 22 September 2014 (UTC)[reply]
  •  Support First of all, redirecting helps non-admins to correct merging mistakes themselves, without posting an undeletion request to AN. This would be convenient. Jianhui67 talk★contribs 16:33, 22 September 2014 (UTC)[reply]
  •  Support Developers have developed redirects and we won't use them? Really? :-) Matěj Suchánek (talk) 17:52, 22 September 2014 (UTC)[reply]
  •  Oppose. In most cases I've seen, the duplicated item contain only one item and created by a bot. Aurora (talk) 06:06, 28 September 2014 (UTC)[reply]
  • Support Vogone (talk) 10:58, 28 September 2014 (UTC)[reply]
  •  Support Ajraddatz (talk) 18:58, 28 September 2014 (UTC)[reply]
  •  Support Stable IDs are really important. Regardless of the age. Raymond (talk) 12:37, 29 September 2014 (UTC)[reply]
  •  Oppose At the beginning redirect was proposed to solve problem of items which don't correspond to one WP article. Redirect should be an exception for some WP articles which are not matching an unique item. For other cases deletions have to be applied. Snipre (talk) 15:36, 29 September 2014 (UTC)[reply]
  •  Support as per http://www.w3.org/TR/cooluris/ Stuartyeates (talk) 19:14, 29 September 2014 (UTC)[reply]
  •  Opposeper Cycn and I don`t agree with the propose of this RFC. I know redirect is useful and using well, However I think delete is also fine. Delete is not harmful --DangSunM (talk) 21:55, 13 October 2014 (UTC)[reply]
  •  Support --YMS (talk) 12:12, 14 October 2014 (UTC)[reply]
  •  Support The need to merge suggests that people were going multiple different places for the same information. A redirect is the sensible thing in this case. GPHemsley (talk) 14:20, 16 October 2014 (UTC)[reply]
  • Oppose. Not convinced by the arguments for the need of redirects. - FakirNL (talk) 10:31, 17 October 2014 (UTC)[reply]
  •  Support, needed for external clients. The only argument I see here agsint redirects is that anyone can do them. If that is really an issue, we should be able to limit the use of redirect tools to admins. But to me, it is a good thing that anyone can do redirects. It is simpler and faster to do and to undo (plus contrary to a deletion, the item history remains visible to anyone) --Zolo (talk) 07:45, 18 October 2014 (UTC)[reply]
  • Support. I'm sensible to the argument about a better history access. I encountered yesterday a strange case with items A, A' and B (A and A' disambig, B a book). It were created because an user changed the disambig into a book. Then, I created a disambig thinking we didn't have that. Then, yet another user merged my disambig with the … book item. To fix that and offer a cleaner solution (restored each item in the pristine state as it were before the clumsy intervention of the first newbie user and the wrong corrections of us two, unmerged the book/redirect mix, remerged the redirect with the redirect) required to look and understand the three items history. With redirect instead of deletion, we keep the history and allow such untangle work. --Dereckson (talk) 14:05, 20 October 2014 (UTC)[reply]
  •  Support Link stability is hugely important, and I see no downsides to generally preferring redirection to deletion, as long as some exceptions are allowed. — PinkAmpers&(Je vous invite à me parler) 11:20, 22 October 2014 (UTC)[reply]
  •  Support per arguments above about link stability, history access. Mike Linksvayer (talk) 21:10, 26 October 2014 (UTC)[reply]
  •  Oppose except, maybe, for rare occations, for instance: 2 linked items are to be merged, and the links have to me moved from one to the other, and you don't want the linking items having 'deleted pages' listed in their link, in which case a temporal redirect can be useful. In other cases redirects are just debris. It complicates reverting because it's more difficult to reach a redirect than a deleted page and it is quite easy to overlook a redirect: you think you're going to one item, but you end up at another. A deleted page gives you a simple pages stating that the item was removed, the reason and if it was merged the destination of the merge. In links to the abolished entry the deleted item shows as red, so it was clearly deleted, but you still can go to it and get the information. The redirect, however, looks like a real item and sends you (forces you) to another item. This makes it more complicated to undo incorrect deletions or merges. Also, most of the time redirects are used as an alternative to neatly cleaning up the old items. The problems, in my opinion, far outweigh the small benefit the redirect can serve and the very existance of the concept of redirecting items causes more problems than it can ever hope to solve, so I think it would be best abolishing the whole concept altogether, so: No redirects at all, no exceptions! - cycŋ - (talk • contribs • logs) 12:40, 28 October 2014 (UTC)[reply]
    • You state that it is less easy to revert a redirect than a deletion. Indeed it often takes two clicks to reach a redirect, while a deleted page is found in one click. But I hope you are aware that for reverting a deletion the admin-tools are needed to undelete, while after that there is need to do two reverts, while with redirects there only need to be done two reverts. In my opinion reverting deletions is more complicated, certainly to non-admins, than reverting redirects. Lymantria (talk) 13:25, 28 October 2014 (UTC)[reply]
      • Well, if it's your opinion it's irrelevant to react other than stating the obvious: I disagree. - cycŋ - (talk • contribs • logs) 09:12, 29 October 2014 (UTC)[reply]
        • Provided you notice that the redirected item is shown at the top of the page (like here), this is really not more complicated to The whole reversion process takes 3 clicks. For a restoration, you need to go into the log, and restore the right version. That is 3 clicks as well (not mentioning, that, as Lymantria points out, a restoration should usually be complemented by a revert). -Zolo (talk) 10:10, 29 October 2014 (UTC)[reply]
          • So, it's more or less the same level of work and complication, it's only a personal preference which of the two you prefer. Except, maybe: It's more complicated to revert deletion for non-admins than it is for admins. That raises the question: is that a bad thing? (I think it isn't). - cycŋ - (talk • contribs • logs) 12:57, 29 October 2014 (UTC)[reply]
            • reverting correct redirects sounds like vandalism that should be fought the same way as other vandalism. What sounds more debatable is that anyone can create redirects. It has some bad sides, but remembering the large and persistent deletion request backlog that so quicly disappeared when redirects were implemented, I think on the whole, the good side far dominate. Anyhow, if we do not want to allow everyone to create redirects, I think it is technically possible to restrict their creation to some user groups. --Zolo (talk) 13:55, 29 October 2014 (UTC)[reply]
              • I reject the suggestion that a backlog disappeared because redirects were implemented. If there's any causality here I it would cause only me to be very suspicious about the concept, not to jubilate the concept as the solution for the backlog problem. But then again, I seem to be suspicious about the concept. (which does not prove the causality, btw) True, if vandalisme occurs it should be treated as such, that should not be helt against a concept. And if it's seen that there are bad sides to this concept and they are addressed that would help me to overcome my reservations. You think the good outweighs the bad, I do not. I presented my arguments and if it does not serve to stop the whole unholy idea I hope it helps to improve it, then I can at least mope in peace... - cycŋ - (talk • contribs • logs) 14:28, 29 October 2014 (UTC)[reply]
                • The backlog disappeared in a few days, after redirects were implemented in the "merge game". The causation appears to be pretty clear (even though the merge rate might have been sufficiently decreased to make the backlog more manageable today, even without redirects). --Zolo (talk) 15:36, 29 October 2014 (UTC)[reply]
                  • Wasn't it the "game" that caused the backlog in the first place, amongst a lot of other issues like clearly incorrect merges... Admins could keep up with it, and maybe introducing redirects to it helped a something flawed become less flawed, but then it was a patch for the game, not a solution for problem that didn't exist before the game. (and I still reject the causality. I seem to remember several admins working their butts off when the Game flodded the RfD page) - cycŋ - (talk • contribs • logs) 15:53, 29 October 2014 (UTC)[reply]
                      • The Game caused the backlog, but only because without it we were much slower at finding duplicates. --Zolo (talk) 09:40, 3 November 2014 (UTC)[reply]
                        • ...and because it caused all kinds of incorrect merges that needed to be undone. And because one couldn't see if the merge was correct or not all needed to be checked, that takes al lot of extra time. It did manage to find a lot of duplicates, sure, and most merges were indeed correct, but a substantial minority of the merges were problematic. - cycŋ - (talk • contribs • logs) 10:37, 3 November 2014 (UTC)[reply]
          • I also have an issue with the way redirects are shown. The first few times I completely missed it. And if I missed it, I doubt I was and will be the only one. But I suppose the way it is shown could be altrered to address this, so this objection can be solved. - cycŋ - (talk • contribs • logs) 12:57, 29 October 2014 (UTC)[reply]
    • I am startled by your point that "redirect are used as alternatives to neatly cleaning up old items".
      1. if you mean cleaning up the item itself, it is just wrong: you can delete a non-empty item, but you cannot redirect it. It means that that redirected, not deleted, items have to be neatly cleaned up.
        • "you can delete a non-empty item", but you shouldn't. That's bad maintenance, like creating redirects is bad mainentance. For both options: deletion or creating redirects you should always clean the item. It's nice that the current situation wo't let you create a redirect unless you clean up, but if the fact that you can delete an non-emptied item is a problem then that may have to be solved, but it's not a reason to abolishing one system for another, expecially not one with its own flaws. If the current system is found to be unfixable and/or if the replacing system would be flawless, then there would be no reason to oppose this new system, I suppose (well, appart from simply disliking/trusting change, but that would be a last resort). - cycŋ - (talk • contribs • logs) 09:12, 29 October 2014 (UTC)[reply]
      2. if you mean cleaning up incoming links, you can both delete or redirect an item that has incoming links. The difference is that it is much more annoying in case of deletion. For humans, they see a red link, it is ugly and, for casual users, unintuitive. For machines, it is very difficult to know what to do. When there is a redirect, things are much smoother. Machines can be relatively easily taught to follow redirects, and humans will hardly notice them.
        • The fact that humans will hardly notice them is a very big flaw in the system and I expect it will cause substantial damage in the future if this is not adressed. Indeed if this flaw, and the others I mentioned, would be adressed may even reconsider redirections as a practical tool, but as for now I remain opposed to the concept. - cycŋ - (talk • contribs • logs) 09:12, 29 October 2014 (UTC)[reply]
    • Also, redirects are not "just debris". To take an example I already used somewhere else. If VIAF stores links to Wikidata, and one of those items is deleted, the link is broken. If the item is redirected, you can still follow the link. --Zolo (talk) 13:58, 28 October 2014 (UTC)[reply]
      • Isn't that VIAF's issue to solve? - cycŋ - (talk • contribs • logs) 09:12, 29 October 2014 (UTC)[reply]
        • If we want other websites to link to Wikidata, they should be able to assume that Wikidata IDs are stable. If items are deleted, they will have to maintain their data manually, and this is can get really time consuming. Of course this is not just VIAF, it is the hundreds of websites that may want to use Wikidata IDs, in databases, spreadsheets etc. They should not need to constantly check that that the links are not stale. -Zolo (talk) 10:10, 29 October 2014 (UTC)[reply]
  • Oppose - doubles should be merged and the extra item deleted. Jane023 (talk) 15:36, 28 October 2014 (UTC)[reply]
    @Jane023:. I think everyone agrees that duplicates should be merged. The question is why should we delete merged items rather than transform them into a redirect ? IDeletions if that it breaks incoming links from external database (see my VIAF example above) and it has some other (more minor) issues like concealing page history. Apart from the teeny-weeny gain of space in the dumps, I do not see any reason to prefere deltions over redirects. -Zolo (talk) 16:18, 28 October 2014 (UTC)[reply]
Deletion is the only way to force people to keep their links clean and accurate. Now, during this startup period, it will be much easier to do this (no item number is older than wikidata itself). Jane023 (talk) 16:45, 28 October 2014 (UTC)[reply]
True, and it is annoying when a tool like this one points you to a deleted page, while a redirect would have made life a lot easier. Lymantria (talk) 17:40, 28 October 2014 (UTC)[reply]
Jane, deletion does not force anything. The difference is that they can only be done by an admin as part of her admin job and as such backlinks are more likely to be taken care of. Even so, quite a lot of items appear to have been deleted without checking backlinks, and that has to be fixed manually. With redirects, those backlinks are not nearly as troublesome, and should be easy to fix by bot. Would such a bot solve your concerns ? --Zolo (talk) 18:35, 28 October 2014 (UTC)[reply]
When I said "Deletion is the only way to force people to keep their links clean and accurate", I was referring to people outside of the Wikimedia family of projects, such as website administrators of content aggregators. I don't really care about internal problems with links, because that would just be examples of bugs that may be fixed in future. Jane023 (talk) 16:07, 2 November 2014 (UTC)[reply]
@Jane023: thousands of items need to be merged. If we delete the merged items, external websites will have to update all those links manually or to write fancy scripts to sort of solve the issue automatically. That is very cumbersome, and uselessly so. If we keep redirects, they could keep their IDs up to date much more easily. I am not a programmer, and still I am fairly sure I could make an Excel macro that would do that. --Zolo (talk) 09:40, 3 November 2014 (UTC)[reply]
Well actually, my whole point is that it is NOT that cumbersome now, while Wikidata is so young. By definition, there are just not that many incoming links that depend on Wikidata, therefore, we should just keep on plugging while we wait for gadgets that will prevent doubles from occurring in the first place. We shouldn't make a fix for something that is itself not a bug, but only a symptom of a bug. Jane023 (talk) 10:00, 3 November 2014 (UTC)[reply]
We may not ever be able to completely avoid redirects. It is difficult to see beforehand that a Chinese article has an equivalent in Polish, and a duplicate is not nearly as annoying as the erroneous conflation of two concepts in the same item, so that duplicate-prevention tools should rather err on the cautious side. If we can decrease the number of duplicates, that is great, but the question will remain: what do we do with those those duplicates we were not able to avoid ? I cannot see any good reason to delete rather than redirect them. If the redirected item was not in use anywhere, it does not do any harm, if it was in use, it avoids breaking things. --Zolo (talk) 10:29, 3 November 2014 (UTC)[reply]
  •  Support On the technical level this makes complete sense. Also, even before The Game existed, admins had an extremely hard time keeping up with the backlog of deletion requests. As Legoktm (talk • contribs • logs) once told me, the use of the MediaWiki delete function for this was unsustainable in the first place. --Jasper Deng (talk) 17:28, 29 October 2014 (UTC)[reply]
  •  Support --Krd (talk) 13:12, 30 October 2014 (UTC)[reply]
  •  Support as a general rule (with common-sense exceptions). Redirects don't cost us anything and are potentially vital for third party users - and we hope there will be many of those. Andrew Gray (talk) 22:31, 14 November 2014 (UTC)[reply]
  •  Neutral: redirects have the advantage of keeping the page history, and of making it easy to restore wrong merges. A disadvantage is that it is much, much harder to find wrong merges, as redirects look the same as real items. It redirects would look different (different color, or in italics), I would be in favour. - Brya (talk) 05:26, 21 November 2014 (UTC)[reply]
  •  Oppose Links to Wikidata items are dynamically created, so there is no need for a redirect unless you are redirecting something that could actually be a separate article, and that could be resurrected as an item when there was an article to link it to (but it would only be discoverable if it was not a redirect, but an empty item with a description). Redirects though, are not like article redirects, where there could be a thousand links to the redirect all over the Wikipedia, and then when an article is created they suddenly go to the redirect turned into an article. That concept does not exist on Wikidata, because if you turn a redirect back into an item, you have to populate it yourself. With article redirects, the links to the redirect are in a thousand other articles. With wikidata, you are only dealing with 200 wikis, and you have to put all of the links into the wikidata item yourself. 99% or more of the redirects that would be created instead of deleting an item are duplicate items that were created for no reason, and just need to have the one link in it moved into the existing item for that article, and the duplicate deleted. It is senseless to keep around tens and hundreds of thousands of redirects that will never become valid items. 76.24.193.7 05:51, 22 November 2014 (UTC)[reply]

Comments/Discussion edit

  • Oppose votes should rather describe what exceptions they want. Please remember that we vote based on arguments. -- Bene* talk 16:07, 27 September 2014 (UTC)[reply]
    • Or why one wouldn't want any exceptions? I appreciate that you'd prefer arguments rather than just votes, but the way you formulate this reads like: "Live with it, it's happening, just describe how we can make living with it a little easier", and you didn't mean that, surely? And 'arguments rather than just votes' would be a reasonable request for supporters as well. 12:47, 28 October 2014 (UTC)

2. Real duplicates edit

Redirecting is the preferred result of solving real duplicates, where due to some error one or more site links are found in one or more items. Administrators should not delete one item and leave the other, but turn one into a redirect to the other.

Votes edit

Comments/Discussion edit

3. Exceptions edit

Redirection is however not preferred in the following cases

No exceptions edit

With this option it is unnecessary to put votes at other options.

Young items (<24h) may be deleted edit

Very young items by accidental creation (<15m) may be deleted edit

Items with category-sitelinks may be deleted edit

This should be applied to Project and Templates (and other no-articles) items too.

I agree with Lymantria that we cannot say there is nobody relying on category items and their identifiers. I'm pretty sure there might be usecases where this is needed. -- Bene* talk 11:44, 28 September 2014 (UTC)[reply]

Items which had no statements before edit

Comments/Discussion edit

4. Naming of Wikidata:Requests for deletions edit

If requests for deletion will often be requests that should lead to redirects in stead, the name "Requests for deletions" should be changed. Votes can come with suggestions.
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Requests_for_comment/Redirect_vs._deletion&oldid=542148489"