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* ^t_a^l_k 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

Tracked in Bugzilla
Bug 65397

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 made from material (P186) relationship to every element would be ideal (Because the chemical is made from elements):

• Na Al Si₃ O₈

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? --Ricordisamoa 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? --Ricordisamoa 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?

Tracked in Bugzilla
Bug 47930

It would be very useful, especially for pages in the "Creator" namespace, for birth and death dates and places, and authority control ids. --Ricordisamoa 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. --Ricordisamoa 19:15, 28 March 2014 (UTC)

Badge icons

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

And there is a discussion about the content of this page: en:Wikipedia:Templates_for_discussion/Log/2015_February_16#Template:Link_FA. -- Magioladitis (talk) 14:11, 22 February 2015 (UTC)

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

• https://www.wikidata.org/w/index.php?title=Q18353501&type=revision&diff=254785407&oldid=254785319

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  TomT0m / 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)

I needed to store multiple date ranges for multi-day events. What I came up with was to use start time (P580) as the main statement, and if the event spans multiple days, use end time (P582) as a qualifier. That way, you're not wondering which start time goes with which end time. You can then distinguish between the statements using preferred or possibly deprecated rank (if an event is postponed, say), while keeping the old dates available if required. Makes the resulting query a little more complex because you need to use p:/ps: but otherwise it works well, and a simple query only needs the main snak. GreenReaper (talk) 17:28, 20 April 2021 (UTC)

Coincidentally Extension:Wikibase EDTF has just become available, implementing Extended Date/Time Format. This may help solve some of the cases above, and those of others; albeit that an extra start/end time may still be necessary when a specific time within a day is required for a period/interval, since time-of-day is excluded for those. GreenReaper (talk) 04:42, 27 April 2021 (UTC)

2021

Will there be a development plan for 2021? Many Wikibase users are curious what they can expect out of WMDE in the near and mid term future. --Jeroen De Dauw (talk) 11:42, 27 January 2021 (UTC)

Hello Jeroen De Dauw! Indeed, the development plan for 2021 will soon be published and announced to the community. If you have any questions in the meantime please let me know. Thank you for your patience. -Mohammed Sadat (WMDE) (talk) 21:39, 29 January 2021 (UTC)

@Jeroen De Dauw: The development plan for 2021 has now been published. Cheers, -Mohammed Sadat (WMDE) (talk) 16:13, 2 February 2021 (UTC)

@Mohammed Sadat (WMDE): Thanks. Is there a way to follow progress on specific goals? I'm interested in following some of the goals (blue headers) in the Wikibase section. If there are Phab tickets it would help if those are linked, assuming there is no better way to follow progress. Jeroen De Dauw (talk) 19:40, 2 February 2021 (UTC)

Hi Jeroen De Dauw! We're in the process of creating specific tickets for the goals of the Wikibase roadmap. In the meantime, this query plus the "wikibase tag" provides an overview. We're also currently curating this wikidata-wikibase "tech focus" board since the maintenance/bug workstream for both products is exactly the same. Once those specific Phabricator tickets that we're creating for each of the roadmap goals are ready then I'll link them to the Wiki page and let you know. That should make it easier to follow our progress. -Mohammed Sadat (WMDE) (talk) 12:59, 8 February 2021 (UTC)

Already done?

I saw a tool that consumes the changestreams and looks for breaking news. Are you aware of that tool?So9q (talk) 18:01, 2 February 2021 (UTC)

Hello So9q! I'm not sure that I understand your comment, could you please rephrase it? I’m aware of the Wikipedia Live Monitor that does also take Wikidata into account. Is it this tool you’re referring to or something else? If so do you have questions around that? Thanks! -Mohammed Sadat (WMDE) (talk) 13:05, 8 February 2021 (UTC)

Citoid support

Tracked in Phabricator
Task T199197

I'm very disappointed that the finalization of Citoid support is not in the plan. This feature was part of the 2019 plan and is almost finalized there is a working version on Test Wikidata. Could you give us a status please (I can't find it in Phabricator)? Thanks. Ayack (talk) 18:56, 2 February 2021 (UTC)

