Wikidata:Contact the development team/Archive/2020/04

This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

different key order in head and result

Hi!

I want to query some wikidata. When I do the query, I get a 'head' and a 'result' object in json.

The key order in the head differs from the key order in the result. Example from the screenshot:

Keys in Head: human, humanLabel, awardEditionLabel, awardLabel, awardWork, awardWorkLabel, director, directorLabel, time

Keys in Body: awardWork, human, director, time, humanLabel, awardEditionLabel, awardLabel, awardWorkLabel, directorLabel

I do not see any reason why keys are swapped in the result.
I do not see any pattern after that the keys are re-arranged. – The preceding unsigned comment was added by Foobar-User (talk • contribs).

JSON object is unordered.--GZWDer (talk) 14:16, 2 April 2020 (UTC)

Shouldn't "The order of elements in the bindings array reflects the order, if any, of the query solution sequence." as in here? --Newt713 (talk) 21:37, 2 April 2020 (UTC)

The two standards (SPARQL and JSON) seems to give different recommandations. In our case, the order is provided by Blazegraph and we don't have a direct influence on it.

@Foobar-User: Can you help us understand what problem you face given that they are not ordered? Do you have some special situation that makes it difficult to use the values? They are still correctly labelled so I would hope you can take the variable ordering into account. Lea Lacroix (WMDE) (talk) 09:18, 3 April 2020 (UTC)

@Foobar-User: Shouldn't "The order of elements in the bindings array reflects the order, if any, of the query solution sequence." as in here? I think that quote (deep link) refers to the order of results in the whole result list, i. e. the order of objects within the full bindings list. That is, if the query has ORDER BY ASC(?a), then "bindings": [ { "a": 1 }, { "a": 2 } ] is valid, but "bindings": [ { "a": 2 }, { "a": 1 } ] is not, because the results are in the wrong order. (Also, in a real result the values wouldn’t be integer literals, that’s just a simplification for the example.) I don’t think that part of the specification intends to say anything about the order of keys within each object, only about the order of the objects within the bindings array. --Lucas Werkmeister (WMDE) (talk) 09:50, 3 April 2020 (UTC)

Add "ОК-КС" (russian alphabet) as a Wikipedia page

