Topic on Talk:Wikidata Bridge/Flow

Here's the thread where you can leave feedback on the first version of the prototype.

Please note that it is a screenshot prototype, not a fully working feature: you will be guided to go from a screen to another and you won't be able to click on all links and buttons that you see on the screen. This is not the final state of the feature but a work in progress.

Do you see any problem with it? Do you have any concern to raise?

Are the texts helpful? (labels of fields, descriptions, information text)

Any other comment?

Thanks a lot!

Any other comment? On la.wikipedia, we predominantly use infoboxes that take all their content from wikidata. Since no user on la.wikipedia really knows Lua well enough to feel confident to maintain Lua code residing on la.wikipedia, we only use "normal" templates and the #statements parser function (and sometimes also the #property parser function) but do not use Lua. You can see an example infobox at la:Carolus de Gaulle.

From this perspective, I would like to emphasize two points:

• It would be great if the new system would not require Lua, as we feel we would not be able to reliably maintain Lua modules residing on la.wikipedia.
• On our infoboxes, we often see content displayed in English (serving as a fallback language), because many Wikidata labels have not yet been translated to Latin. Take for example the page la:Carolus de Gaulle and expand the "Officium" section. In the line starting with "Officium:", you will read: "president of the French Republic, President of the Council, president of the Provisional Government of the French Republic, Coprinceps Andorrae, Coprinceps Andorrae, praeses, Minister of National Defence". This comes from the P39 statements at d:Q2042. Note that "Coprinceps Andorrae" (d:Q683337) has both al Latin label and a Latin sitelink, "praeses" (d:Q1255921) has a Latin label but no Latin sitelink and "president of the French Republic" (d:Q191954) lacks a Latin label. It would be great if the new system you are planning to design and build would allow to translate such labels.

Hello, and thanks a lot for your feedback. We are aware that the lack of Lua skills among Wikipedia communities is an issue that prevents setting more efficient templates. One could think about various ways to solve it: provide better documentation in more languages, organize cross-communities trainings online or at events like Wikimania, provide global templates that everyone could use accross wikis, etc.

However, we think that this issue is independent and different from what we try to solve with the Wikidata Bridge.

Clarification: By "translate labels", I mean:

• add a Latin label if there is no Latin label, and
• change a Latin label (e. g. in case it is misspelt).

Hi, thanks to the development team for your work on this. I appreciate the tool although I worry a bit about the impact this could have on Wikidata (more vandals). We'll need a live feed of all Wikidata edits coming from eg. Czech Wikipedia so that we can keep track of it. Is this planned? Also, it would be cool if "transwiki" edits to Wikidata could only be enabled for experienced Wikidata users (eg. autoconfirmed on Wikidata).

Thanks for your feedback. We'll definitely discuss these topics on d:Wikidata:Wikidata Bridge.

As for the experienced Wikidata users requirement, we will need to find a proper solution, but the goal of the project is to help Wikipedians or newcomers who are not comfortable with editing Wikidata, to be able to do it, so it's targeting people who are not experienced yet.

Make no mistake, I am very open to newcomers and usually want Wikipedia as inviting to them as possible. I hate when all sorts of filters and roadblocks are put into place on Wikipedia. However, Wikidata are *more* difficult to understand than Wikipedia, one single edit can cause more disruption than on Wikipedia and thus Wikidata should be more careful about disruption from new editors than Wikipedia.

Let me give you a few examples of how Wikidata can be more challenging to understand. For example, in Wikidata, we differentiate between a museum building and a museum. That's something usually unseen in Wikipedia. which mixes up both concepts (which is all right for Wikipedia but wrong in Wikidata). Another example: in Wikidata you would not remove a 2018 number from population census once a 2019 figure is published (as you would do in Wikipedia) - rather, you would add a new value next to the existing one and add a proper qualifier "year".

I understand your point. The first version will also be the occasion to monitor the edits and evaluate their quality (eg how many of them have been reverted). Based on this data, we can think about improving the interface on Wikipedia, or provide better watching tools on Wikidata. Restricting the possibility to edit to a certain group of users is an option that we could consider as a last step if really needed.

