# Wikidata talk:Development plan

## Easier sourcing

I don't want to pile on even more work, but would it be possible to add a UI-function "Copy source to other statements". Sometimes one source can be added to all statements within an item and it would be practical to only fill in the fields once. It might be something similar to bene's bot that moves the links from one item to another. --Tobias1984 (talk) 16:35, 22 January 2014 (UTC)

I think this is something best done in a gadget for now. --Lydia Pintscher (WMDE) (talk) 16:38, 22 January 2014 (UTC)

## Phase 3

What happend to WD, phase 3? WD:INTRO says: "The third phase (lists) will allow the automatic updating and translation of list articles. Planned deployment of this phase on Wikidata is in late 2013." Have the plans changed? --Kolja21 (talk) 00:55, 23 January 2014 (UTC)

That is basically the "Complex Queries" part. The plans had changed in so far that Denny quite some time ago decided that it was important to spent more time on datatypes and so on first before moving on to queries. --Lydia Pintscher (WMDE) (talk) 08:39, 23 January 2014 (UTC)
I have also been very curious about this "delay" in implementing "Phase 3" and am sorry to hear this, because this means that we will probably again need to cope with the template and bots maze for Wiki Loves Monuments in September 2014. I cannot wait for the moment when all those monuments could be managed on Wikidata and their lists on Wikipedia would be merely generated from that data. --Blahma (talk) 17:02, 31 January 2014 (UTC)
When Wikidata is not ready for complex queries, tools like WDQ are. GerardM (talk) 14:48, 22 March 2014 (UTC)
Am I correct in assuming that this is now possible and we can prepare Wiki Loves Monuments to run off Wikidata in September 2015? Jane023 (talk) 18:12, 19 April 2015 (UTC)
@Jane023: Hey, this feature is not officially implemented in Wikidata yet but the WMF is working on a SPARQL query service. However, for the time being a tool on labs called Wikidata Query is already able to handle complex queries. See https://wdq.wmflabs.org/ for more information. -- Bene* talk 20:34, 19 April 2015 (UTC)
OK Thanks Jane023 (talk) 20:53, 19 April 2015 (UTC)

## Relationship with Wikidata Toolkit

Lydia, how does the 2014 development plan take into consideration the work planned for Wikidata Toolkit by Markus Krötzsch and his group at TU Dresden? Emw (talk) 02:00, 23 January 2014 (UTC)

We will be meeting in-person next month to figure out all details and discuss exact plans. --Lydia Pintscher (WMDE) (talk) 08:40, 23 January 2014 (UTC)
Exactly. We are in close contact. Wikidata Toolkit is just about to start (the link points to the new homepage!), so it would be too early to plan with it right now. We hope that the toolkit can also help with todos of the core team, but we first have to get properly started. --Markus Krötzsch (talk) 14:42, 31 January 2014 (UTC)

## Mono-lingual text datatype

something similar should be done for these too [1]

Those are basically sound files? They can already be used on Wikidata with the Commons Media datatype. I don't know if there is a property for it already. --Lydia Pintscher (WMDE) (talk) 08:41, 23 January 2014 (UTC)

Isn't the mono-lingual text datatype the same as the string datatype we already have, and use in many properties? The thing which is missing is to have a text for each language, same as the label and description, but as a datatype, what is listed in the "Multi-lingual text datatype" section. The entry on bugzilla describes this multilingual datatype, but names it mono-lingual. Guess the confusion is that Mono-lingual could both mean "text in only one language" or "one text for each language". Ahoerstemeier (talk) 11:04, 23 January 2014 (UTC)

It's not the same thing as string. It is string with a specific language attached. The multilingual one is this then but with several strings and languages. --Lydia Pintscher (WMDE) (talk) 12:44, 23 January 2014 (UTC)
Do we really need the mono-lingual text datatype ? Actually we can solve this case by adding the langage as qualifier. Better stop the development of the mono-lingual text datatype and develop the multilingual datatype which has no solution. Snipre (talk) 12:54, 23 January 2014 (UTC)
For a city motto property which has official versions in three different languages you want monolingual datatype with three values. You do not want people coming up with their own translations. For a comment or description property you want multilingual datatype - here you do want people coming up with their own translations. Filceolaire (talk) 20:47, 23 January 2014 (UTC)
@Snipre: Language in the qualifier also had the disadvantage that certain properties would have 300+ statements. That would certainly explode the current UI. --Tobias1984 (talk) 08:33, 24 January 2014 (UTC)