I was also hoping to see more about Citoid, as adding references is quite tedious right now and it's very important to the quality of Wikidata that we have them. Nicereddy (talk) 01:49, 3 February 2021 (UTC)

@Ayack, Nicereddy: Thank you both for bringing this up. Yes, Citoid is not on the 2021 roadmap, and as Ayak already noted it was in the 2019 plan and is almost finalized. Unfortunately due to the pandemic the main person from the WMF side to move this along is not fully available. We hope that they can get back to it soon. -Mohammed Sadat (WMDE) (talk) 13:27, 8 February 2021 (UTC)

Hello @Mohammed Sadat (WMDE), it has been a year now, is there any update regarding Citoid integration please? Thanks. Ayack (talk) 09:39, 8 February 2022 (UTC)

I think Shared_Citations might be more important to solve first, and then Citoid integration which can be tracked here: https://phabricator.wikimedia.org/T199197 Thadguidry (talk) 15:36, 10 February 2022 (UTC)

@Thadguidry Citoid integration has been developed more than two years ago and is working in beta WD (example). So I think it's more important to finish what has been started than to start other projects. And by the way, Shared_Citations is not even a WD feature. Ayack (talk) 16:27, 10 February 2022 (UTC)

Hello Ayak. Thanks for your feedback. Given that Citoid integration is almost at the finish line I can understand the frustration around its delayed deployment. As you know getting Citoid into production as well as other related work falls with the Wikimedia Foundation Editing team. Unfortunately there is still no movement from their end. We will keep pushing to see if there is a chance that this work will be picked up again in the course of the year. - Mohammed Sadat (WMDE) (talk) 15:22, 14 February 2022 (UTC)

Thank you for you answer @Mohammed Sadat (WMDE). I hope they will work on it soon. Ayack (talk) 18:40, 14 February 2022 (UTC)

(Not saying this replaces proper Citoid integration, but in case folks would not be aware of the awesome User:Samwilson/CiteTool.js user-script. Jean-Fred (talk) 16:00, 10 February 2022 (UTC))

Complete work on Suggesters and selectors

It seems that the plan opens new "chantiers" without much detail on finalizing and closing old ones.

Analysis for Suggesters and selectors has shown they have several defects (or missing basic features) and only a few have been fixed.

It would be good to finalize these. --- Jura 11:31, 9 February 2022 (UTC)

Managed Wikibase hosting

I'm happy to see a commercial offering for entities in need of Wikibase hosting! Nemo 07:57, 18 February 2022 (UTC)

This project is more about killing all commercial offerings for Wikibase hosting by providing something for free than offering anything commercial. ChristianKl ❪✉❫ 14:53, 30 January 2023 (UTC)

Federated Properties 2

Re "We’ve set up an environment on Wikibase.dev where the version of Federated Properties 2 that existed at the end of our 2021 hike can be tested by institutions being recruited from the WBSG."

Hello, can you point me to any documentation of this version of Federated Properties 2. I'd be particularly interested to see any examples of SPARQL queries. Many thanks. AndyGordon (talk) 08:34, 6 March 2022 (UTC)

Sorry for my late response AndyGordon. This page has the documentation you're looking for: https://doc.wikimedia.org/Wikibase/master/php/md_docs_components_repo_federated_properties.html

It includes an example query. Let me know if you have other questions. -- Mohammed Sadat (WMDE) (talk) 11:08, 14 March 2022 (UTC)

Thanks so much! AndyGordon (talk) 11:43, 14 March 2022 (UTC)

Data Quality

A lot of data quality issues are about finding consensus on how to model data. Developing new versions of the Entity Schemas technology without engaging with the community about how to do modeling is unlikely to result in much better data quality.

One of the difference between Wikidata and Wikipedia is that many active users on Wikidata have a lot more pages on their watchlists and thus are less likely to notice discussions on Wikiprojects. Pinging Wikiprojects used to be a solution to get around this but doesn't work anymore for many Wikidata Wikiprojects because they grew over 50 members. Moving the limit from 50 to 500 might be one solution. It might also be possible to find other ways to make discussions more visible to Wikidata users. ChristianKl ❪✉❫ 14:24, 30 January 2023 (UTC)

