Wikidata:Property proposal/WMF short URL

From Wikidata
Jump to navigation Jump to search

WMF short URL[edit]

Return to Wikidata:Property proposal/Generic

   Under discussion
Descriptionslug of a short URL for a web page, from the official Wikimedia URL Shortener
Data typeExternal identifier
Domainpages on WMF projects
Allowed values[3-9A-HJ-NP-Za-km-z$][2-9A-HJ-NP-Za-km-z$]*
Example 1Wikidata (Q2013)d
Example 2Wikipedia (Q52)w
Example 3Wikisource (Q263)s
Example 4Arabic Wikipedia (Q199700)HU
Example 5French Wikisource (Q15156541)Yj
Formatter URLhttps://w.wiki/$1
See alsoWikidata:URLShortener

Motivation[edit]

The official WMF URL shortener is due to launch on 11 April. The format of the URL is w.wiki/ followed by a string of letters and numbers. The examples shown above have been pre-populated, but longer URL slugs will be generated once the system is available to all editors.

Would this be better as an external-ID type property, with a formatter URL of https://w.wiki/$1? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:48, 3 April 2019 (UTC)

Note: consensus seems to be tending towards an external-id datatype; I've modified the proposal accordingly. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:07, 4 April 2019 (UTC)

Discussion[edit]

  • Symbol support vote.svg Support as an external ID so long as there is only one possible short URL domain (w.wiki) that the WMF provides. Mahir256 (talk) 15:42, 3 April 2019 (UTC)
  • Symbol support vote.svg Support --Mehman 97 16:08, 3 April 2019 (UTC)
  • Symbol support vote.svg Support ~ Nahid Talk 16:22, 3 April 2019 (UTC)
  • Symbol support vote.svg Support -- Ajraddatz (talk) 18:21, 3 April 2019 (UTC)
  • Symbol support vote.svg Support preferably as external ID; do you have a reference on what characters are allowed in the URL's (i.e. no upper-case letters, no '-', _', etc?) ArthurPSmith (talk) 18:55, 3 April 2019 (UTC)
    Hmm, the '$' ID listed on the documentation page already breaks this regex. ArthurPSmith (talk) 18:57, 3 April 2019 (UTC)
    That appears to be a one-off, so I'd add a constraint-exception. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:24, 3 April 2019 (UTC)
  • How many items for distinct single pages on WMF projects do we have? I feel like this property would only have about 15 uses total... --Yair rand (talk) 20:54, 3 April 2019 (UTC)
  • Symbol support vote.svg Support as external-id NMaia (talk) 02:00, 4 April 2019 (UTC)
  • Symbol support vote.svg Support as external-id. ··· 🌸 Rachmat04 · 06:23, 4 April 2019 (UTC)
  • Symbol support vote.svg Support David (talk) 07:09, 4 April 2019 (UTC)
  • Symbol support vote.svg Support though it seems only stewards will manage the URL themselves.AldNonUcallinme? 13:00, 4 April 2019 (UTC)
    • Not so, any editor in good standing (i.e. not blocked on meta) may create a short URL using this service; only stewards may delete them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:59, 5 April 2019 (UTC)
  • Symbol wait.svg Wait Will this be used as a qualifier for links to wikimedia sites? It seems the current proposal doesn't address whether or not that's intended. ChristianKl❫ 07:58, 5 April 2019 (UTC)
  • Symbol support vote.svg Support external identifier John Samuel (talk) 18:19, 5 April 2019 (UTC)
  • I have to echo the concern of Yair Rand: I don't see enough usage beside few designated shortcuts: rest are randomly created. — regards, Revi 04:57, 6 April 2019 (UTC)
    • You don't see "enough usage" because the service is not yet live. As my proposal says, it is due to launch on 11 April. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 06:58, 6 April 2019 (UTC)
      • I don't think we should be storing all the short links for all the wikidata articles, all the wikipedia articles, and then we only have a limited small set of link. That qualifies for "not enough usage", IMO. (In case someone has uncertainty in my comment, interpret my message as firm no.) — regards, Revi 14:45, 13 April 2019 (UTC)
        • Where has anyone proposed "storing all the short links for all the wikidata articles [and] , all the wikipedia articles"? Regardless, it has already been established that there will be more then sufficient short URLs ("1000 or more"), relevant to storage in Wikidata, to justify a new property. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:51, 13 April 2019 (UTC)
  • Pictogram voting comment.svg Comment seems unclear how this should be used. In general, I think redirecting urls should be avoided. If this property just repeats the interwiki link table (Special:Interwiki), that table might be worth being stored directly. --- Jura 17:25, 7 April 2019 (UTC)
    • "In general, I think redirecting urls should be avoided." The Wikidata community; the wider Wikimedia commmunity, and the WMF all seem to disagree with you. To reiterate: The official WMF URL shortener is due to launch on 11 April. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:44, 7 April 2019 (UTC)
  • Symbol oppose vote.svg Oppose Pictogram voting comment.svg Comment @Pigsonthewing: I support the short URL extension and think it will be useful, but I'm not as sure about the proposed property. As written, the property is to be used on the Wikidata items for the projects/sites which the URLs redirect to, rather than the Wikidata items which describe the same entities as the pages which the URLs redirect to (and I suspect it might end up getting incorrectly used for the latter, including people pointlessly generating short URLs for Wikidata items and then circularly adding those short URLs to the Wikidata items). Almost none of the possible IDs will ever have their own items (e.g. "Alan Turing's English Wikipedia article" probably doesn't need an item), and because the targets are limited to pages within the Wikimedia projects, only notable parts of the Wikimedia movement (e.g. Women in Red) would ever get IDs in the first place. Furthermore, the use of a property for this is sort of pointless given that WMF owns and operates the actual database. It doesn't actually seem to have much utility, other than to advertise that the URL shortener exists. (By the way, The Guardian article ID (P6085) – the only existing property for short URLs – is still nominated for deletion for related reasons.) Jc86035 (talk) 17:02, 8 April 2019 (UTC)
    I've struck out the oppose, since a majority of the current short URLs are now redirects to current or possible project home pages. Jc86035 (talk) 17:07, 13 April 2019 (UTC)
  • Pictogram voting comment.svg Comment I agree with those who think this might be confusing, though I'm not withdrawing my "support" vote above as it still seems a useful thing to record within Wikidata. I would note that per Yair rand's question which Andy failed to answer in a reasonable manner, there is a wikidata entry for every language wikipedia (for example Albanian Wikipedia (Q208533)) so that, with the wiktionaries, wikisources, etc. probably adds up to 1000 or more. ArthurPSmith (talk) 18:20, 10 April 2019 (UTC)
    • Alert readers will note that I had already addressed that point in my answer of 10:05, 4 April 2019; in the light of which, my subsequent answer was perfectly reasonable. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:40, 11 April 2019 (UTC)
  • @ChristianKl: I don't understand your comment about waiting. Can you clarify? As I noted just above, the main purpose I see for this property would be to add this property as a statement, for example Albanian Wikipedia (Q208533) with value whatever the shortener ID for "https://hy.wikipedia.org/" is. This seems particularly useful as the shortener works in one direction (from the shortened ID to the wikimedia page) but there's no obvious reverse, so Wikidata could provide that at least for these main pages.
  • @Yair rand: You didn't state an opinion for or against here, do you have anything further to comment, given that this should be applicable to 1000+ wikidata items? ArthurPSmith (talk) 19:27, 12 April 2019 (UTC)
    • @ArthurPSmith: Wikidata contains plenty of links to Wikimedia websites. It's possible to add a WMF short URL link whenever there is such a link as a qualifier. This discussion till now has had no position on whether adding the property as a qualifier should be allowed. ChristianKl❫ 15:09, 14 April 2019 (UTC)
    • I'm going to abstain on the main proposal (I'm unsure about the value of listing shortened URLs in general), but I Symbol oppose vote.svg Oppose using this instead of or in addition to normal links in qualifiers/references. --Yair rand (talk) 18:23, 14 April 2019 (UTC)
  • Symbol oppose vote.svg Oppose WMF already decided to store this elsewhere, similarly to their other short-url scheme. As stated before, Wikidata doesn't generally store url shorter addresses. Besides, there don't seem to be enough uses for these, unless someone makes them for every item (I doubt that is desirable). --- Jura 06:35, 13 April 2019 (UTC)
    • "WMF already decided to store this elsewhere" is, of course, irrelevant to Wikidata - which in any case already has properties for other data which the WMF stores elsewhere. That the quantity of values relevant to our items will be in at least four figures has already been established. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:15, 13 April 2019 (UTC)
      • @Pigsonthewing: Pardon, but is your "WMF already decided...irrelevant to Wikidata" meaning that, in one day future, Wikidata should be splitted from WMF (not only we should have separated server clusters, but also build Privacy Policy, Terms of Use, Code of Conduct... ourselves)? --Liuxinyu970226 (talk) 22:08, 27 May 2019 (UTC)
  • @Pigsonthewing: I've used a shell script to create most of the possible homepage redirects (1,594, although this includes 653 Incubator, Beta Wikiversity and Multilingual Wikisource projects, other currently non-functioning redirects and various other subdomains). I've put them in a Commons data page so that they can be imported if the property is created. Jc86035 (talk) 17:07, 13 April 2019 (UTC)
  • Pictogram voting comment.svg Comment Some possible issues:
    • Which URLs are to be treated as "canonical" (e.g. https://zh-yue.wikipedia.org/ vs. http://zh-yue.wikipedia.org/ vs. https://yue.wikipedia.org/ vs. https://zh-yue.wikipedia.org vs. https://zh-yue.wikipedia.org/wiki/頭版)? Each of these would be given different redirects by the current version of the software, and at least four variations (5k, 5m, K6 and K7) already exist.
    • How will each URL's target be indicated, if that is done? This would be helpful for more easily filtering incorrect or inappropriate values.
    • What would start time (P580) indicate as a qualifier? Would it indicate the time that the target became valid, the time that the redirect was created, or either?
    Jc86035 (talk) 17:07, 13 April 2019 (UTC)
  • Symbol oppose vote.svg Oppose I do not see the benefit of adding a dedicated property for a URL shortener - shortened URLs are URLs themselves, so why cannot we use our existing URL properties for them? It is not clear to me why URL (P2699) and its sub-properties are not sufficient. I do not think it is useful to indicate a shortened URL in addition to a longer one: by design, they are equivalent and one can easily convert one into the other, so storing both would not be very useful. Also, shortened URLs are not necessarily unique as explained by Jc86035 above - they are not designed to be used as identifiers at all. So, I very much welcome the introduction of the Wikimedia URL shortener, but I do not think this property would be useful. I also note that Pigsonthewing has been very insistently asking admins to create this property and I do not think this is appropriate. @Pigsonthewing: if you are not satisfied with the property creation delays, feel free to give a hand yourself by creating other property proposals marked as ready (there are 47 of them at the moment, so you have plenty of choice). − Pintoch (talk) 12:40, 26 April 2019 (UTC)
  • Symbol oppose vote.svg Oppose Per Pintoch. We already have properties for URLs, I do not see the benefit of adding a dedicated property for a URL shortener, although the URL shortener itself is a great tool.--Jklamo (talk) 17:23, 14 May 2019 (UTC)
  • Comment: "shortened URLs are URLs themselves, so why cannot we use our existing URL properties for them?" for the same reason we do not use them for official blog (P1581), archive URL (P1065), or interwiki prefix at Wikimedia (P6720), or any of our identifier properties with a formatter URL. We have ample precedence. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:26, 16 May 2019 (UTC)
    • Each of the properties you mention have a specific reason to be different from URL (P2699), yes. But invoking that "precedence" does not actually give a reason for this particular property to be separate - could you come up with an argument that is actually related to the proposal? − Pintoch (talk) 12:33, 18 May 2019 (UTC)
  • Symbol support vote.svg Support as external-id.--Vulphere 12:31, 27 May 2019 (UTC)