There are two points discussed here and while the line between them is not entirely clear, there is nevertheless agreement that:

• It is appropriate to modify existing infoboxes to permit Wikidata inclusion when there is no existing English Wikipedia data for a specific field in the infobox (option 4 of the first question). There is sufficient support for option 3 however, to indicate that this modification should be done carefully and deliberately, at least at first.
• It is, on the other hand, not appropriate to use Wikidata in article text on English Wikipedia at this time (option 1 of the second question). There is a valid point raised that while running text is clearly not suitable for Wikidata use, it might be worth discussing use in tables specifically – but not consensus regarding this has been reached in this discussion.

— Coren ^(talk) 19:21, 15 May 2013 (UTC)[reply]

Wikidata's Phase 2 deployment to English Wikipedia will occur on April 22, 2013; it has already occurred on 11 projects, and will be deployed on all other Wikipedias April 24. We need to think about if or how we will make use of the work of this sister project and how we want to interact with it now, and in the future. It should be noted, as well, that once Phase 2 deployment takes place, it will be technically possible for editors to use Wikidata's data anywhere in an article, not just the infobox; only the project's social conventions will determine whether or not any use of Wikidata's data within article text or in infoboxes is acceptable. - Risker (talk) 07:39, 21 April 2013 (UTC)[reply]

What's Wikidata again?[edit]

Wikidata is a new Wikimedia project whose objective is to be "a free knowledge base that can be read and edited by humans and machines alike...[I]t centralizes access to and management of structured data, such as interwiki references and statistical information." Essentially, it is an editable database.

Phase 1 of the Wikidata implementation is now in progress; its purpose is to manage interwiki links for articles. This implementation started on English Wikipedia in early March 2013; users may have noticed that bots made these changes on article pages they watch. At present, if it is necessary to modify any interwiki links that are already present, the change must be done on the Wikidata site, and should not be done on English Wikipedia.

The Phase 2 deployment of Wikidata is intended to permit editors to utilize the data stored in Wikidata when editing articles, in particular in completing the data fields for infoboxes. Editors and bots are currently adding data from articles and other sources to Wikidata. The long-range goal is that this data will be centrally stored on Wikidata, basically offering for structured data what Commons offers for multimedia files. This data can be used by any entity (including but not limited to Wikimedia projects). Any changes to the data would be done on Wikidata, thus permitting one edit to modify the content of a particular data statement wherever it is being used. Eventually, there is a plan to make this editing accessible directly on Wikipedia.

Phase 3 is intended to promote the use of Wikidata in list articles, and is scheduled to take place in mid- to late 2013.

How does Wikidata collect information?[edit]

Data is entered by editors and bots. Some bots extract data from Wikipedia infoboxes, categories and articles. Each article ("item" in Wikidata terminology) has a corresponding page on Wikidata, where the data resides. No alterations are made to Wikipedia when data is transferred from Wikipedia to Wikidata. Many experienced Wikipedians from dozens of projects are assisting in the development of Wikidata's database.

How far along is the data collection?[edit]

Data collection is in its infancy: many "items" (articles) have no data statements at all (only the list of interwiki links), and some have a few data statements but not all the information that is normally seen in a populated infobox. This will change as more information is transferred from the Wikipedias. Of note, a non-neglible number of title/subject conflicts have been identified during Phase I (interwiki links), not all of them easily resolvable. The Wikidata community is working out how to address these issues through requests for comment and other policy development, as is appropriate for a new project doing new things. Because most Wikidata volunteers come with extensive experience on one or more Wikimedia projects, Wikidata is considerably further along in its development than any other projects were only seven months after their first users were registered.

Reference sources found in the original Wikipedia are not able to be transferred to Wikidata at this time; several of the data types required to properly format a reference (e.g., dates, page numbers) are not available on Wikidata now (although this is an objective for the future). Some bots are adding "imported from _ Wikipedia" as the source of the information.

Does English Wikipedia have to use Wikidata?[edit]

No. Even when the Wikidata extension is deployed, no Wikipedia project is required to use data from Wikidata anywhere in their project. It is a decision to be made by each editing community. The Wikipedias that decide to use Wikidata can determine how they want to use it. The decision is ours to make. Different options are discussed below.

Feedback on Wikidata is very welcome.

In infoboxes[edit]

In article text[edit]

See also[edit]

• Wikipedia:Wikidata/Workflow
• Wikidata Phase 2 with additional links
• Wikidata Data model
• Wikidata Timeplan
• Phase 2 technical proposal at Meta
• Wikidata deployment Q&A at Meta

General discussion[edit]

