Wiktionary:Votes/2017-05/Installing Wikidata

Voting on: Requesting Wikidata access for Wiktionary. This is specifically not about how data from Wikidata should be used, merely about requesting that the extensions be installed here so that we can start exploring various ways in which it might be put to use.

Schedule:

• Vote starts: 00:00, 25 May 2017 (UTC)
• Vote ends: 23:59, 10 June 2017 (UTC)
• Vote created: DaveRoss 23:00, 25 May 2017 (UTC)

Discussion:

• Wiktionary:Beer parlour/2017/February#Proposal: Implementing Wikidata access
• Wiktionary:Grease pit/2017/May#Wikidata access
• Wiktionary talk:Votes/2017-05/Installing Wikidata

1. Support - DaveRoss 23:00, 25 May 2017 (UTC)
2. Support entirely. —Justin (koavf)❤T☮C☺M☯ 23:25, 25 May 2017 (UTC)
3. Support --Daniel Carrero (talk) 00:13, 26 May 2017 (UTC)

   I believe Wikidata is going to be installed no matter the outcome of this vote, but the community chooses whether to use it or not, and where. According to d:Wikidata:Wiktionary#Our plan, the "Phase alpha" (Automatic interwiki links on Wiktionary) was already implemented. There are still phases beta, gamma and delta to go. There's already plenty of support in Wiktionary:Beer parlour/2017/February#Proposal: Implementing Wikidata access, but I suppose this vote can't hurt. That said, I'm not really sure why we're voting already since the vote still has the yellow "premature" box. (edit: Dan Polansky removed the box) --Daniel Carrero (talk) 00:17, 26 May 2017 (UTC)

4. Support – though, like @Dan Polansky, I don't like the idea of moving translations to Wikidata, and am skeptical about moving language data there, an idea proposed on one of the discussion pages. — Eru·tuon 19:19, 26 May 2017 (UTC)
5. Support -Xbony2 (talk) 00:27, 28 May 2017 (UTC)
6. Support Don't see why not Purplebackpack89 13:39, 29 May 2017 (UTC)
7. Support I'm interested in exporting Module:Unicode_data to wikidata and be able to share it among multiple wiktionaries. –dMoberg 21:48, 1 June 2017 (UTC)

   I am not sure what do you mean. Why do you need Wikidata for this module? Note that Wikidata is about data, not about sharing scripts. --Vriullop (talk) 06:16, 2 June 2017 (UTC)

   There are numerous modules on Wiktionary which are essentially flatfile databases with access methods tacked on. The goal would be to move the data which is stored in the module to Wikidata and keep the access methods local. Language names is another example. - DaveRoss 14:19, 2 June 2017 (UTC)

8. Support I have been working in ca.wikipedia for feeding infoboxes with data trancluded from Wikidata and I am eager to start exploring the possibilities for Wiktionary prior to the major move with new lexemes thing. I think it is necessary to have the tools for adquiring habilities with new Lua functions and for testing it all. At the end we will be able to propose what can be done or to respond to user requests. I assume that any data transclusion is subject to community decision independently of this vote. FWIW I'd like to have also data transclusions on ca.wikt as a guinea pig. --Vriullop (talk) 15:44, 2 June 2017 (UTC)
9. Support --Einstein2 (talk) 11:18, 6 June 2017 (UTC)

