Shortcuts: WD:DP, WD:DEVPLAN
This is the Wikidata development plan. It is ordered by when items will likely be started but the order is not necessarily fixed. It can change depending on changed priorities.
- 1 Done
- 2 In progress
- 2.1 Access for remaining sister projects
- 2.2 UI redesign
- 2.3 Improved internal consistency checks
- 2.4 Consistency checks against 3rd parties
- 2.5 Improved watchlist integration
- 2.6 Hover cards
- 2.7 Wikimedia Commons
- 2.8 Improved user experience for referencing: Citoid support
- 2.9 Geo-shape datatype
- 2.10 Wiktionary support: Task 1 - Wiktionary interwiki links
- 2.11 Wiktionary support: Task 3 - Lexeme entity type
- 3 Todo
- 3.1 Automated list generation
- 3.2 Editing from the client
- 3.3 Infobox demos + documentation
- 3.4 Improved user experience for referencing: Nudging users about adding or changing references
- 3.5 Article history integration
- 3.6 Multi-lingual text datatype
- 3.7 Easy lookup of items by identifier
- 3.8 Wiktionary support: Task 2 - Switch on Phase 1 for Wiktionary
- 3.9 Wiktionary support: Other Tasks
- 4 Beyond the planning horizon of this plan
- 5 Withdrawn
Access for remaining sister projects
The remaining sister projects have access to sitelinks and data via Wikidata. The roll-out is staged to allow the communities to adapt. The planned order is:
- Sitelinks: 08.04.2014 Done
- Data: 10.06.2014 Done
- Sitelinks: 19.08.2014 Done
- Data: 2.12.2015 Done
- Wikidata itself
- Sitelinks: 19.08.2014 Done
- Data: 19.08.2014 Done
- Commons (not including file metadata!)
- Sitelinks: 23.09.2013 Done
- Data: 2.12.2014 Done
- Sitelinks: 24.02.2015 Done
- Data: 22.09.2015 Done
- Sitelinks: 23.02.2016 Done
- Data: 03.05.2016 Done
- Meta, MediaWiki, Wikispecies
- Sitelinks: 20.10.2015 Done
- Data: 2.12.2015 Done
- Sitelinks: ?
- Data: ?
Not to be done (yet)
Reading and editing Wikidata is joyful and intuitive on desktops, tablets and mobile phones. The interface is visually pleasing, integrates nicely with other Wikimedia projects and contains no jargon. The interface provides the user with the information they were looking for quickly and does not overwhelm them (i.e. deprecated data is hidden initially and information is ordered in an intuitive way). It invites the user to add additional information (including qualifiers and sources) and offers little nudges towards making correct and useful contributions by offering suggestions. Erroneous contributions and vandalism are discouraged. Navigating and editing the website is fast. Both the data and the interface is localized in the user’s locale and language preferences. Where no data is available in a particular language a fallback is used.
Not to be done
- enforcing user-defined constraints on data input
Improved internal consistency checks
It is easy for a user to find and understand constraint violation reports. Fixing an item that violates a constraint is easy. When viewing an item with a statement that violates a constraint the user can easily spot the wrong statement.
Consistency checks against 3rd parties
We check Wikidata's data against other databases. Inconsistencies are visible to the user when viewing an item.
Improved watchlist integration
Users on Wikipedia and co need to see changes on Wikidata that affect their articles easily and comprehensively in their watchlist. This includes support for showing Wikidata changes when using the enhanced recent changes option.
When a user hovers over a link to an item a small card is shown that holds the most important information about that item.
Wikimedia Commons holds a huge amount of multimedia files available for the other Wikimedia projects and the world to use. Structured data support for Wikimedia Commons is important to make it easier to maintain the files and make reuse, especially 3rd-party reuse, easier. The structured data support comes in two ways. The first is by providing access to the data stored in Wikidata. This includes things like the date of birth of an artist. The second way is by enabling Wikimedia Commons itself to store structured data related to the files stored there. This includes things like the license and subject of a photo for example.
When a new file is contributed, the uploader is asked to provide some information like tags, creator name and license in the upload wizard. Users are able to then access and edit this structured data via a form as well as an API (similar to how it is done on Wikidata). It is easy to specify and retrieve the licensing and provenance information of a multimedia file. Additionally it is easy to tag and categorize images based on concepts from Wikidata. Tags and other file information is shown in the user’s language to accommodate the multi-lingual audience of Wikimedia Commons. All this information can be used to easily search for files that fit certain criteria like “picture of a cat and a child from 2010, licensed under CC-BY-SA”.
Improved user experience for referencing: Citoid support
A user adds one piece of information of a reference like its ISBN. The tool then automatically adds the other necessary information.
Users can link to geo-shapes in Wikidata. They can for example use it to store the outline of a country.
An extension connects pages with the same name on the different Wiktionaries to each other. It creates the set of Interwikilinks for a given page in the configured namespaces (usually the main namespace on Wiktionaries) by looking for pages with the same name on the other Wiktionaries (or more general, on other projects within a configured namespace). Then, add and overwrite with local links mentioned in the wikitext.
Wiktionary support: Task 3 - Lexeme entity type
A new entity type for Lexemes have statements and labels, but not anything else (descriptions, aliases, sitelinks).
Automated list generation
Users are able to write queries like “all poets who lived in 1982” or “all cities with more than 1 Million inhabitants”. They are entered in a page in the Query namespace and internally saved as JSON. They are then executed when resources are available - usually not immediately. The result is cached. A query can be set to rerun at regular intervals or on-demand by an administrator. The result of the query is shown on the same page. It can also be accessed via the API. The clients can include the result of a query in their pages to for example create list articles. This will enable for example to have automatically updated list articles on Wikipedia.
Editing from the client
Editors on Wikipedia and the other Wikimedia projects don't want to and should not need to go to Wikidata every time they want to edit the data their project uses from Wikidata. We need to enable them to edit the data locally on their project without having to understand a lot about Wikidata and visiting Wikidata.
Infobox demos + documentation
We provide a few demo infoboxes and good documentation for people to use as a starting point for moving infoboxes on Wikipedia towards using more data from Wikidata.
Improved user experience for referencing: Nudging users about adding or changing references
When adding a statement without a reference the editor is nudged to provide one. When a statement is changed but not its reference the editor is made aware of it and nudged to change the reference.
Article history integration
Editors on a client can look at the change history of an article and see all Wikidata changes relating to this article. This way they can see all changes affecting their article without having to go to another project.
Multi-lingual text datatype
Users can add strings and specify a language for it. This is similar to the mono-lingual string. However translations in more than one language can be provided. The one in the user’s language is shown and the others can be shown on-demand.
Easy lookup of items by identifier
Wikidata contains a lot of useful identifiers. This makes it possible to find the Wikidata item that corresponds to an external entity like a museum record. A special page makes it possible to enter an identifier and get the corresponding item back.
Wiktionary support: Task 2 - Switch on Phase 1 for Wiktionary
Once the new component from Task 1 is switched on, the usual Wikidata Phase 1 can be enabled for Wiktionary. This will allow to create interwiki links for those pages that would not be connected through the new component.
Wiktionary support: Other Tasks
See Wikidata:Wiktionary/Development/Proposals/2015-05 for details.
- Task 4: Embedded entity type
- Task 5: Form entity type
- Task 6: Sense entity type
- Task 7: Extending search
- Task 8: Arbitrary access
- Task 9: Link Wiktionary from Wikidata
- Task 10: Assess further needs after deploying interwiki links extension
- Task 11: Compact view for Forms
- Task 12: Compact view for Senses
- Task 13: Supercompact view for Forms
- Task 14: Handle multiple representations
Beyond the planning horizon of this plan
Installing Wikibase on Wikiquote and allowing structured data on this sister project has lots of advantages. However, there is also lots of work to do in the software to support all features needed for this proposal.
Access from 3rd party wikis
MediaWiki installs outside the Wikimedia cluster are able to make use of the data on Wikidata similar to how they make use of images from Wikimedia Commons via InstantCommons.
Users are able to pose simple queries to Wikidata via a SpecialPage as well as the API. Wikidata can answer queries like “What has the ISBN 2-01-202705-9” or “What has the capital Paris”. These queries are restricted to one property/value pair and return a list of items. The returned result only includes items where the statement is marked as preferred. These queries are most useful for use with one of the many identifiers in Wikidata that connect the knowledge base to other databases.
This is canceled in favor of Wikidata Query Service and the external identifier look up service.
Not to be done
Querying for sources or qualifiers
Things to keep in mind
Some data types are easier to query than others. Time, Geo and Quantity values require range queries. For the Item and String data types, simple equality is sufficient.