## Simple queries

Statement "The returned result only includes items where the statement is marked as preferred" heavily restricts the usefulness of such requests, given that the current instructions from Help:Ranking indicate that "preferred" is only required when more than one statement is present for a given property... LaddΩ chat ;) 23:56, 23 January 2014 (UTC)

Is there a development item for linking WD to WP redirects, re. Wikidata:Project_chat/Archive/2014/01#redirects ? LaddΩ chat ;) 00:17, 24 January 2014 (UTC)

## Statements on Properties

Will this include 'Sub-property of'?
It would be nice to be able to define this even if we don't have the facility to do a search 'including sub-properties' at this stage. 85.133.32.70 13:59, 24 January 2014 (UTC)

There might be a way to do that using string then. To do it properly though we'd need a datatype that lets you link to other properties. We don't have that yet and it is not yet on my roadmap. --Lydia Pintscher (WMDE) (talk) 22:56, 24 January 2014 (UTC)

Being able to define a (multilingual) label for the inverse property would be nice too.

For symmetric properties it would be nice to be able to specify that a property is symmetric. 85.133.32.70 14:19, 24 January 2014 (UTC).

Adding that as a statement will be possible. --Lydia Pintscher (WMDE) (talk) 22:56, 24 January 2014 (UTC)

## Geo-shape datatype

Open street maps seem to already have these. Would a better solution be to link to their geo-shapes, maybe with a link to go there to edit it?
Storing the geoshapes on wikidata would (IMHO) lead to us having geoshapes which at are either a duplication of their data or something worse than their data (out of date or vandalised). Even if their was some conceivable way that we could have better data than OSM it would make more sense (IMHO) to transfer the data to OSM and let them curate it. 85.133.32.70 14:08, 24 January 2014 (UTC)

The projects are not overlapping 100 %. A lot of data on OSM is not notable enough to be included here (e.g. address of a restaurant). On the other hand we have lots of maps that are not in the scope of OSM (e.g. geographic distribution of certain animals). For the overlapping data we can do cross-checks which will improve the quality of open-access data. --Tobias1984 (talk) 16:14, 24 January 2014 (UTC)
It'is very important to have geo-shape data, many official sources relase it with free license, it can help a lot to mantain data integrity especially for admistrative divisions and places, and we can't import OSM data because we have a different license --Rippitippi (talk) 20:32, 24 January 2014 (UTC)
Right. Obviously work will have to be done to define where the boundaries are and make sure we work closely together with OSM. --Lydia Pintscher (WMDE) (talk) 22:57, 24 January 2014 (UTC)

## UI redesign

Is there any chance that the UI redesign will include the option to display statements for which the current item is the object? i.e. statements on other item which link to the current item.

A function where infoboxes can import those statements would be nice too. It would pretty much mean that we can get rid of inverse properties. 85.133.32.70 14:15, 24 January 2014 (UTC)

At least initially not. In the future maybe. --Lydia Pintscher (WMDE) (talk) 22:58, 24 January 2014 (UTC)

## Simpler JSON API

Is there any chance we can get an easier JSON API than the current one? It would be wonderful if you don't have to look up property names and stuff and you can simply do something like this:

   curl "http://wikidata.org/item/Q42"
{
"statements" : [
{
"property_id" : "P31",
"property_name" : "instance of",
"property_value" : "human"
}
]
}


I know it's not as easy as this (because you can get multiple values for a property, etc.), but i guess re-use of the Wikidata data would be greatly enhanced by a simpler API. Husky (talk) 10:25, 28 January 2014 (UTC)

Hey :) It's currently not on the plan but I will bring it up for discussion. --Lydia Pintscher (WMDE) (talk) 10:41, 28 January 2014 (UTC)
Thanks Lydia! Let me know if you need me to make some more examples. Husky (talk) 10:54, 28 January 2014 (UTC)