1. Oppose. I sense a considerable potential for harm. The interwiki thing does not need Wikidata, obviously. In the worst case, the use of Wikidata could lead to transfer of Wiktionary lexicographical information into a foreign database with inflexible data models ("Starre Strukturen"), to be shared by multiple Wiktionaries. That foreign database, Wikidata, does not have a particularly pleasant interface and edit histories. Disagrements will have to be resolved in that foreign project; changes in rendered data in Wiktionary web pages will no longer be traceable to changes in Wiktionary data but rather in part to changes in data located in a foreign database. If that approach works so well, why did OmegaWiki not take off much better? --Dan Polansky (talk) 17:15, 26 May 2017 (UTC)

   While I respect your concerns (I share most of them) this is specifically not about how we will use it, merely giving us the flexibility to understand how we might make use of data which is already there, etc. Even if access to Wikidata was implemented, we are under no obligation to use it, or to adopt any of the policies or changes which other projects propose. - DaveRoss 17:20, 26 May 2017 (UTC)

   I believe any large project of moving data to Wikidata would require a vote. For example, I think it would be great to use Wikidata to get information (senses and categories) for all our place names. Other projects may be discussed separately. --Daniel Carrero (talk) 17:32, 26 May 2017 (UTC)

   For one thing, I do not want Wiktionary wikitext littered with numerical identifiers like in diff; that is:

   {{trans-top|nautical instrument|Q427293}}.

   Ditto for definition lines.

   Once Wikidata is installed, Wikimaniacs who have not yet been prevented from making large-scale non-consensual changes will have the technical means to roll out en masse things I disagree with. --Dan Polansky (talk) 17:44, 26 May 2017 (UTC)

   You linked to an edit in the translation table: {{trans-top|nautical instrument|Q427293}}. Apparently the template does not use the 2nd parameter for anything so it's useless (it was rightly reverted).

   I think I see some potential for use of numerical identifiers everywhere. 1) it could replace senseids if people want, 2) I would be happy to replace whole place name definitions with something like {{place|Q1234567}} (or {{place|Q1234567|lorem ipsum}} where "lorem ipsum" is a comment only visible in wikitext). --Daniel Carrero (talk) 17:58, 26 May 2017 (UTC)

   It reminds me of my job where I can never remember what is what since it is hidden behind a numerical ID. It is certified ugliness. -Dan Polansky (talk) 18:02, 26 May 2017 (UTC)

2. Oppose We shouldn't install it if we don't know how we're going to use it. --WikiTiki89 17:57, 29 May 2017 (UTC)

   Counterpoint: it is a lot easier to figure out ways in which it might be used if we are able to test it out. It would also be nice to be able to create examples and demonstrations of possible uses so that we can vote on them after they are functional. - DaveRoss 11:57, 30 May 2017 (UTC)

   Just an example w:ca:User:Vriullop/proves/Balaena mysticetus. It is intented to be a template for filling hypernyms of taxonomic names from Wikidata. Coding a module for Wikidata is tricky, it needs use cases and a lot of time. --Vriullop (talk) 19:13, 30 May 2017 (UTC)

   Then that's what the vote should have said. --WikiTiki89 17:17, 30 May 2017 (UTC)

   That is what the vote says: "...so that we can start exploring various ways in which it might be put to use". - DaveRoss 17:50, 30 May 2017 (UTC)

   It should have been made clear that any permanent use of it would still need to be voted on. --WikiTiki89 18:11, 30 May 2017 (UTC)

   Wikidata or not, major changes need to be voted on. Maybe it would be a good idea to be even more strict with Wikidata? If people want, we may implement this new rule: reverting on sight any and all edits that use Wikidata if they were not discussed or voted before. Just an idea. --Daniel Carrero (talk) 14:05, 1 June 2017 (UTC)