• I think Wikidata holds great potential, but it's a bit rushed. I'm not sure why it's being rushed, but I get the feeling that it is.

  I think Wikidata needs more time to evolve and grow. This is obviously a balancing act: we don't want Wikidata to grow too fast and too much independent of this project. If that happens, Wikidata will likely never integrate well here. But right now, given the current user workflow issues, unless there can be some commitment made by the Wikidata team (a timeline) to fix these issues, I'd be hesitant to see us become so reliant on this project so quickly.

  The ability to easily change and monitor our site content is very important and Wikidata currently seems to be a threat to this ability. --MZMcBride (talk) 21:10, 21 April 2013 (UTC)[reply]

  Are you suggesting that Wikimedia should develop global watchlists or something similar? What nonsense is that? :) --Izno (talk) 22:43, 21 April 2013 (UTC)[reply]

  Changes to the connected Wikidata item are actually being displayed both in the recent changes feed as well as in your watchlist. This is actually one of the biggest technical challenge we are tackling, and so far it seems to work. If you watch a page, and there is a change in Wikidata, you should see that in your recent changes. This is a stronger integration than, e.g., Commons provides, where a change to an image does not show up. --denny vrandečić (talk) 09:48, 22 April 2013 (UTC)[reply]

  Is it intended to show in page histories, as well? Andrew Gray (talk) 18:01, 22 April 2013 (UTC)[reply]

• I am obviously biased, but it is my strong believe that "release early, release often" is the right way to go. The Wikidata development team listens actively to the community and I organize the development priorities accordingly. I do not know how Wikidata will be in the end, how it will look like -- but I know how to get there, which is by letting the community work with the new tools, figure out what works and what doesn't, fix issues, and continue to develop features based on the lessons learned. To wait for Wikidata to become perfect before we deploy it to the English Wikipedia simply will not work out: Wikidata can only improve when growing together with the Wikipedia communities. We will continue to keep an eye on how Wikidata is actually used, where the problems are, what kind of issues the community uncovers -- and work on them. But letting Wikidata grow on its own -- and it grows extremely well already! -- runs the real risk that the community processes and the technical systems start growing apart too much. --denny vrandečić (talk) 10:20, 22 April 2013 (UTC)[reply]

• I don't think infobox option 2 and 3 are technically possible as wikidata relies on the linked item. The subpages or the talkpage does NOT link to wikidata. The same applies to option 2 on the article text. HenkvD (talk) 18:25, 22 April 2013 (UTC)[reply]
  • I'm surprised that Denny had not pointed that out: Denny, could you please verify? My understanding is that Wikidata will go where it's put, and we've seen examples of it being linked on talk pages and Wikipedia-space pages so far (including subpages), but I could easily be wrong. Risker (talk) 18:30, 22 April 2013 (UTC)[reply]
    • Actually, I did change Option 2 accordingly, adding "(This requires that the given page also has an item in Wikidata, from where the data is being pulled in.)" As HenkvD points out, you can only display data that is connected with the given page, i.e. it is currently not possible to display the mayor of New York on the page for San Francisco. So any such test pages would need to have some respective items created. But regarding Option 3, I am not sure why this would not be possible, but maybe I misunderstand the option - HenkvD, do you mind to explain a bit? --denny vrandečić (talk) 18:38, 22 April 2013 (UTC)[reply]
      • Ah, I think perhaps HenkvD and I were interpreting things differently, and you may have a third interpretation. Testing on a subpage would probably mean copy-pasting the infobox for an article to a subpage, so it would still have the requisite content and its page name would still include the necessary data, no? Risker (talk) 18:41, 22 April 2013 (UTC)[reply]
        • Option 3 is no problem. Sorry my mistake. As for option 2: Testing on a subpage is as different as New York / San Fransisco and has in fact no information in Wikidata for thr subpage, and I don't recommend to enter test data. So adding test infoboxes on a subpage will show no data of Wikidata. I would recommend to test on the test2 system or on the demo system. HenkvD (talk) 15:49, 23 April 2013 (UTC)[reply]
          • It is possible to make a parser function that overrides the usual lookup of the related item. Possible is just that – possible. Option 2 is not a good solution anyhow. Jeblad (talk) 17:17, 23 April 2013 (UTC)[reply]
            • I am open for suggestions. Please show it on test2:Talk:Helium or test2:Helium/subpage. HenkvD (talk) 17:45, 23 April 2013 (UTC)[reply]
              • "Possible to make" does not imply that such a parser function exist or will be made, or as I just wrote "Possible is just that – possible". It would conceptually be some parser function that changed the default item to some other item, and it would probably create a lot of consistency problems. ;) Jeblad (talk) 18:38, 23 April 2013 (UTC)[reply]
                • Conclusion: Options 2 are not possible at the moment (unless somebody proves otherwise). It might well be possible when Wikidata develops. HenkvD (talk) 07:26, 24 April 2013 (UTC)[reply]
                  • Template:Wikidata value uses a trick with Expand Template, for instance {{wikidata value|Germany|47}} resulting in for instance this. Not really an easy way for users to test. HenkvD (talk) 11:17, 27 April 2013 (UTC)[reply]

• I think that the best sort of data to start with is data that doesn't change. For example date of birth or external IDs as used in {{Authority control}}. Templates could then use that data but still allow for a local override if something is included in the parameters in the article. -- WOSlinker (talk) 10:48, 23 April 2013 (UTC)[reply]
  • If we do start using Wikidata in infoboxes, can we please discourage people from using bots to import it. A lot of the data in Wikidata is frankly a mess right now and it may be a few months before things settle down and they have all the features in place for sources and qualifiers. In the meantime, we shouldn't be importing this data without careful error checking by humans. Kaldari (talk) 07:39, 24 April 2013 (UTC)[reply]
    • As long as we do not start using Wikidata data in infoboxes and surface it to many eyeballs, I do not think that a system of check and balances can be expected to ensure improvement in quality on Wikidata. I.e. if data is not used, data will get bad. Or put otherwise: less eyeballs, more errors. --denny vrandečić (talk) 08:52, 24 April 2013 (UTC)[reply]