## Translation?

Hi, thanks for putting this roadmap up :)

Any objection to enable Translation on it? I know some folks very interested in this but not able to parse English well enough :)

Cheers, Jean-Frédéric (talk) 10:31, 3 February 2014 (UTC)

If anyone wants to actually put the time into translating it, sure. However so far I have not heard requests for translations so I am not sure if it is worth spending the time on it. But please go ahead if you want to do it :) --Lydia Pintscher (WMDE) (talk) 11:02, 3 February 2014 (UTC)

## Crowd-funding

For some of the features it might be necessary to hire more developers. Why not advertise that and try to get some kind of a crowd funding thing running. I am sure our 12000+ community could come up with a years salary for someone. It is certainly in the interest of the community that the development team doesn't shrink. --Tobias1984 (talk) 11:28, 3 February 2014 (UTC)

We have hired Adrian and Thiemo to help out with the UI for example. I'd rather continue to find corporations and non-profits as sponsors for now and not also beg the community for money. You're awesome handling the data already ;-) If we get into the situation where this is really necessary I will consider it though. --Lydia Pintscher (WMDE) (talk) 18:31, 10 February 2014 (UTC)

## Formula datatype

I think we should also consider a datatype that can handle complex mathematical and chemical formulas. The current solution with inserting unicode lower and upper case letters is more than unsatisfactory. For example the mineral albite (Q182264) currently looks like this:

• NaAlSi₃O₈

but even with unicode characters the chemical formula is not very intelligent. It is for example not aware of what it is made of. A link with a material used (P186) relationship to every element would be ideal (Because the chemical is made from elements):

But of course the markup has to include a lot more things. I think with some adaptations we should be able to use or even import data from en:Chemical Markup Language and en:Mathematical Markup Language.
We have to think early enough about this otherwise we will loose a lot of computational capabilities in our queries. Currently I don't see a way how a query could answer the question "how many silicon atoms in one formula unit of albite". --Tobias1984 (talk) 16:45, 10 February 2014 (UTC)

It seems to me that this is something that should (at least initially) be done by a gadget. --Lydia Pintscher (WMDE) (talk) 18:28, 10 February 2014 (UTC)
Not sure it any further thought has been given to this, but there is an increasing amount of complex strings that would need a datatype, ideally 100 % compatible with Mathjax. en:Dodecahedron shows many notation styles used in geometry, that we can currently not store because of the string limitations. Or different topics ranging from symmetry and crystallography en:Cubic_symmetry#Subgroups_of_full_octahedral_symmetry, en:Cubic_crystal_system#Crystal_classes. It somehow seems simple to me that we just duplicate the string datatype, call the second one Mathjax-code and then just paste the mathjax code into the text field. Tobias1984 (talk) 20:53, 15 May 2014 (UTC)
I've filed it as bugzilla:65397. --Lydia Pintscher (WMDE) (talk) 14:08, 16 May 2014 (UTC)

## Create queries on-the-fly

Surely many queries will be complex and useful enough to be shared across all projects. But what about more specific queries, e.g. "all Polish female scientists who won the Nobel prize in a leap year"? Would we host all of these, Wikidata will become a real mess.

Why not provide a Scribunto/parser function to generate and view queries directly on articles? -- 19:47, 25 February 2014 (UTC)

Performance will prohibit this at least at the beginning. --Lydia Pintscher (WMDE) (talk) 19:49, 25 February 2014 (UTC)
Caching? -- 19:47, 14 March 2014 (UTC)
That's exactly what we'll be doing. But that is a _hard_ problem and will not just magically happen ;-) --Lydia Pintscher (WMDE) (talk) 21:50, 21 March 2014 (UTC)
As I understand the latest, there is talk about an in memory database. This sounds similar to what Magnus does with the WDQ. Would it be possible to have multiple instances of an in memory database that does share the workload ? Thanks, GerardM (talk) 18:17, 16 May 2014 (UTC)

## Phase 2 on Commons?

It would be very useful, especially for pages in the "Creator" namespace, for birth and death dates and places, and authority control ids. -- 20:17, 14 March 2014 (UTC)