3. Oppose Per Dan Polansky. Also, IMHO, CFI needs to be updated first, as Wikidata's data, doesn't meet CFI(for example, Polish Wiktionary is mostly prescriptive, so things in Wikidata entered by Polish Wikt users might be made up non-entries that exist only because PWN dictionary and/or RJP says so; French Wikt doesn't require durably archived attestations, so some entries there are attested only by webpages and therefore don't meet English Wikt CFI and so on).Mistrz (talk) 12:37, 8 June 2017 (UTC)

   This vote is about installing Wikidata, not how to use the data. Are you under the impression that once Wikidata is installed, all the Wiktionaries will need to have the same content? Why would we want that? The French, the Polish and the English Wiktionaries may use (or not use) Wikidata for their own purposes separately. --Daniel Carrero (talk) 12:45, 8 June 2017 (UTC)

   No, but the only lexicographic data that can exist in the Main namespace is one that meets CFI; as I already pointed out, Wikidata's data doesn't meet CFI, ergo no Wikidata's lexicographic data can exist in the Main namespace, until either CFI is updated or that particular piece of data is separately attested(which kind of defeats the point, but that is a different discussion than this vote), so it pretty much boils down to installing something that either will provide useless fluff(like geotagging {{place}}) or will only be used in the user namespace… Seems pointless to me. Mistrz (talk) 13:08, 8 June 2017 (UTC)

   Sure, senses have to meet CFI to exist in the main namespace. Are you talking about using Wikidata to store senses themselves? (like using Wikidata to store the information that, say, apple is a fruit) As I said somewhere else, I'm pretty sure I'd oppose that project except for place names, which have tons of repetitive information to be shown and organized. What about book information for quotations, and language/script/family/character info for various purposes? All that can hopefully be stored in Wikidata. --Daniel Carrero (talk) 13:17, 8 June 2017 (UTC)

   I would also suggest that "useless fluff" is not the only possible data which could be usefully stored in a relational database. Much of the underlying data which powers our modules and templates either already exists in Wikidata or could be migrated there, potentially resolving issues we have been having with module memory errors, etc. It can also open up the possibility to build smarter, more robust modules which need significant data structures to operate. All of the opposing votes here seem to be about specific uses, none of which are being proposed or allowed by this vote. - DaveRoss 13:24, 8 June 2017 (UTC)

   Not just senses, for example saying that X is a synonym of Y based on data in Wikidata is also problematic, because 1)Y might not exist, but instead be a made up prescriptive term or 2)Y might not have a sense synonymous to X under our CFI and so on – almost all uses in the entries are problematic because of CFI, even for places(most place names have prescriptive names in Polish, for example, as there is special Standardisation Commission for these, but vernacular uses traditional names regardless, so most of these standard names might be hard to attest), though that might be a bit more valid use, indeed.

   "Useless fluff" is only useless in the Main – if this vote would specify that the use of Wikidata is limited to Module:, Template: and Citiations: or something like that, I would vote support instead, but to quote Dan Polansky: "Once Wikidata is installed, Wikimaniacs who have not yet been prevented from making large-scale non-consensual changes will have the technical means to roll out en masse things I disagree with." – while I not necessarily agree with the wording of the quote;), my concern is that this very vague vote will allow deploying of tens of thousands of unverified changes in the Main namespace without any policy oversight. Mistrz (talk) 14:07, 8 June 2017 (UTC)

   The synonym thing a good point. I remember we had a page called Wikisaurus:penis/more (now deleted) with 18kB+ of words supposed to be synonyms of penis, most of them seemed to be protologisms. Maybe we shouldn't use Wikidata to store synonyms for us. Aside from that, as I said above, we may want to implement this new rule: reverting on sight any and all edits that use Wikidata if they were not discussed or voted before. If this vote passes and Wikidata is allowed, does that deleting-on-sight rule sound like a good idea to you? --Daniel Carrero (talk) 14:20, 8 June 2017 (UTC)

   Strictly speaking, stuff like putting something like {{wikidata|Q12345}} instead of {{l|en|something}} under Synonyms of one entry, is much less of a problem and probably can live with the current policy(as in, RFV and RFD can deal with it). My issue is more with the possibility of someone editing, for example,{{desctree}} to pull descendants automagically from Wikidata, which can potentially affect thousands of entries – we won't be able to check immediately all of that, so some wrong entries might linger for months/years (need I point to Webster 1913? ;) ), reducing the overall quality of the Wiktionary, even if the original rationale for such an edit was "Greater Good" of populating entries faster…

   I don't think there is a sensible way of reducing the risk of such change, other than simply banning Wikidata's data in the Main namespace. We could though create a separate namespace for it, where the integrity of that data could be manually checked and then pulled into Main – but that's a debate for the future, I think. Mistrz (talk) 15:40, 8 June 2017 (UTC)

   The same argument applies to all modules and templates. - DaveRoss 17:02, 8 June 2017 (UTC)

1. Abstain I presume this will come to pass whether we vote for it or not. A few of the ideas proposed for expanding what we can host on Wikidata have been good ideas; many ideas, particularly those on Wikidata:Wiktionary, are really awful and could destroy the project if brought to fruition. (Yes, I am aware of how dramatic that sounds, but very similar project have been created in the past, resulting in abject failure, for fairly predictable reasons.) The key is that we remain vigilant to ensure that there is local consensus for every significant shift of data from here to Wikidata. —Μετάknowledge^{discuss/deeds} 17:08, 5 June 2017 (UTC)

   Your assumption is incorrect: "I presume this will come to pass whether we vote for it or not." TBH, I had assumed the same thing as you. But in Wiktionary:Grease pit/2017/May#Wikidata access, @Lea Lacroix (WMDE) said "Of course, we will take your community vote into account, if the result if negative, we won't deploy anything." --Daniel Carrero (talk) 17:13, 5 June 2017 (UTC)

2. Abstain idk Equinox ◑ 17:10, 5 June 2017 (UTC)

Passed: 9-3-2 (75%) --Daniel Carrero (talk) 00:19, 11 June 2017 (UTC)

Ticket submitted. - DaveRoss 13:16, 11 June 2017 (UTC)

Actually, apparently that's redundant to phab:T159316. I copied your text as a comment in the old ticket. (to inform people that the vote happened) --Daniel Carrero (talk) 13:20, 11 June 2017 (UTC)