• To me Wikidata holds potential but at the current stage there are plenty of issues before it becomes usable in WP. The biggest problems seems to coordination with various groups in Wikipedia and the handling of sources and requirements for them. Imho it requires international cooperation of the portals and projects dedicated to maintaining/managing a certain topic area in WP. Meaning for instance members of the chemistry portal need to decide how they want to use Wikidata and what requirements they on Wikidata entries themselves and their sourcing, similarly the input from portals/projects of all important other domains (math, biology, physics, history, biography, economics, sociology, ...) need to be involved. This should be international as well, i.e. ideally the chemistry editors from all large Wikipedias should settle what the Wikidata entry say for a chemical substance should look like and how it needs to be sourced. Without the involvement of those portals/projects for the various domains, there is a good chance that they will be unhappy with Wikidata and block its use in their respective domains. In addition their knowledge/manpower, which is needed to design sensible wikidata entries for the respective domains and to fill and maintain them, will be lost.--Kmhkmh (talk) 10:34, 25 April 2013 (UTC)[reply]

• I see several issues. First, Wikidata is universal across multiple Wikis, which may not have the same verification/sourcing standards as the English Wikipedia. We would need some way to reconcile or provide a lowest-common-denominator solution for when data is challenged. Second, I don't like this idea of making editors learn new interfaces. I was very much a fan of the way Wikidata phase 1 rolled out: there were bots to transfer interwiki links, and until you learned how to edit Wikidata, you could just insert an interwiki link and let the bot take care of it for you. Such a system would in many ways be similar to Infobox Option 4, but would be less burdensome to our editors. Ray^Talk 17:47, 1 May 2013 (UTC)[reply]

BLP issues[edit]

If it's agreed that Wikidata Phase 2 will be used on English Wikipedia fairly soon, BLP issues should be considered, since it appears that (a) changes to linked Wikidata items are less visible than changes to articles and (b) sourcing on Wikidata is apparently a work in progress. My suggestion would be to exclude BLPs entirely for the moment, except for (a) interwiki links (obviously) and (b) authority control data. Further rollout for BLPs should wait for more experience to develop with use of Wikidata in other areas - perhaps most obviously, if the rollout is for infoboxes initially, in location articles. Rd232 ^talk 22:07, 23 April 2013 (UTC)[reply]

• I agree. There is definitely a potential for problems with BLPs. I would favor excluding BLPs for the time being. Kaldari (talk) 07:35, 24 April 2013 (UTC)[reply]

Use of Wikidata in infoboxes[edit]

• Option 4 I think that this is the best balance of integration/innovation and responsibility here - allowing for a more gradual migration of data, and a way to opt-out. Data can be migrated over time, and the Wikidata information can then be used should local consensus find it appropriate. We have several articles on cities, highways, etc. where English is not the primary language, and where other Wikipedias have more information than we do, and I think we can benefit from this. I do think that each field should be decided by consensus wherever possible, as Wikidata is not necessarily appropriate for all enwiki infobox fields, and that consideration should be given to BLPs that may be easily vandalized. Option 4 gives us that leeway. --Rschen7754 21:02, 21 April 2013 (UTC)[reply]
• Option 4 - as part of the infobox adaptation, we may want to consider developing a "do not display" switch for some fields (consider cases where it's useful to maintain the data in WD, and the infobox supports that element, but it's undesirable to display it in the specific enwiki article). Andrew Gray (talk) 21:31, 21 April 2013 (UTC)[reply]
• Option 1 I am a Wikidata admin and have been active on the project since pretty much day one, so when I say that Wikidata simply isn't ready for this, it's not because I don't like the project, but because I have strong concerns about how developed it is currently. Simply put, I don't think that we should be deploying Phase II content to the Wikipedias when qualifiers (one of the major components to Phase II) have only just been released, several datatypes have not even been released yet, and only a tiny fraction of items have any data actually in them. Additionally, the issue of sourcing still really hasn't been addressed. Perhaps in a few months we could revisit this. Sven Manguard Wha? 21:36, 21 April 2013 (UTC)[reply]
  • Remember that coverage is patchy, but it's not completely random. For example, about 60% of the authority control entries from en and de wp have now been migrated to Wikidata; the whole set should be complete in around a week or ten days. So while we're still missing many datatypes, and content for many others, there are some datatypes like this where we have fairly significant coverage and we could start making use of it on short notice. Andrew Gray (talk) 00:02, 23 April 2013 (UTC)[reply]

