Wikidata:Contact the development team/Archive/2018/06

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

Question about Queries

Thanks for posting the chat log of the office hour (And sorry I could not attend, as I had a bbq with my house mates). I saw that Tpt asked about queries, and looking at the ticket it gives the impression that the queries will reside on-wiki as opposed to centralized queries (as explained here). I suppose the later has preference, as it would be nice to add statements to the query container and centralize queries here on Wikidata so that they can be reused. If my assumption is correct, may I update the phabricator ticket to reflect this? If you prefer to do this yourself, I am also fine with it :)--Micru (talk) 22:21, 29 May 2018 (UTC)

This is not decided yet. It's part of the discussion we will have to define the needs better. Lea Lacroix (WMDE) (talk) 11:22, 1 June 2018 (UTC)
Thanks for your answer. I've updated the task based on it.--Micru (talk) 13:25, 1 June 2018 (UTC)

Issue with image suggester

Tracked in Phabricator
Task T196165

I've found an image on Commons I want to add to Villa du Parc du Mercantour (Q45290271). So I copy the title of the file: "File:Barcelonnette - Villa du Parc du Mercantour -984.jpg", I select image (P18) on Villa du Parc du Mercantour (Q45290271), I paste "File:Barcelonnette - Villa du Parc du Mercantour -984.jpg" and the right image is at the end of the list, the tenth! Same issue if I paste only "Barcelonnette - Villa du Parc du Mercantour -984.jpg".

This issue is systematic: when you enter the exact title, the right image is never suggested in the first place.

Could you fix it please? Thanks. — Ayack (talk) 11:44, 1 June 2018 (UTC)

Thanks for reporting. I did a few tests and created a ticket. If you encounter this issue with another serie of files, feel free to add them in the list. Lea Lacroix (WMDE) (talk) 14:34, 1 June 2018 (UTC)

Numeric value too large?

Is it possible to state a numeric value with more than 126 digits? RSA-129 (RSA-129 (Q638002)) contains 129. -- IvanP (talk) 20:18, 3 June 2018 (UTC)

I think it's not possible, see Help:Statements#Quantitative values. —MisterSynergy (talk) 20:46, 3 June 2018 (UTC)

Disappeared edit

At https://www.wikidata.org/w/index.php?title=Q19245238&oldid=691379642 , there is no prime factor = 2, despite the editing being visible in the edit history.
--- Jura 10:21, 7 June 2018 (UTC)

From what I see here it's been removed by the next edit. Lea Lacroix (WMDE) (talk) 11:08, 7 June 2018 (UTC)
And for reference, here's the lines for this item in the QuickStatements v1 format file I uploaded:
Q19245238	P5236	Q200	P1114	2
Q19245238	P5236	Q23350
Q19245238	P5236	Q720733

QuickStatements2 turned the first line into 2 statements first to create the claim and then to add the qualifier; I see no sign that the qualifier edit ever happened, so there may have been a problem on that end to start? But the state in wikidata looks wrong too with the second create actually replacing the first statement. ArthurPSmith (talk) 18:03, 7 June 2018 (UTC)

P2258

Per Property talk:P2258, please convert this to external-id. I had asked for input on PC.
--- Jura 11:45, 30 May 2018 (UTC)

Property talk:P728

Documentation reports that the property is used by seven templates in hywiki. Actually no template uses it there. Any suggestions what happened? Thanks - Kareyac (talk) 17:58, 11 June 2018 (UTC)

@Kareyac: because templates used it before. Currently template removal from the list is manual process. --Edgars2007 (talk) 06:08, 13 June 2018 (UTC)
Thanks, I understand now. - Kareyac (talk) 06:15, 13 June 2018 (UTC)

Default SPARQL table view rejected?

Why is the default SPARQL table view rejected in favor of a SPARQL column view? (My query)--Succu (talk) 21:00, 12 June 2018 (UTC)