This will not work until this bug is fixed. Pyb (talk) 16:15, 21 March 2014 (UTC)
But some Commons pages are actually connected to useful Wikidata items. -- 19:15, 28 March 2014 (UTC)

Wikidata:Development plan#Badges says "wikis can choose to use own icons." How do I do that? Japanese Wikipedia uses [2] for featured articles and [3] for good articles (from ja:MediaWiki:Common.js), and would like to keep using them. --whym (talk) 23:59, 18 August 2014 (UTC) @Lydia Pintscher (WMDE): sorry if this is not the best place to ask this, but I couldn't find elsewhere. And I don't prefer mailing lists for questions like this which could be repeated by others... whym (talk) 00:11, 19 August 2014 (UTC)

You can define the icon locally in css. We'll publish more detailed instructions when badges on the clients go live. I don't have them yet. --Lydia Pintscher (WMDE) (talk) 09:01, 19 August 2014 (UTC)
Thanks. Then I'll wait for the information til 21 Aug (for jawiki that is). whym (talk) 10:14, 19 August 2014 (UTC)

## Category

This page needs a category (as its sibling pages). And don't reply sofixit, I don't know Wikidata's project pages category tree. --Nemo 06:57, 6 October 2014 (UTC)

## Link FA/GA/FL templates now in TfD in English Wikipedia

Thank you! Answered there. --Lydia Pintscher (WMDE) (talk) 16:56, 22 February 2015 (UTC)

## Finishing the time datatype

I notice that support for the rest of the time datatype's eventual features (sub-day units, alternate calendars, precise ranges) is not listed on this page. Is this planned for any time soon? --Yair rand (talk) 14:48, 23 June 2015 (UTC)

Good catch. At the moment it's all still a bit fuzzy to me which is why it is not on the page. I need to fix this. I fear I'll only get to it after Wikimania. --Lydia Pintscher (WMDE) (talk) 10:11, 25 June 2015 (UTC)

## Ranges, Arrays, Maps

I just want to comment on the problem of ranges again. The quantity datatype is frequently being used to give the lower und upper bounds of a range. Example given without judgement (there is currently no consensus on how to do this):

This has 2 problems. We don't know what logical relation 2 statements have. A source could say both are true together, or that both are true individually. I am also not sure if adding the range using "+-" is a good way of handling this, because many people are adding this as standard deviation (Note that this also had problems, because it can be 1, 2, 3, ... probably 6 sigma. Without the sigma number we don't know the surface below the bell-curve, and therefor not how many values lie within the distribution). And the next problem then is that ranges have standard deviations too.

Fields in a plot are a lot like geopolygons.

It would also be nice if we could solve ranges for more than just 1-dimensional data, or at least keep it in mind, so it won't get too complicated to solve it in the future. For phase diagrams it would be ideal if the stability fields could be defined as polygons or arrays in PT-space. This is also connected to our general need for an array datatype for vectors and tensors (especially physical measurements that have an x, y, and z component).

3-dimensional data might also be important at some point, but probably farther away.

In any case if anyone is interested in doing more work on this I would be happy to do a clearer write up, or participate in the discussion. --Tobias1984 (talk) 10:34, 5 October 2015 (UTC)

Hey :) Thanks! At this point I don't think we'll work on this anytime soon but you're right we need to keep it in mind. I don't yet know to what extend we'll be able to handle this. --Lydia Pintscher (WMDE) (talk) 13:38, 5 October 2015 (UTC)
@Tobias1984: We also can envision sketching our own complex datatypes using properties and items. For example a polygon is a list of point, if needed we could create an item for polygons that needs to be stored, and create a property/qualifier to link the items to the main items, for example to store a (structured) map as a set of geopolygons. As long as the datas can be stored and we have a specification on how to store this, we can store the datas and use them in wikipedias or external projects. author talk page 14:13, 5 October 2015 (UTC)
I had a similar problem for critical data for chemical compounds. I created a special structure to store data inside an unique statement. See Property_talk:P873#Example_of_use. Snipre (talk) 15:41, 5 October 2015 (UTC)