• There is an option missing, and that option is: Default to Wikidata where present, but accept text where it is not. The problem with the options as laid out currently is that option 4 and this option ("4.5") are not mutually exclusive. For one field in one infobox, we might want to default to Wikidata display. For another field in the same infobox, we might want to default to local-display.

  As for whether Sven's concerns, I don't see qualifiers, sourcing, lack of data, or missing data types as prohibiting integration. For e.g. Template:Infobox book or Template:Infobox video game, there are a number of fields for a number of games for which sourcing and qualifiers are not necessary as the information is trivially obtained from the article text or otherwise. (For example, I'm not sure I've ever seen ISBN sourced....)

  Anyway, put me down for options 4, 4.5, or even 5 (if that counts option 4.5). --Izno (talk) 22:35, 21 April 2013 (UTC)[reply]

  My understanding is that 4 is the same as the one you suggest - we can default to WD display simply by removing the elements from the infobox, but override it whenever there is a local value. (This has the benefit of keeping control of use of WD with the editors of a particular page) Andrew Gray (talk) 23:42, 21 April 2013 (UTC)[reply]

  And my point is that maybe that shouldn't be allowed or necessary for some fields e.g. ISBN; is there a real need in most cases to keep it to article specific, or would it make sense to force users to edit the Wikidata item? Etc. For some fields, say gender (with persons), maybe it would make sense to be able to default to the article text as opposed to defaulting to Wikidata.

  In all, I think it should be an article-by-article and an infobox-by-infobox and a field-by-field case whether something should default to what's entered in the field or to what's on Wikidata, and that's neither captured in options 4 nor in 5. --Izno (talk) 13:50, 22 April 2013 (UTC)[reply]