When listening to Mr Denny Vrandečić I get the feeling the biggest benefits he sees of the Wiki echo system is that you have many "eyes" checking the data. I would like to see some thoughts of how a good wikiecho system works and how this piece fits in. Some examples of confused thoughts

• all edits in one Wiki infobox should be seen directly on all other language versions
• when Wikidata is changed the change is indicated in an Infobox that a diff exist
  • if there is a change it needs to be approved
  • if a change is approved in x Wikis its accepted as trusted and shown in more Infoboxes
• a change need to have a reference/source or get a higher "trust" value if it has
  • a change need to have a source that is on a trusted list of sources
• we have in Sweden done WD objects for all Swedish Church parishes GITHUB that means we try to follow a structure that a person is born or dead in one of those parishes i.e. very few other languages has labels for those items
  • any strategy to use labels when new changes will appear in more infoboxes and we have no labels
    • the change stream should indicate that we now have a new WD object appearing in your language wiki that has no label in your language

• .....

Thanks for your feedback and suggestions. Let me answer on a few points:

• The ability to watch Wikidata edits from Wikipedia already exists. If an article uses an item, then it's possible to watch the changes made on this item on one's Wikipedia watchlist.

• Approving edits a posteriori is not what we want as Wikidata is an open project. We can consider this; after deploying the first version, analyzing the usage and the quality of edits, and asking feedback from the community: if we get a strong request from the community, we could consider it for next version in the future.

• Yes, references will be part of the interface (maybe not on the first version)

• About monitoring: items without labels: it is already possible to do this by adding some extra code the template that would add maintenance categories

Here are few suggestions/feature requests:

1. Field validation on Coordinates, Altitude, Units, Data types, future field value etc. need to be take care.

2. WhatIf I have to add a new InfoBox field, which is not there? i.e. can a User/an Admin change the template of the Infobox?

3. More than 50% unique users visiting Odia Wikipedia use Smartphone. Is there any plan to bring this feature to Mobile web/Android App?

4. I see some fields are not editable. Is there any specific reasons? or How is it decided?

5. Search and upload Image feature from the Infobox directly.

Thanks a lot for your suggestions!

1. Absolutely, it will come later in the next versions

2. The template builders will be able to add new infobox fields by changing the template

3. Yes, it is planned that the feature will work on mobile web interface. As for the app, we can't promise anything, since it's a different organization taking care of it (Reading team at WMF)

4. I'm not sure that I understand what you mean. Did this happen while testing the prototype? If so, that's normal: the prototype is no fully-functioning software but only a step-by-step tool that is leading you through one only path (editing the altitude)

5. This seems way bigger than the Wikidata Bridge. It could be develop in a near to distant future.

Do you see any problem with it? No. This is really promising.

Do you have any concern to raise? No.

Are the texts helpful? Are we talking about the info labels in the infobox? They are indeed helpful. Maybe I don't understand this question. Were there talk before about removing the labels in infoboxes?

Any other comment? Thank you for your work!

Do you see any problem with it? The main flow looks right, but several details are unclear as described below.

Are the texts helpful? Why lowercase "edit" in the title? Not sure about the "Apply changes" label either - this is supposed to appear in the Wikipedia context, so it might be better to use "Publish changes", like the Wikipedia editors

Any other comment? Please make sure that the wrong/outdated strings are as flexible as possible: gender/plural/placement customizations should be possible, e.g. in Romanian you would say "altitudine greșită" (feminine), "coordonate greșite" (plural), but also "cod greșit" (masculine singular) - in all cases the qualifier comes after the label

Also, what's the workflow for multiple values (e.g. villages in a municipality) and images? What about qualifiers and sources?

Thanks a lot for your feedback! We'll take in account your comments about labels and customization.

Multiple values and qualifiers will not be part of the first version, as they are connected to various complex use cases that we need time to study. But they will be worked on in the future versions. Sources will be part of the interface as soon as possible.

I have been looking forward to it for several years and I say quite often that it will be online soon! :)