I would like to add
ru ОК-КС (the name comes from https://ru.wikipedia.org/wiki/%D0%9E%D0%9A-%D0%9A%D0%A1)
in the Wikipedia field in https://www.wikidata.org/wiki/Q11794364

I managed to find ОК-КС in the popup list, but when I click publish, I always get : Could not save due to an error. The save has failed. Sovxx (talk) 14:12, 8 April 2020 (UTC)

This is a side effect of the breakage that happened at the beginning of the week (phab:T249565). There is probably another Wikidata item attached to the Wikipedia page. The way to fix it would be to find this other item and to merge them. Lea Lacroix (WMDE) (talk) 11:46, 9 April 2020 (UTC)

Page image property

When looking for something else, I came across phab:T112865#1692685. Apparently, there is a configuration variable that selects the "page" image.

Since it was last defined (years ago), there are few more properties (to be used when there is no image (P18) ). Please add:

Thanks!

BTW, I was looking for the code that determines the thumbnail that is displayed for image properties. Where can I find it? --- Jura 07:07, 9 April 2020 (UTC)

I created a ticket for the first part of your request. As for the second part, I think this is the code you're looking for. Lea Lacroix (WMDE) (talk) 13:51, 9 April 2020 (UTC)

Thanks for both. Personally, I'd have put the P2716 last (more complex than the others).
I had a look at the code for /Archive/2019/12#Page_for_thumbnail. It seems to me that it might allow for the page parameter (of djvu or pdfs), but the image is generated from the snak with the filename. Reading the file page (P7668) or title page number (P4714) qualifiers might require getting data from outside that. So it might take more time to write it than I had thought (not that I could actually do that myself). As we add more P7668, eventually it should be worth doing it. --- Jura 15:22, 9 April 2020 (UTC)

Suggested that direct account creations be turned off for TESTWIKIDATA

Tracked in Phabricator
Task T250348
Resolved

Due to the number of spambots creating accounts and spamming at the testwikidata, I have submitted a request to have the direct account creations to be turned off. It was implemented at wikimaniawiki a couple of months back and has been highly effective. At that wiki, the createaccount link was converted into a link to direct them to metawiki, and you/we could similarly point them here to create an account. — billinghurst sDrewth 07:06, 16 April 2020 (UTC)

This appears to have been implemented. I hope that it meets with the community's approval. — billinghurst sDrewth 11:27, 16 April 2020 (UTC)

Problems to add a 15th qualifier

Hi! Please help to add a 15th qualifier:

Item: December murders (Q583569)
Property: instance of (P31)
Qualifier property: of (P642)

Please add here the 15th (and last missing) dead person: André Kamperveen (Q2506619)

I cannot do this myself. In my opinion you have to increase a possible qualifier limit, right? Doc Taxon (talk) 16:51, 16 April 2020 (UTC)

I had no issues doing this. See Special:Diff/1158946617. Mbch331 (talk) 17:29, 16 April 2020 (UTC)

I tried it once more, it worked now. I think it will be very difficult to find out, why it has not worked about 16:45 UTC, right? Doc Taxon (talk) 17:40, 16 April 2020 (UTC)

Note there is new property victim (P8032) (and older property participant (P710)). There is no need to store these as qualifier.--Jklamo (talk) 07:35, 17 April 2020 (UTC)

Calculated values

There are many situations in science where one value is derived from calculating another (such as totals and sums) in a straightforward manner. Most likely, having these quantities be dynamically calculated at use time would result in unacceptable performance drawbacks. Instead, the value can be calculated once, and then only updated as the data on which it depends is updated. A dependency graph (usually a directed acyclic graph (Q1195339) could be used to determine when or if to recalculate such values. The calculation could be carried out by a SPARQL query or (most preferably) a Lua module (which, being Turing-complete and functional rather than declarative, offers more flexibility). But yet I do not see this added to the development timeline. I have a major use case for such a feature, so I'd like to know if this is still planned.--Jasper Deng (talk) 06:10, 14 April 2020 (UTC)

Hello @Jasper Deng:, thanks for letting us know. Could you tell us more about your usecase?

So far, this feature was not often requested, that's why it is not included in the roadmap yet (that, and because we have plenty of other important things to do). Thanks in advance, Lea Lacroix (WMDE) (talk) 13:35, 14 April 2020 (UTC)

@Lea Lacroix (WMDE): tropical cyclone (Q8092)'s often have many calculated, or derived metrics, that depend on their best track, which is a tabular list of tuples containing many variables, with the key being the storm identifier and time. Such quantities include:

${\text{ACE}}_{storm}={\frac {1}{10000}}\sum _{t=0}^{n}v_{t}^{2}\mathbf {I} [v_{t}>34]$ (Accumulated cyclone energy (Q339687) for an individual storm)
$v_{max}=\max v_{t}$ (maximum sustained wind (Q6795923))
${\text{ACE}}_{season}=\sum _{{\text{storm}}1}^{{\text{storm}}n}{\text{ACE}}_{storm}$
The top 10 storms worldwide by some metric, such as lowest central pressure
The most intense storm of a given season ( ${\text{argmin}}_{{\text{storm}}\in {\text{season}}}{\text{central pressure}}_{\text{storm}}$ )
The longest-lived storm

The list goes on and on. My ultimate hope is that we can use Wikidata to create interactive maps of the storm (I don't think putting this data as tabular files on Commons is best, especially if we want to use SPARQL/WDQS to answer more complex questions, which is a very common use case), and also simplify things like list of the most intense tropical cyclones (Q6643122) (currently, the inclusion criteria on that list are arbitrary and we have lots of duplicate information on different storms for different types of record lists). This data can be imported from International Best Track Archive for Climate Stewardship (Q43269466) and other places. So I guess I also want better support for rendering tabular data, or at least compound properties (i.e. properties with values set to members of the Cartesian product (Q173740) of the possible values of different data types; creating an item for every data point is unwieldy and does not enforce the individual data types). Commons' tabular data feature is nice, but is not suitable for making this data available via WDQS.--Jasper Deng (talk) 19:30, 14 April 2020 (UTC)

Thanks a lot for your explanation. I agree that tabular data is probably not the best for what you envision.

I'm not entirely sure how granular data about storms in Wikidata should be, that's a question to ask to the community. Back to the calculated values, we have this ticket that may describe the problem. However, I'm not sure how quick we can take it on our plate, as the roadmap for this year is already pretty packed. Lea Lacroix (WMDE) (talk) 13:38, 17 April 2020 (UTC)

@Lea Lacroix (WMDE): I think it should be quite granular after talking off-wiki with others interested in this use case.

The stats of many other things like tornado (Q8081) also would benefit from at least having tuple-valued and derived properties. Essentially, I am hoping for the database to be able to assume Boyce–Codd normal form (Q2460153) without losing easy access to these derived quantities. Supporting general tuple-valued properties is also something that would vastly expand the power of Wikibase, since many complex data types can be described as ordered tuples of simpler data types, much in the same vein as a structure in C (Q1164699). If I had to pick one of these two, I would say supporting tuple-valued data is more important; an interim solution to derived quantities is to simply have a bot maintain such quantities.--Jasper Deng (talk) 01:19, 18 April 2020 (UTC)

Passthough for sister languages does not work

I use WD in British-English, when using the "nearby" function, if there is no text for the item in en-gb, it should fail-over to the text from en, however, it does't it just shows the Q value

– The preceding unsigned comment was added by Back ache (talk • contribs).

I think this is phab:T117158 - Nikki (talk) 13:00, 17 April 2020 (UTC)

What Nikki says :) The problem is identified and is waiting to be solved. Lea Lacroix (WMDE) (talk) 13:14, 17 April 2020 (UTC)

Thanks :-) Looks like its been on the waiting list for five years! Back ache (talk) 01:36, 19 April 2020 (UTC)

trim?

Can you please automatically trim values instead of rejecting values with leading or trailing white-spaces and forcing the user to manually remove the white-spaces. Please. --Herzi Pinki (talk) 10:28, 17 April 2020 (UTC)

Hello,

Thanks for your message. Can you give me an example? What were you trying to do and what went wrong or unexpected? Lea Lacroix (WMDE) (talk) 13:14, 17 April 2020 (UTC)

thanks for your reply. I had it with various properties. Last time for burial plot reference (P965). The error message is: Die Speicherung konnte aufgrund eines Fehlers nicht ausgeführt werden. Fehlerhafte Eingabe: Gruppe 13, Nr. 73

Removing the blank allows to store the value (the blank is at the end of the value and visible in source code here).

On the message it is difficult to see the trailing blank, as the value is no marked by suitable delimiters (another improvement possible). It does not happen for street address (P6375). I would expect that trimming is not implemented on a per-property basis, but at least for all properties that allow string values. best --Herzi Pinki (talk) 21:02, 17 April 2020 (UTC)

@Lea Lacroix (WMDE):? --Herzi Pinki (talk) 09:27, 20 April 2020 (UTC)

I can reproduce it by trying to add burial plot reference (P965) with "test " as the value (i.e. the word "test" followed by a normal ASCII space) on Wikidata Sandbox (Q4115189). The English error is "Could not save due to an error. Malformed input: test". It looks like phab:T188802 to me. - Nikki (talk) 10:32, 20 April 2020 (UTC)

Hello,

I think the related ticket is this one. For a bit of context, until now we don't trim the blanks because of some cases where the blank character is actually the only character of the string. We could decide to trim and keep these exceptions aside. Lea Lacroix (WMDE) (talk) 12:23, 20 April 2020 (UTC)

is there any sense in life? Is there any sense in writing tickets? Is there any sense in complaining about even simple flaws? 🤦 The ticket you, Lea, mentioned was created in 2013. The other ticket in 2018. Both are still open. Both seem to be duplicates to me. Ok, lesson understood. It would be an improvement, if you could enclose the erroneous string in the message in quotes to make the spaces visible. --Herzi Pinki (talk) 13:28, 20 April 2020 (UTC)

I created a task to improve the error message: phab:T250695. I hope that it describes the problem with the error message accurately.

Wikidata is a project in continuous development, plenty of tickets are created every day and the development team is working as efficiently as possible to triage, prioritize and resolve them, but we can't expect to fix issues immediately.

Thanks for reporting this problem. Lea Lacroix (WMDE) (talk) 13:53, 20 April 2020 (UTC)

Lea, I do not expect that reported issues are fixed immediately, but 2013 till now is far from any idea of immediateness. :-) --Herzi Pinki (talk) 14:04, 20 April 2020 (UTC)