@Succu: it depends on monitor size. But the main reason - your query output was too wide. --Edgars2007 (talk) 06:10, 13 June 2018 (UTC)
At my side nothing changed. I simply reruned the query. --Succu (talk) 06:35, 13 June 2018 (UTC)
Chinese URLs are long ..
--- Jura 06:38, 13 June 2018 (UTC)
And not new in the result set. --Succu (talk) 07:07, 13 June 2018 (UTC)
Seems the problem is gone... --Succu (talk) 10:55, 13 June 2018 (UTC)

Update of WDQS triplestore failing on a massive scale

I just used QuickStatements to add 2,398 statements, each qualified with reason for deprecated rank (P2241). (See Special:Contributions/JhealdBatch, run started 11:58 diff, concluded at 13:46, 14 June 2018.)

However, checking to see what is now there according to WDQS, I find that 227 statements are not reported at all, and a further 24 appear to be missing their qualifier.

As far as I can see, the statements appear to have been loaded successfully into Wikibase (eg diff), but they appear not to have been read into WDQS.

Many workflows rely on accurate and complete WDQS returns, that statements have been properly added, properly qualified, or properly removed.

Failure on this scale makes any results based on WDQS essentially completely untrustworthy. This needs to be fixed, and soon. Jheald (talk) 16:32, 14 June 2018 (UTC)

Pinging @Smalyshev (WMF):. Jheald (talk) 16:37, 14 June 2018 (UTC)
@Jheald: Could you post how exactly you checked for the statements that were not reported? I.e. the query you used? Smalyshev (WMF) (talk) 16:59, 14 June 2018 (UTC)
@Smalyshev (WMF): Sorry to be slow to get back to you. I managed to lock myself out of the flat and away from my computer for five hours just after I posted that, while my wife was out at the theatre!
I am not sure how much my queries will help you, but the first one was this, to check the total counts of statements that had been written:
SELECT (COUNT(DISTINCT(?stmt)) AS ?count) ?reason ?reasonLabel WHERE {
      ?item wdt:P4327 [] .
      ?item p:P1144 ?stmt .
      ?stmt pq:P2241 ?reason
          
      SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}  GROUP BY ?reason ?reasonLabel
Try it!
Results ought to be "unrecognised": 2398, "incorrect": 228, "withdrawn": 88. (The "incorrect" and "withdrawn" runs were done slightly earlier).
Instead I am now seeing "unrecognised": 2238, "incorrect": 225, "withdrawn": 84. -- a little better than before, but still considerably out.
To look at the content according to WDQS in detail, I ran the following:
SELECT ?bhl ?item ?val ?reasonLabel WHERE {
      ?item wdt:P4327 ?bhl .      
      ?item p:P1144 ?stmt .
      ?stmt ps:P1144 ?val .
      OPTIONAL {?stmt pq:P2241 ?reason} .
          
      SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
} ORDER BY xsd:integer(?bhl)
Try it!
and then a perl script on my own machine to compare the return against the files I had given to QuickStatements.
Compared with the file of "unrecognised" statements given to QS, that's now showing 141 statements not seen at all and 19 unqualified -- making a total of 160 being malreported, consistent with the first query.
First ten failing to be properly reported are Q51386615, Q51386780, Q51387474, Q51393955, Q51397119, Q51398128, Q51399298, Q51405549, Q51420395 (statements missing completely), and Q51421393 (statement unqualified). Jheald (talk) 22:55, 14 June 2018 (UTC)
This query confirms that the problem is with the Library of Congress Control Number (LCCN) (bibliographic) (P1144) statements, not the BHL bibliography ID (P4327) ones:
SELECT (COUNT(DISTINCT(?item)) AS ?count) WHERE {
      VALUES ?item {wd:Q51386615 wd:Q51386780 wd:Q51387474 wd:Q51393955 wd:Q51397119 wd:Q51398128 wd:Q51399298 wd:Q51405549 wd:Q51420395} .      
      ?item wdt:P4327 ?bhl .
#      ?item wdt:P1144 ?lccn .
}
Try it!
-- Jheald (talk) 23:30, 14 June 2018 (UTC)
Well it used to, anyway. They all seem to be fixed now (and latest total unrecognised is now up to 2262). Jheald (talk) 23:45, 14 June 2018 (UTC)
And now a count of 227 unseen and 24 unqualified again -- just like my original result; so I guess may depend which server is handling the request. Though every specific 10 I choose now repeatedly seem to be found .... ??? Jheald (talk) 23:58, 14 June 2018 (UTC)
Yes, there seems to be a problem there in which some servers get partial results for some items, especially when they are updated by bots or QuickStatements, editing references, as it seems. I haven't yet discovered what is causing it, but your case seems to be the instance of the same bug. Manually updating entries usually fixes it, but I want to look into it deeper and see if I can figure out why this happens. Definitely should not happen and I so far am not sure where exactly the bug happens, but I will look into it. May be some weird race condition? No idea :( I'll dig into the data and see. Smalyshev (WMF) (talk) 06:33, 15 June 2018 (UTC)