• I would be more cautius and go with Option 3. In this way, we could identify and fix important issues before going to Options 4 and 5. (I am a double admin here and on Wikidata).--Ymblanter (talk) 06:44, 22 April 2013 (UTC) Now I see that my understanding of option 3 does not seem to be the same as for other users. I am striking my vote for the moment and will give to it more thought later.--Ymblanter (talk) 11:55, 22 April 2013 (UTC)[reply]
• I am not sure I understand the options as they have been. I have tried to rephrase them slightly, but keeping their gist, especially by changing Option 4 to what is here called Option 4.5 (because 4 alone makes not much sense really). I also do not really understand the difference between Option 3 and 4. In my opinion there are only 4 options:

  A) ban the use of Wikidata globally. Even if, e.g. a WikiProject decides they would like to use it, they would not be allowed. Any such change will be globally undone, and repeat offenders will be penalized.

  B) ban the use of Wikidata in the article namespace, whether directly or through inclusion or Lua invocation, but allow experimenting in other namespaces. Even if, e.g. a WikiProject decides they would like to use it, they would not be allowed in the article namespace. Any such change will be globally undone, and repeat offenders will be penalized.

  C) allow the use of Wikidata in the article namespace, but only indirectly through template inclusion. Wikidata is not to be used by a template when the relevant editor community agrees not do. Major and widely used templates should be discussed before changing them boldly. Data given locally in an article must override data from Wikidata. Also, data from Wikidata can be suppressed locally in the article. Data can be shared with other Wikipedias through Wikidata, but the local community can always override the data.

  D) anything goes, and whatever the editing community of an article or Wikiproject think is right, should be done. Usage of Wikidata data in the article directly is fine. Templates can be written in a way that they have no parameters at all, and you cannot change them locally anymore, but you always have to go to Wikidata to change it.

  I think that Option D is not really an option. I would like to ask to maybe rethink the options, before they go to the relevant notice boards. --denny vrandečić (talk) 10:07, 22 April 2013 (UTC)[reply]

  My understanding is that 3 means: we choose a particular field as a guinea pig (I do not know, say localities - then try to import data from Wikidata very carefully and see what works and what does not. Once we make sure everything works, we move to a different field and test. Option 4 to me is: Import whatever you want, but only if there were no data in the infobox before.--Ymblanter (talk) 10:16, 22 April 2013 (UTC)[reply]

  Just to add that I have no hard feelings, and for me ABCD options would work as well (then my choice would be C).--Ymblanter (talk) 10:18, 22 April 2013 (UTC)[reply]

  The difference between 3 and 4 is that with 3, the #property goes in the article itself, in the infobox parameter (so it would say |date={{#property:P22}}, whereas with 4 that would go in the infobox, with logic saying "if date= is filled in in the article, use that; if not pull from Wikidata". --Rschen7754 10:22, 22 April 2013 (UTC)[reply]

  Huh? But that would mean to actually call Wikidata data in the article, not in the template, and the template call would become even more arcane and scary than it is currently. Who would want that? We need to understand what Option 3 means before we can cast our preferences on those (or replace them with my options A-D). --denny vrandečić (talk) 10:25, 22 April 2013 (UTC)[reply]

  It means that Wikidata would be used on an opt-in basis by field and by article. I personally don't like that or think it's the best idea, and have voted accordingly, but I think it's another possibility that may be considered. --Rschen7754 10:29, 22 April 2013 (UTC)[reply]

  I understand that. But this could and should be implemented inside the template, and not on template call. --denny vrandečić (talk) 10:35, 22 April 2013 (UTC)[reply]

  Also, your understanding of Option 3 is vastly different than the one by Ymblanter, so I mantain that the options need clarification. --denny vrandečić (talk) 10:36, 22 April 2013 (UTC)[reply]

  Having talked extensively with Risker during the drafting of this RFC, I'm pretty sure that my interpretation of option 3 was what was intended by the drafter. --Rschen7754 10:42, 22 April 2013 (UTC)[reply]

  OK, then I will rephrase Option 3 accordingly to reflect that. --denny vrandečić (talk) 11:23, 22 April 2013 (UTC)[reply]

• Option 3.5. There are instances where Wikidata should not be used (e.g. to keep page histories intact), but for static data such as authority control, ISBNs, etc there are benefits to be had. I agree that Phase 2 data on Wikidata is extremely sketchy at the moment. MER-C 11:56, 22 April 2013 (UTC)[reply]
• Option 4. Why not? – Ypnypn (talk) 16:48, 22 April 2013 (UTC)[reply]
• Option 4. If implemented wisely it can work. If English wikidata will use it it will get more attention and will increase quality. (More eyeballs). Initially I opted for 1 as I thought there was too much resistance. I changed my opinion as I see more support. HenkvD (talk) 12:01, 25 April 2013 (UTC)[reply]
• Option 4. The best way to improve Wikidata is to use it as soon as possible, because if it's not used, it will never improve. That being said, I agree with Sven Manguard: Wikidata is not quite ready to be adopted on a massive scale. So I suggest we start using it on a few templates for simple data (ISBN codes) and slowly progress from there. Anything more advanced (data that requires references) can still wait a few months until Wikidata reaches a certain stability. --Iketsi (talk) 20:05, 22 April 2013 (UTC)[reply]
• Option 4 — ΛΧΣ²¹ 20:06, 22 April 2013 (UTC)[reply]
• Option 4: Local editor communities or Wikiprojects should be able to make the call, whether they want to use Wikidata or not, basically, template by template and maybe even article by article. Up to them. There should be no project-wide rule in place that disallows the usage of Wikidata, as Option 1 proposes. Option 3 sounds even worse, as it puts the call to Wikidata in the article, and thus clutters the article further instead of simplifying it. Option 2 is not as useful as it sounds, because only the data of the connected item can be called, so experiments would be extremely limited. And Option 5 is too strong: editors really should have the possibility to override Wikidata data if they want to. --denny vrandečić (talk) 20:33, 22 April 2013 (UTC) (as a member of the community)[reply]
• Option 4 - Useful and relatively safe way to deploy it. -- King of ♥ ♦ ♣ ♠ 20:51, 22 April 2013 (UTC)[reply]
• Option 3 or 4 -- of course there's a lot of stuff missing -- info is being madly copied from the English Wikipedia to Wikidata as we speak -- but I think we should play around with it in a controlled fashion, iterating as necessary. -- phoebe / (talk to me) 21:44, 22 April 2013 (UTC)[reply]
• Option 4 -- we should be encouraging people to move data over to Wikidata and we should try to use it when it's possible; this way will hopefully do that without hurting article quality in the meantime. Cbrown1023 talk 21:52, 22 April 2013 (UTC)[reply]
• Option 1 or 2 for now. I fully agree with Sven Manguard: Wikidata is not ready for this. It's not even half-ready. Premature deployment will not only create headaches, it will create hostility against Wikidata which will be hard to eliminate later on, especially if we experiment with the rationale (suggested above) that experimenting on en.wiki will be good for Wikidata. Don't get me wrong: I love Wikidata and I've worked there for the past month or two. I think it will be an excellent asset down the road. Wikidata can already be of great use (see my oh-so-fantastic suggestion) but most of its current content consists of bot-created unvetted items with unreferenced statements. If you start deploying now, people will freak out, especially people who don't know what a document-oriented database is (a group underrepresented in this discussion). Pichpich (talk) 22:02, 22 April 2013 (UTC)[reply]
• Option 1 or 2. Unfortunately, I don't feel like Wikidata is quite ready for prime-time use in infoboxes yet. For example, it currently lists the pope's occupation as 'chemist', since they don't yet have date qualifiers for claims. Give it a couple more months, and I'll likely support. Kaldari (talk) 07:34, 23 April 2013 (UTC)[reply]
• Option 4. Start with infoboxes which are on a small number of pages only. - Patrick (talk) 10:33, 23 April 2013 (UTC)[reply]
• Option 4 (or option C as Denny describes it), but I think this RFC is more confusing than necessary. The templates should be coded so data comes from Wikidata if there are no local overrides, that is option 4 will gracefully extend into option 5. That means a template with no parameters with values will use whatever it gets from Wikidata. If there are local values for some of the parameters those will be used and not be replaced with values from Wikidata. That means {{somebox}} will use whatever it can from Wikidata as long as it is implemented as part of somebox, while {{somebox|param1=somevalue1}} will use whatever it can from Wikidata except for whatever is called param1, and something like {{somebox|param1=somevalue1|…|paramN=somevalueN}} will override everything. It possible we should avoid option 3, that is we should not use involved property-calls in the wiki-code for the article itself. That will be counterproductive, we want to make the editing experience simpler for the editor, not even more convolved than today. Still note that option 3 is nothing more than using Wikidata on a case-to-case -basis, but in a crappy and counter-intuitive way. I think it is better to default to Wikidata and then override that if anything goes wrong in specific articles. It will also make it possible to shift to a simpler wiki-code as we move data to Wikidata and verifies that everything works as expected. The end result in the articles wiki-code in this case will be something simple like {{somebox}} and not something convolved like {{somebox|param1={{property:prop1}}|…|paramN={{property:propN}}}}. Jeblad (talk) 17:37, 23 April 2013 (UTC)[reply]
• Option 4. This seems the most sensible and logical way to move forwards. — Cirt (talk) 20:21, 23 April 2013 (UTC)[reply]
• Option 4: I agree that Wikidata isn't really ready yet. But the only way it will ever become ready is by these kind of almost quick-and-dirty implementations of it. Wikipedia and its related projects have always been more of a bazaar than a cathedral. Of course a more structured and cautious approach seems preferable at first. Sure there will be plenty of bumps along the road by audaciously going ahead now rather than in six months, and there will probably be much irritation between the English Wikipedia and Wikidata. But I think these are acceptable short-term losses in light of the long-term gain, and I believe that option 4 is the path forward at this time. Gabbe (talk) 09:24, 24 April 2013 (UTC)[reply]

Thank you, very well said! --denny vrandečić (talk) 09:37, 24 April 2013 (UTC)[reply]

• Option 4: This makes it very easily override-able, makes it so that the workflow for editors is not changed, but still brings in some of the benefits of Wikidata. Legoktm (talk) 10:06, 24 April 2013 (UTC)[reply]
• Option 1 - After fighting with the mess than manual insertion of inter-wiki links has become, I am pretty much convinced that WikiData is a solution in need of a problem. Carrite (talk) 19:51, 24 April 2013 (UTC)[reply]
• Option 4, largely per Gabbe. Ironholds (talk) 21:48, 24 April 2013 (UTC)[reply]
• Option 4, this is how my initial vote translates.--Ymblanter (talk) 07:22, 25 April 2013 (UTC)[reply]
• Option 4: I'm comfortable with option 4 on a per template basis (once it has been verified that the existing infobox data, including references, for each supported property has been imported at a recent date). Most of the currently supported properties aren't supposed to change very frequently. I'm very interested in later potential developments like seeing the weather and climate boxes automatically update for cities. Not to mention the rich query potential as Wikidata matures. Wakebrdkid (talk) 10:35, 25 April 2013 (UTC)[reply]
• Option 4 per Gabbe. Use it or lose it.
• Option 4 It allows people to gradually work Wikidata into Wikipedia without too many issues. And I agree with the sentiment that if we do not make use of Wikidata, it will lose interest as a project and stop growing. This is a nice easy way to ease into it while they continue to get things off the ground. Zell Faze (talk) 18:43, 25 April 2013 (UTC)[reply]
• Option 5 Interwiki data collaboration is really the way to go. Even if there is some inconvenience at the beginning, I believe tools can be made to make metadata edition even easier than it is now. Nicolas1981 (talk) 04:47, 26 April 2013 (UTC)[reply]
• Option 4 - This is a reasonable way to start, it will provide needed support and feedback to wikidata, and the long-term gain is worth the transition cost. By adding one template at a time we can start with templates where the change seems particularly useful (low-use templates, or those with good coverage in Wikidata, or those with repeated data across many pages that aren't currently well-synchronized). – SJ + 15:28, 26 April 2013 (UTC)[reply]
• Option 3 and 4 - We need to be able to make #property calls within existing templates in individual articles to try out what is works and what doesn't - and also to explain to other editors what Wikidata does. Here's one I prepared earlier as an example. Gradually, we can simplify this by forking current templates like {{Infobox country}} to something like {{Infobox country with Wikidata}} where each parameter would display the local value if it existed or the wikidata value if it did not. I've seen so many arguments about what should be in infoboxes that I have to recommend maintaining maximum flexibility for as long as possible. --RexxS (talk) 20:13, 26 April 2013 (UTC)[reply]
• Option 4. We should enable option 4 globally, and leave the decision as to whether to use it for any particular template to consensus by those editors with an interest in maintaining that template. -- The Anome (talk) 23:02, 26 April 2013 (UTC)[reply]
• Option 3 or 4. Infoboxes are already highly structured data, and I think it makes sense to share that via Wikidata where it makes sense. For example, I would like to see geocoordinates end up on Wikidata eventually. --Delirium (talk) 14:43, 27 April 2013 (UTC)[reply]
• Option 3 or 4. Infoboxes and wikidata are both designed to contain structured, standardized data, as Delirium and others have pointed out. We should at least give this a try and see if it will work. Steven Walling • talk 23:15, 1 May 2013 (UTC)[reply]
• Option 2 No reason you can't use sandbox for it. Red Slash 15:56, 4 May 2013 (UTC)[reply]
• Option 1 or 2 unless (1) Wikidata editing can be integrated into the Wikipedia interface; and (2) Wikidata is at least as well watched for vandalism as Wikipedia. No way do we want to make it more difficult to edit, and easier to vandalise. Espresso Addict (talk) 03:11, 7 May 2013 (UTC)[reply]
• Option 4 makes most sense. Many fields are left unpopulated in infoboxes solely because "it's obvious" - sometimes it's worth stating the obvious. Carlossuarez46 (talk) 06:51, 8 May 2013 (UTC)[reply]
• Option 4 As the answer to so many dreams... –Quiddity (talk) 02:08, 9 May 2013 (UTC)[reply]
• Option 3. I really think that we should start slowly on this. It makes sense to test out Wikidata, making sure that the database is both accurate and robust, before rolling it out across infobox templates. That said, I have no objection to 4 in principle, I just think that more testing and experience would be good first. Eluchil404 (talk) 05:30, 10 May 2013 (UTC)[reply]
• Option 4, or if we must, 3. I know that this will only be usable at first in a limited number of contexts, but perhaps it's time to start exploring what can be done with what we've got. I would say ... in announcing an option 4, it'd be important to set expectations of what can reasonably be done with it today. --j⚛e decker^talk 02:29, 15 May 2013 (UTC)[reply]

Use of Wikidata in article text[edit]

• Option 1 I honestly think that including Wikidata in article text is awkward at best, and is not necessary. --Rschen7754 21:05, 21 April 2013 (UTC)[reply]
• Comment - in principle I support option #1, but we need to think about definitions; I think the division here between "article text" and "infoboxes" is problematic. WD is certainly valuable for infoboxes, and it's certainly pretty silly in running text (I am really bullish about the potential for Wikidata, but I can't see a circumstance in which we'd want to insert WD elements into a sentence). However, this leaves a big gap - tables and other non-text non-infobox items. Statistically-heavy tables could make very good use of WD information (drawing the values from the WD entry for each line) but a narrowly-defined "no article text" rule would prohibit this. Andrew Gray (talk) 21:34, 21 April 2013 (UTC)[reply]
  • I could see a day where almost the entirety of an article like List of diplomatic missions in Boston is based off of information from Wikidata, but as I argue below, right now we just don't have enough actual data on Wikidata to do much of anything useful. Sven Manguard Wha? 21:39, 21 April 2013 (UTC)[reply]
• Option 1 I am a Wikidata admin and have been active on the project since pretty much day one, so when I say that Wikidata simply isn't ready for this, it's not because I don't like the project, but because I have strong concerns about how developed it is currently. Simply put, I don't think that we should be deploying Phase II content to the Wikipedias when qualifiers (one of the major components to Phase II) have only just been released, several datatypes have not even been released yet, and only a tiny fraction of items have any data actually in them. Additionally, the issue of sourcing still really hasn't been addressed. Perhaps in a few months we could revisit this. Sven Manguard Wha? 21:37, 21 April 2013 (UTC)[reply]
• Absolutely option 1 per both the workflow concerns and the "unnaturalness", except plausibly for testing in infoboxes (as opposed to embedding the information in the templates themselves) or other natural data elements such as Andrew Gray points out. On the note of unnaturalness, I am willing to bet (and probably lose :) that the Wikidata devs have not considered how it will mesh with the current parser and WYSIWYG editor work that is ongoing. --Izno (talk) 22:38, 21 April 2013 (UTC)[reply]
• Option 1, way too early to discuss anything else.--Ymblanter (talk) 06:45, 22 April 2013 (UTC)[reply]
• Option 1 per above. MER-C 11:57, 22 April 2013 (UTC)[reply]
• Option 2; what does it hurt to let people experiment? However, I don't think we should ever go to 3 – it's too confusing for editors. (Lists and tables would be an exception.) – Ypnypn (talk) 16:50, 22 April 2013 (UTC)[reply]
• For now Option 1. As Sven Manguard. Option 3 would be a possibility in the future, but at this moment Wikidata is too unstable. HenkvD (talk) 18:40, 22 April 2013 (UTC)[reply]
• Option 1 — ΛΧΣ²¹ 20:05, 22 April 2013 (UTC)[reply]
• It's not really article text and it's not really an infobox template either: I would like to use it in {{Commons category}}. Already did some harvesting over the last couple of weeks. Multichill (talk) 20:30, 22 April 2013 (UTC)[reply]
  • I agree; {{Attached KML}} is another possibility too. --Rschen7754 21:38, 22 April 2013 (UTC)[reply]

    • yes, that would be nice; those templates have more in common with infoboxes than text though. -- phoebe / (talk to me) 21:46, 22 April 2013 (UTC)[reply]

• Option 1 - No clear plan on how it is to be used. I'm afraid it'll just turn into a mess. -- King of ♥ ♦ ♣ ♠ 20:52, 22 April 2013 (UTC)[reply]
• Option 1, maybe 2 for experimentation purposes. -- phoebe / (talk to me) 21:46, 22 April 2013 (UTC)[reply]
• Option 1, maybe 2, like Phoebe. I feel like someday we might want to use Wikidata in article text to keep information up-to-date and valid, but it would make it too hard for new users to edit and overly complicate editing. It makes to use Wikidata calls in infoboxes which are complicated and include may parameters already, but that is not the case with article text. Cbrown1023 talk 21:53, 22 April 2013 (UTC)[reply]
• Option 1 see my comments in the infoboxes section but to summarize: Wikidata is not even remotely ready for this and ignoring this will create ill-will towards Wikidata. Pichpich (talk) 22:07, 22 April 2013 (UTC)[reply]
• Option 0 as there are no work done on how something like this should integrate with the text at all. In some cases it is possible to create templates to make it easy to use data from Wikidata in running text. In other cases it is not only difficult but impossible. One reason is that we don't have any working system for inflection and that makes it simply impossible to reuse a lot of the data in contexts where inflection of the value strings are necessary. Distinguishing between those cases and creating rules seems to be premature at the best, but perhaps I could go for something like "avoid exposing the editor to anything more than ordinary templates" and then see what will happen over time. I think we (we as in the community on all wikimedia projects) want to use data values from Wikidata in running text at some point, but we don't want the complexity in the present calls, and we want a simple way to impose inflection rules. Just to make it clear, inflection rules are slightly more than the built in grammar, plural and gender. Jeblad (talk) 18:09, 23 April 2013 (UTC)[reply]

Since we are talking about the English Wikipedia here, the necessity for inflexion is not that important. I still think that limiting the use of Wikidata to templates would make sense, they shouldn't be in the article text directly. --denny vrandečić (talk) 18:51, 23 April 2013 (UTC)[reply]

I am pretty sure we will run into problems with inflection even on English Wikipedia. Anyhow, we should know more about what works and what not before anything is decided on use of this in running text. I guess I would like to see good examples on whats possible before I make up my mind on running text, but I guess I'm in favor of allowing use of data form Wikidata in templates and not only infoboxes. Wikidata can for example be used for spelling forms on other languages, this is the label and the form should be good enough for this use. We can also use Wikidata for birth and death dates, this should not create any problems. There are probably a number of similar templates that can be made that reuses data for specific purposes and doesn't need working inflection rules. Jeblad (talk) 02:56, 24 April 2013 (UTC)[reply]

• Option 2. Quite helpful to let people try new things out and then move from there hopefully. — Cirt (talk) 20:23, 23 April 2013 (UTC)[reply]
• Option 1. Not never, but not now. Let's see what happens with infoboxes first. - Dank (push to talk) 12:59, 25 April 2013 (UTC)[reply]
• Option 1 Wikidata is best used for Infoboxes. After that is done and we have some experience, lets decide what to do next. Personally I don't see Wikidata integrating well into article text at all, but maybe with Visual Editor that will change. Either way, its too early to be looking at this. Zell Faze (talk) 18:45, 25 April 2013 (UTC)[reply]
• Option 3 I can imagine some topic-focussed WikiProject starting to experiment with this, making it easy to keep information coherent on many Wikipedias. Example: The exact proportion of metal in each asteroid is not something you would put in an infobox (too much of a detail), but it is worth having in the body of the article, and this information changes often with new research, so WikiData would be a great way to keep this coherent across all wikipedias. Nicolas1981 (talk) 05:03, 26 April 2013 (UTC)[reply]
• As Multichill notes, some sort of experimentation outside of infoboxes is useful. Is a RfC consensus needed to allow personal experimentation? – SJ + 15:33, 26 April 2013 (UTC)[reply]
• Agree with SJ - how would I be able to look at the implications for list articles if I couldn't experiment somewhere on en-wp? At present, I could probably make something like List of works by JS Bach from what is available on Wikidata, but it would be almost entirely a Lua call and many might say that List of compositions by Johann Sebastian Bach already exists and is comprehensive. But then very similar code could create Rihanna discography with auto-updating across all Wikis as Wikidata is updated. There are many philosophical debates to be had before we know where we are going, and we need testbeds to explore the issues. --RexxS (talk) 20:30, 26 April 2013 (UTC)[reply]
• Option 1, for now. Let's start with infoboxes first, and see how that goes before we start on using Wikidata within article text. -- The Anome (talk) 23:07, 26 April 2013 (UTC)[reply]
• Option 1, on the basis that I think we should get to the stage where we are comfortable with option 5 in infoboxes before we start basing entire lists on Wikidata. —WFC— _{FL wishlist} 16:07, 27 April 2013 (UTC)[reply]
• Option 1 The current implementation, putting opaque property identifiers with bizarre alphanumeric names in to wiki pages, is deeply confusing and unfriendly to editors of all stripes. Steven Walling • talk 23:14, 1 May 2013 (UTC)[reply]
• Option 2 No reason you can't sandbox it. Red Slash 15:56, 4 May 2013 (UTC)[reply]
• Option 1. No way do we want to make editing more difficult. Espresso Addict (talk) 03:12, 7 May 2013 (UTC)[reply]
• Option 2 Testing is good, and limited use in articles is likely, but not immediately desirable. If we end up with exact {Population of Canada} figures in the infobox, it would eventually be smart to use the same within the article's text. –Quiddity (talk) 02:08, 9 May 2013 (UTC)[reply]
• Option 2 Test/use it starting with simple things like Wikipedia:Authority control. (In many ways it is similar to Interwiki links which were replaced easily) --Nizil (talk) 07:13, 13 May 2013 (UTC)[reply]