I haven't found any information about how the new system will be implemented on existing infoboxes. Will it be a special templates? By plug-ins? By Lua? Will How difficult will it be?

Or will there be a new infobox system? (no templates, standardized, easy setup eg. P131 to this line in cs lang and with/without ref) That would be best.

Thanks for your feedback!

There will be no new system, the interface will be based on existing templates, so the communities don't have to perform a big change, but rather update their templates step by step when they feel like it. We are still investigating on the best technical solution for these improved templates.

Suggestions:

• Edit icons/buttons could be easier to select and look less busy if provided in a 3rd column in Infobox tables, making the columns correspond to: field_name, field_value, edit_button.
• Edit dialog should ask for a reference to be provided for any new value provided.
• "Wrong Value" should ideally be split into "Wrong Value - Vandalism or No Reference" (removes the Wikidata value) and "Wrong Value - Published Error" (deprecates the Wikidata value). If this split can't be done, the Wikidata value should be deprecated instead of replaced/removed, allowing someone using the Wikidata interface to decide why the value is wrong.

Thanks a lot for your valuable input!

• About edit icons: thanks for the suggestion, we'll have a look at it.
• We're currently figuring out how to best work with references. Thanks for the idea.
• We're looking into ways to make the template as smart as possible, without asking the editor too many questions that could lead them to abandon the edit. We'll not deal with deprecated rank in the first version but could consider it in the future.

I really agree with the need of providing references.

Additional suggestions:

• Require the user to enter values for any qualifier properties listed by P2302 (property constraint) Q21510856 (mandatory qualifier constraint).
• Ask the user to enter values for any qualifier properties listed by P2302 (property constraint) Q21510851 (allowed qualifiers constraint).

Thanks. Suggesting and checking values will not be part of the first version, but we'll definitely look at it later.

@Lea Lacroix (WMDE): perhaps the first version should check that the Infobox property does not have P2302 (property constraint) Q21510856 (mandatory qualifier constraint). If there is at least one mandatory qualifier then the edit icon would be hidden and editing from Wikipedia disallowed. For example, P1279 (inflation rate) doesn't make sense as a standalone statement--it requires P585 (point in time) to specify the date upon which the statement is valid.

Hi all,

I was looking at the prototype and it totally confused me:

1. http s://www.figma.com/proto/KIkcQ7NjOl8OkQtGWe5duIbW/Client-editing-UI?node-id=281%3A2956&scaling=min-zoom&redirected=1 found on Topic:V1x2lxtu8rgi954a links to page 8 instead of 1
2. it is still a mockup, right?

What is the scope of this? It can only edit infoboxes that use Wikidata already? or more?

How is it realised? Will it be included in the Visual Editor or a gadget?

I am asking, because we will finish the first backend services for https://meta.wikimedia.org/wiki/Grants:Project/DBpedia/GlobalFactSyncRE and it might be helpful to include here.

We will post all references extracted from Wikipedia for example

The current policy on the big Wikipedia's regarding Wikidata is that only statements with sources can be displayed on Wikipedia. Given that the prototype involves users entering unsourced statements, the prototype doesn't seem to provide the necessary functionality to be used on the big Wikipedia's.

Even from the Wikidata side, we don't want people to remove existing data and replace it with new data without providing a source that backs up the new data in cases where the old data is sourced.

While we might allow unsourced statements in some cases to be entered from Wikipedia, design prototypes should include a way for the user to specify the source for the information they enter as that's one of hard things to get right.

Thanks for your feedback. We're aware that references are an important part of data quality and acceptation of Wikidata's data by the Wikipedia communities, and we'll look at how to include references in the Wikidata Bridge interface as soon as possible.

The current policy on the big Wikipedia's regarding Wikidata is that only statements with sources can be displayed on Wikipedia. Given that the prototype involves users entering unsourced statements, the prototype doesn't seem to provide the necessary functionality to be used on the big Wikipedia's.

Which Wikipedia are you referring to ? This is not true for example in frwiki.