Corrupted statements

Tracked in Phabricator
Task T85296
Tracked in Phabricator
Task T167565

Hello, Wikidata API allows to create corrupted statements, examples:

  • corrupted date presentation: [1], value "+1740-12-00T00:00:00Z" is not supported by Wikidata editor and visualizer.
  • corrupted unit presentation: [2], unit "http://www.wikidata.org/entity/1".

Statements creation API should reject such edits as I understand. Is it known issue? — Ivan A. Krestinin (talk) 17:21, 14 June 2018 (UTC)

There's https://phabricator.wikimedia.org/T167565 and https://phabricator.wikimedia.org/T85296 Smalyshev (WMF) (talk) 06:39, 15 June 2018 (UTC)

RTL marks in Query Service results

I tried to fix ISNI (P213) identifiers with format issues recently and ran into an issue which I believe is a bug in the Wikidata Query Service. Using this query, I find 9 cases where a regex format violation is found. Problem for all but one of them is that the Query Service sees an RTL mark (hex 0xE2 0x80 0x8F in UTF-8 hex) at the end of these identifiers/strings, which is not there in the regular Wikidata UI, nor in JSON representation. I was not able to remove this RTL mark with different strategies (e.g. [3]), even after carefully sanitizing the input string when re-entering the data in the Wikidata UI. On the other hand, if I deliberately place an RTL mark at this point, as I did here for the Wikidata sandbox item, I can see this RTL mark in the Wikidata UI (identifier indeed displayed right-to-left) and in the JSON representation. Hence I think that in the other 8 cases there is something wrong with the Query Service.

Ping @Smalyshev (WMF). I have looked at phabricator for reported issues, but only found phab:T178057 which I think is unrelated. —MisterSynergy (talk) 06:52, 15 June 2018 (UTC)