Except it doesn't allow strings that only contain whitespace either. Users have to manually strip whitespace when editing because of ~25 potential statements that we can't even add, that seems ridiculous to me. - Nikki (talk) 15:40, 20 April 2020 (UTC)

Ah .. that's where that odd error message comes from .. --- Jura 17:17, 20 April 2020 (UTC)

AbuseFilter not triggering on edits that would trigger it

As discussed in Topic:Vkqokk527p3u4cnp, we seem to have a case where this edit filter did not fire on certain edits, but the test interface says that it should have. Am I missing something obvious? Are there circumstances when we don't run edit filters? Should I report this as a bug in phabricator? Thanks, Bovlb (talk) 17:09, 18 April 2020 (UTC)

@Bovlb: article_namespace is deprecated. page_namespace should be used instead (see mw:Extension:AbuseFilter/Rules format). I'm not sure if it fixes the problem, but I think it's worth a try. Ahmad^talk 18:50, 18 April 2020 (UTC)

@Ahmad252: Thanks, I have made that change. The new version also fires on those edits in the test tool. I'll see how it goes in practice. Bovlb (talk) 21:50, 18 April 2020 (UTC)

@Bovlb: If I'm not mistaken, I think DannyS712's change (here) was the correct one. Can you please double check? Ahmad^talk 00:10, 19 April 2020 (UTC)