I'm primarily reacting to the discussions on enwiki. There people complain about unsourced Wikidata statements and are generally opposed to unsourced Wikidata statements being imported into enwiki. The sense I got on dewiki was generally similar.

But even if it wouldn't be a requirement from the side of Wikipedia, it's still important for us. Unsourced statements shouldn't be able to overwrite sourced statements. You could solve that by not showing the user the option to edit the value in the template, but that would make it confusing for users to know why they can't edit a specific claim and some of those users would likely complain and don't get a good impression about Wikidata out of the process.

Well, digging into the first Lea’s link a little bit we jump to this image which seems to take this problem into account.

I don't think it does. Clicking neither of those options should do something when the user doesn't provide a source for the new value. To me that image just feels like it wants to set the ranks of statements.

As far as enwiki discussions go there's the RFC from 2018 and in it's summary it has:

Despite this clear bifurcation, there is a consensus on one point: if Wikipedia wants to use data from Wikidata, there needs to be clear assurances on the reliability of this data. Of the many options, 3A, "Each statement imported from Wikidata must comply with Wikipedia policies", was the only option in the entire matrix in the poll to gain a majority: 52% percent of those expressing a preference in question 3 supported this option. If we define this to mean that the data drawn from Wikidata must be what is generally considered "reliable", then when we combine the share of votes from two other related options, 3C ("Require source") & 3D ("BLPs sourced"), this results in 78% of participants in the poll expressing some form of assurance about the reliability of the material drawn from Wikidata.

The only way we can provide that demanded assurance is by not giving Wikipedia unsourced data. If we try to deploy a tool on enwiki that is about unsourced Wikidata statements that sounds to me like asking for trouble and for someone to start the next anti-Wikidata RFC.

I mean this answers to the « overwrite » point at least. It seems obvious that by the answer of this question will trigger the creation of a new statement and the change of rank of the other one. This means this is not really related to the « make source mandatory » question. (although this poses the question of if this fits all the legitimate and in use usage of ranks we can observe on Wikidata and the consumers)

The current policy on the big Wikipedia's regarding Wikidata is that only statements with sources can be displayed on Wikipedia. Given that the prototype involves users entering unsourced statements, the prototype doesn't seem to provide the necessary functionality to be used on the big Wikipedia's.

Not true for Swedish Wikipedia

• we dont show Wikipedia references...
• we show max 3 referencies (the first 3)
  • we have no ranking of sources to be shown (which I feel we need)

Hi! Please remind the new editor that he is going to modify a statement with references. Something like: You are going to change a statement backed by 3 references [to be shown in the box] by a statement with no references. Are you sure about that? Or allow only changes for statements without references [excluding Wikipedia references] to be changed through that way. On Arabic Wikipedia, we usually put a one line template code to avoid having edits by new editors in the wikidata-based infobox. See California article as an example.

Thanks for the idea. We'll definitely look at it for further versions.

One thing that the Wikipedia community reacts on is if a Wikidata driven Infobox presents occupations in the "wrong order" and the order is normally not logical is my feeling its more a subjective feeling that this occupation should be first in the list as I think its important.....

Suggestion is to have a drag/drop interface to change position in the list....

At Wikidataconf 2017 I spoke with the people from Histropedia that we should have some kind of small icon/or mini timeline that you could expand which I feel is a better way of use WIkidata and display events in a persons life

• example Leonard da Vinci SPARQL timeline

@Salgo60: the order would have to be stored somewhere--probably a new qualifying Wikidata property a bit like P1545 (series ordinal) but named along the lines of "display order ordinal" without needing references and being subjective. I'm not sure that kind of vagueness/objectiveness would be welcomed on Wikidata though.

This would be an extremely nice thing to have! One suggestion to the team: don’t make the tool too complicated, make it generic (but still useful) and make it work great. The problem with WE-Framework, for example, is that it is so specific that it stops from being useful. Current prototype is kind of the same in the other way: you can’t alter the units as proposed, there’s no way for person to back up their claims with references.

P. S. Small windows can be bad for multilingual text, as can be seen in T151313.