Yes, seems to be something weird - if I insert string "0000 0000 4698 056X" into the database, it comes back with RTLM attached. No idea why :( I'll dig into the code and try to see what's going on. Smalyshev (WMF) (talk) 07:31, 15 June 2018 (UTC)
OK, I checked it and it looks like it's caused by the following: Blazegraph apparently uses ICU collator to distinguish strings. And by default ICU collator ignores RTL marks. It can be configured not to do this, but I am not sure if it's possible without reindexing. I'll check more into this.
Tracked in Phabricator
Task T197447
Smalyshev (WMF) (talk) 09:14, 15 June 2018 (UTC)

Hijos de su madre

Hi! My boss wanted my to make an article about a new series we produced, so all the data is correct. I already try 2 times to make the article, but someone deleted it. How can I resolve the problem so it stays on wikipedia?  – The preceding unsigned comment was added by 201.116.78.2 (talk • contribs) at 16:05, 18 June 2018‎ (UTC).

Ask on Wikipedia; this site is Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:01, 19 June 2018 (UTC)

Strange behaviour when editing

I am using Seamonkey (Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46). I did the following: Open Q750517, scroll down to BnF-Id and click on "edit". I cleared the field and started to type with a "1". The I found I was wrong (browser window jumped) and want to edit the VIAF, so I pressed ESC. The edit-fields disappeared, but the "1" which I typed was still here. So I was a little bit nervous … did I edit the wrong data?

I could not reproduce this behavior with Firefox 60.0.2 ESR. I could reproduce the behavior with seamonkey on the field "postal code" too, but not with "shares border with".

Quick steps to reproduce: Open some item. Select some property (postal code, BnF, VIAF), fill the field with a "1", press Escape.

--Wurgl (talk) 07:44, 17 June 2018 (UTC)

Anyone having Seamonkey installed could try to reproduce?
Would you mind creating a ticket on Phabricator? Thanks, Lea Lacroix (WMDE) (talk) 14:41, 20 June 2018 (UTC)

Display-order of external identifiers

There's a current discussion at Wikidata:Requests for comment/Sort identifier statements on items that are instances of human on whether and/or how to impose a sort-ordering for the display of external identifiers.

As a technical question, is there any possibility of being able to sort the identifiers alphabetically according to their labels in the user's own language?

Is this something that might be considered an option (a) without adding too great an overhead to the server load for serving pages, or to page presentation time; and (b) without requiring too much developer time? Jheald (talk) 07:53, 20 June 2018 (UTC)

It is technically possible. It would need some work though, and I can't give you any information about when it could be done. Lea Lacroix (WMDE) (talk) 14:39, 20 June 2018 (UTC)

Incorrect date format for decades in Polish

KaMan pointed out (permalink) that date format for decades in Polish interface is incorrect. Example (Q51660): there is lata 1220-te and should be lata 1220. (with full stop). I don't know whether this is a problem with translation (translatewiki?) or an issue that have to be solved somewhere else, so I'll be grateful for fixing this, telling me how I can fix this myself or pointing me to someone who can help me with this (phab ticket?). Wostr (talk) 21:08, 13 June 2018 (UTC)

Hey @KaMan, Wostr:, is this the same as this ticket? Lea Lacroix (WMDE) (talk) 14:35, 20 June 2018 (UTC)
@Lea Lacroix (WMDE): no, I think it's not the same problem, but thanks to you I've found the right place to fix this: translatewiki:MediaWiki:Wikibase-time-precision-10annum/pl. @Chrumps: mógłbyś to poprawić? Sorry, że Cię pinguję, ale nie mogę się zalogować na translatewiki (nie wiem nawet w sumie, czy tam działa ten sam login co w projektach Wikimedia...). Wostr (talk) 19:51, 20 June 2018 (UTC)
I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Wostr (talk) 10:16, 27 June 2018 (UTC)

Cannot create new item - description error

Tracked in Phabricator
Task T193498

I am unable to create a new item with en label "Běhounek" and en description "family name". I am getting an error "Item Běhounek (Q1022019) already has label "Běhounek" associated with language code en, using the same description text", but the item Běhounek (Q1022019) has the same label, but a different description.--Jklamo (talk) 14:19, 27 June 2018 (UTC)

I'm seeing real database errors in creating a new item right now - "[WzPkmApAICkAAL9JC5EAAAAJ] 2018-06-27 19:25:28: Fatal exception of type "Wikimedia\Rdbms\DBQueryError"" - I tried twice and got (I think) the same error - it looked very close anyway. ArthurPSmith (talk) 19:27, 27 June 2018 (UTC)
Ok, my problem has gone away now. ArthurPSmith (talk) 19:49, 27 June 2018 (UTC)
Same for me for a couple of minutes in a my subpage. --ValterVB (talk) 19:57, 27 June 2018 (UTC)
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Contact_the_development_team/Archive/2018/06&oldid=709622202"