Yes, thanks. I must have confusedly changed it back again. Should be good now. Bovlb (talk) 02:04, 19 April 2020 (UTC)

Deprecated variables are still supported and should work. I cannot see any undos in the filter log, so it's likely they cannot be caught by the filters due to a bug. --Matěj Suchánek (talk) 09:34, 19 April 2020 (UTC)

phab:T250720 Bovlb (talk) 17:06, 20 April 2020 (UTC)

Adding statements: please add an 'add statement' possibility on the top side of the page also

Tracked in Phabricator
Task T142082

Following discussion in the Dutch Kroeg, I like to propose to add an "add statement" link next to the 'Statements' header on every Q and P item page. At the moment, everyone who wants to add any statement, needs to scroll down the entire page or manually press the keyboard 'End'-button to go down and often then scroll up a bit again also. I find this very inconvenient, and I really wonder why apparently this has not been brought up before (or was it, and what was the reason to decline?). I think this simple adjustment would make life for all users so much easier. Thanks, greeting, Eissink (talk) 18:04, 4 April 2020 (UTC).

This feature request is described in Phab:T142082. The main blocking point seems to be that adding a button at the top of the sections would encourage people to add statements without checking if a similar statement is already there.

If you really want to have this button, I guess a userscript could work. I'm pretty sure it already exists but I couldn't find it, maybe someone can point it here? Lea Lacroix (WMDE) (talk)

