Wikidata:Development plan/archive2018

From Wikidata
Jump to navigation Jump to search

This is an archive of the Wikidata:Development plan page from December 2018. Informations are likely to be outdated.



Done

[edit]

See Wikidata:Development_plan/Done.

In progress

[edit]

Access for remaining sister projects

[edit]

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:

  • Wikisource
    • Sitelinks on general language editions: 14.01.2014 ✓ Done
    • Data on general language editions: 25.02.2014 ✓ Done
    • Sitelinks on Multilingual Wikisource not yet (see phab:T138332)
    • Data on Multilingual Wikisource: 09.11.2018 ✓ Done
    • Edition interwiki links not done yet (see phab:T128173)
  • Wikiquote
    • Sitelinks: 08.04.2014 ✓ Done
    • Data: 10.06.2014 ✓ Done
  • Wikinews
    • 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
  • Wikibooks
    • Sitelinks: 24.02.2015 ✓ Done
    • Data: 22.09.2015 ✓ Done
  • Wikiversity
    • Sitelinks on general language editions: 23.02.2016 ✓ Done
    • Data on general language editions: 03.05.2016 ✓ Done
    • Sitelinks on Beta Wikiversity not yet (see phab:T54971)
    • Data on Beta Wikiversity not yet (see phab:T209208)
  • Meta, MediaWiki, Wikispecies
    • Sitelinks: 20.10.2015 ✓ Done
    • Data: 2.12.2015 ✓ Done
  • Incubator
    • Sitelinks not yet (see phab:T54971)
    • Data: 14.12.2018 ✓ Done
  • Wiktionary
    • Sitelinks: 21.06.2017 ✓ Done
    • Data on enwiktionary: 08.09.2017 ✓ Done
    • Data on other Wiktionaries: 07.11.2018 ✓ Done
  • Outreach Wiki (see phab:T171140)
    • Sitelinks not yet
    • Data not yet
  • Wikitech (see phab:T171143)
    • Sitelinks not yet
    • Data not yet

There's also phab:T171144 which consider to provide arbitrary access on all WMF wikis without providing sitelink supports.

UI redesign

[edit]

Wikidata:UI redesign input

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

[edit]
  • enforcing user-defined constraints on data input

Improved internal consistency checks

[edit]

https://phabricator.wikimedia.org/project/profile/1202/ and Wikidata:Constraint violation report input

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

[edit]

https://phabricator.wikimedia.org/project/profile/1203/

We check Wikidata's data against other databases. Inconsistencies are visible to the user when viewing an item.


Improved watchlist integration

[edit]

Wikidata:Watchlist integration improvement input

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.

Hover cards

[edit]

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

[edit]

c:Commons:Structured data

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

[edit]

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

[edit]

A new entity type for Lexemes have statements and labels, but not anything else (descriptions, aliases, sitelinks).

Wiktionary support: Task 4 - Embedded entity type

[edit]

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

[edit]

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

[edit]

Has a Gloss (multilingual text, like Description for Items) and Statements, but no Label or Sitelinks.

Wiktionary support: Task 8 - Arbitrary access

[edit]

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.).

Todo

[edit]

Automated list generation

[edit]

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

[edit]

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

[edit]

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

[edit]

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

[edit]

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.

Duration datatype

[edit]

Users can enter the duration of an event and it is formatted accordingly in years, days, or HH:MM:SS. To be determined if the datatype should follow ISO 8601.

Multi-lingual text datatype

[edit]

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

[edit]

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.

[edit]

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”).

[edit]

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.

[edit]

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

[edit]

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

[edit]

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

[edit]

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

[edit]

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

[edit]

Structured Wikiquote

[edit]

m:Wikidata/Development/Wikiquote

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

[edit]

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.

Withdrawn

[edit]

Simple queries

[edit]

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

[edit]

Querying for sources or qualifiers

Things to keep in mind

[edit]

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.