Hey Christian,

Thanks. We did get a lot of input for example at the last Data Quality Days around Entity Schemas and looked at a lot of existing discussions since they were introduced. The next steps are going to include a lot of work under the hood to be able to make changes later that we need to do one way or the other.

Making Wikiprojects more visible has also been one of the central themes at the last Data Quality Days and we've started looking into how to approach it. I am trying to make this a priority after we've made progress on Entity Schemas. Lydia Pintscher (WMDE) (talk) 09:31, 9 February 2023 (UTC)

I thought we had a ticket already for the Wikiproject visibility issue but it seems we didn't so I created on here now: phab:T329284. Lydia Pintscher (WMDE) (talk) 13:16, 9 February 2023 (UTC)

Link relevant Phabricator tasks

Could you please link relevant Phabricator tasks for each of the priorities that we can subscribe to? Lectrician1 (talk) 18:40, 30 January 2023 (UTC)

Not all of the activities are software-driven so they don't all have tickets in Phabricator. But I'll link to tickets for the Wikidata ones where they exist. Lydia Pintscher (WMDE) (talk) 09:33, 9 February 2023 (UTC)

Rough budget?

Can someone add an order-of-magnitude budget in staff time, community dev time, and € ? Sj (talk) 16:55, 25 April 2023 (UTC)

Wishathon March 2024

The Wishathon March 2024 will be held next month. One of the project ideas being offered is a mobile front-end change for Wikidata, specifically adding statements on mobile devices. Is there any guidance for Wishathon participants on what should be done first to work on this project? (source code access, documentation, etc) Rtnf (talk) 04:25, 7 February 2024 (UTC)

In case you didn't see it, we responded here.

Marking this section now  Resolved. - Mohammed Abdulai (WMDE) (talk) 09:38, 16 February 2024 (UTC)

A long(-long)-term strategy?

Is there a long-term strategy of Wikidata development. Like, for the next 10 years? Nikolay Komarov (talk) 16:14, 13 February 2024 (UTC)

Hi @Nikolay Komarov, thank you for your question. While we don't have a granular development plan spanning the next 10 years, we do have a long-term strategy that guides our development activities. See the latest LinkedOpenData/Strategy/Wikidata

Our Linked Open Data (LOD) strategy serves as a framework, and we use it to inform our plans and priorities on an annual and quarterly basis. -Mohammed Abdulai (WMDE) (talk) 09:47, 16 February 2024 (UTC)

Thank you for the answer! It looks like something I was looking for. Nikolay Komarov (talk) 09:52, 16 February 2024 (UTC)

Reduce data redundance

@Mohammed Abdulai (WMDE): I remember that data redundance is often mentioned as one relevant problem for the growth of Wikidata, from various perspectives. I think it would be worth including some specific work of this issue in the next development plans (probably it falls under "Improve underlying technology", but I would personally judge important to see it mentioned explicitly). The issue can be approached from two perspectives: one is fixing some well-known bugs in Wikibase (these 5 ones firstly: meta:Community Wishlist Survey 2023/Wikidata/Prevent data duplication); the other is reflecting on how to improve data models in order to reduce redundancy in references (see Wikidata:Requests for comment/Duplicate References Data Model and UI) and in many other aspects (well assembled by @Mahir256: in Making Wikidata Smaller Without Reducing Information during WikidataCon 2023), including - but not limited to - MUL labels and aliases (under development: Help:Default values for labels and aliases = phab:T285156) and, in the future, also automatic descriptions using Wikifunctions (phab:T303677). Thanks in advance, --Epìdosis 16:35, 13 February 2024 (UTC)

Many thanks for highlighting that, @Epìdosis. Indeed, reducing data redundancy remains an ongoing priority for us. Currently, our focus is on addressing this issue with the "mul" step. Following this, we'll evaluate our next steps, but yes, automated descriptions using Wikifunctions looks promising. -Mohammed Abdulai (WMDE) (talk) 17:21, 16 February 2024 (UTC)