Shortcuts: WD:DP, WD:DEVPLAN
|Development plan||Usability and usefulness||Status updates||Development input||Contact the development team|
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 Wiktionary support: Task 3 - Lexeme entity type
- 2.10 Wiktionary support: Task 4 - Embedded entity type
- 2.11 Wiktionary support: Task 5 - Form entity type
- 2.12 Wiktionary support: Task 6 - Sense entity type
- 2.13 Wiktionary support: Task 8 - Arbitrary access
- 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 7 - Extending search
- 3.9 Wiktionary support: Task 9 - Link Wiktionary from Wikidata
- 3.10 Wiktionary support: Task 10 - Assess further needs after deploying interwiki links extension
- 3.11 Wiktionary support: Task 11 - Compact view for Forms
- 3.12 Wiktionary support: Task 12 - Compact view for Senses
- 3.13 Wiktionary support: Task 13 - Supercompact view for Forms
- 3.14 Wiktionary support: Task 14 - Handle multiple representations
- 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.
Wiktionary support: Task 3 - Lexeme entity type
A new entity type for Lexemes have statements and labels, but not anything else (descriptions, aliases, sitelinks).
Wiktionary support: Task 4 - Embedded entity type
Form and Sense are conceptually Entities, but they don’t have their own wiki page, they are embedded in their hosting Lexeme page. Might require a bit of refactoring in existing code.
Wiktionary support: Task 5 - Form entity type
Has a (single, not per language) Label (monolingual text), Grammatical markers, and Statements, but no Description or Sitelinks.
Wiktionary support: Task 6 - Sense entity type
Has a Gloss (multilingual text, like a Label or Description for Items) and Statements, but no Label or Sitelinks.
Wiktionary support: Task 8 - Arbitrary access
Allow Wiktionary clients (i.e. the current Wiktionary projects) to access arbitrary data from Wikidata, so the clients can do whatever they want with it (e.g. create content for Wiktionary such as flection tables, etc., or even larger parts of entries for languages that are otherwise not well supported in a given project, etc.).
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 7 - Extending search
Search on Lexemes use Language and Word type for autodescription, followed by a disambiguator if needed (i.e. See@de would be “See // German noun (1)” and “See // German noun (2)”). Alternatively, it could use the first sense description to disambiguate. Search also triggers on Forms (just as it triggers currently on Aliases for Items, e.g. type [went], find “go // English verb // Past tense: went”).
Wiktionary support: Task 9 - Link Wiktionary from Wikidata
Display appropriate links to Wikidata, based on the central Wikidata article list. Appropriate places are likely Lexemes and Forms. Note that these links are not saved in Wikidata, but generated and displayed.
Check which interwiki links remained in Wiktionary and figure out if more needs done. Probably the community will have told us what more needs to happen by now, but if it didn’t, ask and listen. Might create further tasks. This discussion about additional needs should happen after Task 1, Task 7 and Task 8 are done, or else the current situation would be discussed instead of the newly created one.
Wiktionary support: Task 11 - Compact view for Forms
The Forms sections is far too big in default view. Instead, introduce a more compact default view for Forms, that can be expanded inline. See mock-ups below.
Wiktionary support: Task 12 - Compact view for Senses
The Senses section is quite big in default view. Instead, introduce a more compact default view for Senses, that can be expanded inline. See mock-ups below.
Wiktionary support: Task 13 - Supercompact view for Forms
The compact Forms view can still be quite big (especially for Finnish verbs and similar Lexemes). Introduce a supercompact default view for Forms, that can be expanded inline to the compact view. See mock-ups below.
Wiktionary support: Task 14 - Handle multiple representations
For languages like Serbian, Uzbek, Kazakh, Chinese, etc, that use several scripts, the new structure is not ideal (but optimizing for these few languages would be detrimental for the other languages). Once we are here (say, once Task 7 is done), we need to solve the issue of multiple Representations, possibly by adding some special handling to Forms or by automatic transliteration mechanisms. The actual solutions need to be assessed and discussed with the wider community at this point (but not much earlier, so that their fit in the overall architecture can be meaningfully discussed).
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.