Thank you for answering and bringing the request over to Phabricator. In my case, I often come right from Commons to add an image, knowing from the Wikidata Infobox already that an image statement is not already there. And as someone else mentioned: the same possible problem would still be there when people jump right to the bottom (by keyboard End button) to find the statement button they need. I'm not sure what you mean by a userscript, but it was already suggested to me to use quickstatements, which doesn't seem comfortable, and also to use KeyShortcuts, which is hardly an improvement over using the End button, which besides from still requiring hand movement from mouse to keyboard also seems to favor editing the label, not creating a new statement. Unless discussion is continued here, I will further comment on Phabricator. Thanks again, Eissink (talk) 17:08, 8 April 2020 (UTC).

How about testing if it actually leads to more duplicates? --- Jura 06:54, 9 April 2020 (UTC)

I use the end button to go to the end of the wikidata input form, and add my new property there. Or I can scroll down. Without reading the content already existing. What a paternalistic thought that you could enforce the user to read by just placing the button at the most annoying position! That said, I would be well possible to put it also in top. without loosing enforcement. best --Herzi Pinki (talk) 10:19, 17 April 2020 (UTC)

I have the impression that Wikidata lacks developers that care about users. This point was raised years ago (Phab:T142082), everyone says it's annoying, yet nothing is done. It has not stopped me from adding images or links to Commons, since there is no other possibility, but it certainly stops me from adding first names and family names, when sorting on Commons fails despite the Infobox connection: it is just to much trouble to change it on Wikidata, I choose to just add a DEFAULTSORT template on Commons to fix it, leaving Wikidata for what it is: incomplete. This happens very, very often, and I am convinced many others act the same. Name me one other website or application where the user, the volunteer has to scroll down entirely just to add some data – it's nothing but totally ridiculous. Eissink (talk) 17:34, 23 April 2020 (UTC).

Hello all, and thanks for pointing this issue to us.

I understand that the "add a statement" link at the top of the page is a valuable feature that would make the life of many editors easier. I also agree with you that the choice we previously made to not have this feature in order to avoid creation of duplicate statements is not a proper solution to the problem. It enforces a certain behaviour on users (scroll to read all statements), when we should instead make sure that the software is dealing with possible duplicates correctly. This choice was an acceptable solution at the beginning of Wikidata's development, but not anymore.

Here's what we can offer now to move forward: we can work on the implementation of the "add Statement" button at the top of the page, as soon as possible (it will be tracked in the existing ticket). In parallel, we will start investigating on a proper way to check if the editor is about to create a statement that already exists, and to inform them before saving the statement. I created this ticket for this task.

I hope this helps. Lea Lacroix (WMDE) (talk) 10:19, 24 April 2020 (UTC)

Thank you for your response. I trust that having constructive views on this topic will bring a solution, and maybe even more innovation to the interface, so I feel I can rest my concerns considering this now. Thank you, Jürgen Eissink (talk) 12:14, 24 April 2020 (UTC).

Please change the Data type of ISIL (P791) from String to External identifier

Tracked in Phabricator
Task T251119

Proposal was discussed here.

For your attention: @Epìdosis, Pigsonthewing, ArthurPSmith: @Jura1:

Iwan.Aucamp (talk) 14:19, 24 April 2020 (UTC)

@Iwan.Aucamp: I don't object, but do you know why the constraint violations page still shows a large number of unique-value and single-value constraint violations? Those are the critical constraints for something to qualify as an external identifier. ArthurPSmith (talk) 12:24, 27 April 2020 (UTC)

Hello, I created the related ticket. If something changes and you want to stop or postpone the change, please let us know. Lea Lacroix (WMDE) (talk) 12:45, 27 April 2020 (UTC)

@ArthurPSmith: from ISO 15511:2019 "Since this document allows the use of existing codes to be incorporated into the ISIL, it is possible that a given organization can have more than one ISIL. However, it is the intention of this document to minimize the number of codes." so I think the single value constraint is wrong and should be removed. Fort the "Unique value" violations I think most of them point to problems in Wikidata, at least the ones I checked. There are seemingly many duplicate Wikidata items and some wikidata items with two identifiers which should only have one. We should maybe take the discussion further on the property talk page. Iwan.Aucamp (talk) 20:08, 30 April 2020 (UTC)