Wikidata:Contact the development team/Archive/2016/05

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

Items vanishing from SPARQL query results

A while ago I was seeing if I could replicate a Wikipedia discography section using Wikidata and made a Listeria list using a SPARQL query at User:Nikki/Listeria/SNH48. Yesterday the bot suddenly updated the list and removed three items (the old version is here, 1, 3 and 4 were removed). All three removed items are older than the ones that are left and have not been touched for over a month (since before the last list update), yet they are no longer being returned in the SPARQL query.

Any idea what's going on here? (@Smalyshev (WMF): Maybe you know?)

- Nikki (talk) 09:07, 28 April 2016 (UTC)

See https://phabricator.wikimedia.org/T133924 - this is most likely source of the trouble. I'll investigate what is happening there. --Smalyshev (WMF) (talk) 17:55, 28 April 2016 (UTC)

Heh, I had just commented on that and wanted to add a link here but you beat me to it. :D Thanks for looking into it! - Nikki (talk) 17:59, 28 April 2016 (UTC)

@Smalyshev (WMF): Did we loose some "schema:isPartOf" values last night?
--- Jura 12:26, 2 May 2016 (UTC)

Representation of no unit

I was interested in which items are most commonly used for units, so I came up with this query and found (to my surprise) that 1 (Q199) is apparently the most commonly used item.

Having a look at some of the items, it looks like Q199 is being used in the RDF to mean no unit. That seemed weird to me (what if someone actually used Q199 as the unit?) so I had a look at some of the items' JSON and found Special:EntityData/Q12061543.json which has "unit": "http://www.wikidata.org/entity/Q199", for P1092 and Special:EntityData/Q81231.json which has "unit": "1", for the same property.

This query however shows both as using Q199 while neither Q12061543 nor Q81231 show a unit either when displaying or editing the data.

I'm not sure what's going on here, but it seems like something is wrong because there's a distinction being made in some places but not others.

- Nikki (talk) 20:36, 15 April 2016 (UTC)

@Smalyshev (WMF): Can you have a look please? --Lydia Pintscher (WMDE) (talk) 09:07, 20 April 2016 (UTC)

Q199 is the default unit. We can not use both Q199 and "1" since mixing data and objects (i.e. strings and references to other entities) in the same property is frowned upon in RDF world. So, quantities having no unit will have unit of Q199 in RDF. If you notice data that does not follow this (in RDF, JSON is another matter) please tell me. Smalyshev (WMF) (talk) 17:38, 20 April 2016 (UTC)

Is there a reason why it's not optional? (still seems strange to me to reuse a real item to mean no unit, then there's no way to tell that the quantity doesn't have a unit set, you can only add special casing to catch Q199). - Nikki (talk) 17:17, 27 April 2016 (UTC)

Note that it's not just the RDF, the interface lets you enter Q199 as the unit, stores Q199 as the unit and then displays it as if there were no unit (see here - one has a unit set, one doesn't, but they're displayed as if they were identical). - Nikki (talk) 17:17, 27 April 2016 (UTC)

I think it's fine to treat Q199 as no unit resp. setting no unit equivalent with unit 1. Also in the International System of Units (SI) brochure you can read Such counting quantities are also usually regarded as dimensionless quantities, or quantities of dimension one, with the unit one, 1. [1] --Pasleim (talk) 18:35, 27 April 2016 (UTC)

I would be fine with turning Q199 into no unit if someone enters that, my main issue is the inconsistency, I would expect no unit to be consistently represented, not 1 for some statements, Q199 for others. - Nikki (talk) 19:01, 27 April 2016 (UTC)

Maybe the ones with "1" predate the introduction of units (Q3 2015) and even editing them doesn't convert them to the new format.
--- Jura 09:27, 28 April 2016 (UTC)

That's not the case because entering no unit in a new statement uses "1" for the unit (see Special:Diff/325555342). - Nikki (talk) 07:28, 5 May 2016 (UTC)

display (and link) Q numbers in diffs

When someone changes a statement to a different item with the same label, it is not always obvious what the change is - indeed if there are other changes in the diff it is entirely possible to overlook that there has been a change.

For example [2] changes the unit from gallon (Q178413) to gallon (UK) (Q23925410) (both labelled "gallon" in English) but the only obvious change is to the level of precision (that neither ±0 or ±1 are likely correct is a separate issue). The simplest way to solve this is to display the Q number in brackets after the label of the item in the same way that the {{Q}} template does. Thryduulf (talk: local | en.wp | en.wikt) 14:22, 26 April 2016 (UTC)

Well, on the diff view, if it's there in an own line, it changed, so I personally don't think it's much of a problem that I can be overlooked. However, it's true that you don't see what the change actually is. If "x" changed to "x", either the old or the new value is most likely wrong, and the diff does not give any indication which of those is the case. Adding Q numbers would help a bit (actually, they are already there, as a tooltip), but not really much - if Q8436 changed to Q35409, is that good or bad? I think, adding the descriptions would actually help more than the Q numbers.

(Actually, even though there now is the "Descriptions" gadget, I'd still support descriptions being displayed for linked items in statements in the item view, too. This would not only help in finding incorrect statements, it would also increase the value of Wikidata item pages for human readers, I believe. However, I would consider this a usability improvement, while for the diffs it would actually be a problem's possible solution.) --YMS (talk) 09:12, 27 April 2016 (UTC)

Descriptions would be good, yes, but Q numbers are a start in that they make it far more obvious what has changed and if the same change is being made to many items then you only need to look at the items once. Thryduulf (talk: local | en.wp | en.wikt) 12:36, 27 April 2016 (UTC)

+1 to displaying the Q number. I'm used to the display of Template:Q, it looks weird without it. :P More seriously: The Q number is what actually changed and what unambiguously distinguishes them, so it makes sense to display that. Displaying descriptions won't solve the problem if neither item has a description, for example. - Nikki (talk) 07:41, 5 May 2016 (UTC)

Query service returns 502 Bad Gateway for all queries

Tracked in Phabricator
Task T134238

The query service seems to be down, running any example queries ("Even more cats" for instance) from the wikidata query service results in an error (502).

I've tried from different ip addresses (in the UK) over the last 10 hours and see the same error. I've also tried navigating to the api endpoint in a browser, but that also isn't working: https://query.wikidata.org/sparql (results in 502 bad gateway).

Hopefully this is the correct place to raise this issue, will happily provide more info as needed.  – The preceding unsigned comment was added by BenjaminWikiData (talk • contribs).

I'm getting the same error. I've filed a bug on Phabricator: phab:T134238. --Yair rand (talk) 09:09, 3 May 2016 (UTC)

The issue is being looked into and a workaround is in place (updates are not being applied right now). Cheers, Hoo man (talk) 13:33, 3 May 2016 (UTC)

Please restart it.
--- Jura 05:13, 5 May 2016 (UTC)

Seems all good again? --Lydia Pintscher (WMDE) (talk) 07:03, 5 May 2016 (UTC)

Currently it works, but the time it takes me to write this, I think it might break again.

BTW, until it works again fully, could we just turn off the main address (used by bots) and leave another one for (manual) users.
--- Jura 07:30, 5 May 2016 (UTC)

Now it doesn't
--- Jura 07:57, 5 May 2016 (UTC)

Bugs in Wikidata edits on Wikipedia watchlist

Screenshot

This is a screenshot of my English Wikipedia watchlist made several minutes ago. It shows a lot of vandalism, but in fact it looks like all these edits occurred just in one item, Q6581072 (which I do not watch). The history of the item shows that the IP only made one vandal edit and only there, but somehow it was imaged as a bunch of edits in unrelated articles on my watchlist. Waht could it be and what did go wrong here?--Ymblanter (talk) 19:14, 4 May 2016 (UTC)

For whatever reason, all these items are about sporstwomen.--Ymblanter (talk) 19:15, 4 May 2016 (UTC)

This is phab:T45578 --Pasleim (talk) 19:44, 4 May 2016 (UTC)

Ok, thanks. I still do not get which pages are affected by a single edit, but this is not so important.--Ymblanter (talk) 20:41, 4 May 2016 (UTC)

About weekly dump

What are the differences between the 4 version of dump? I normally use type 3.

1. wikidata-20160502-all-BETA.ttl.bz2 03-May-2016 15:15 7245749739
2. wikidata-20160502-all-BETA.ttl.gz 03-May-2016 12:14 9668098104
3. wikidata-20160502-all.json.bz2 02-May-2016 21:05 4792850631
4. wikidata-20160502-all.json.gz 02-May-2016 15:43 7342188547

--ValterVB (talk) 17:23, 6 May 2016 (UTC)

The .json ones represent the data as JSON, the .ttl ones (I assume) represent the data as RDF using the Turtle syntax (en:Turtle (syntax)). .gz and .bz2 are just two different compression formats. - Nikki (talk) 19:39, 6 May 2016 (UTC)

Thanks. --ValterVB (talk) 08:32, 7 May 2016 (UTC)

Strange link to deletion-log in Watchlist at Wikipedia

Some WD-action as seen from sv.Wikipedia.

This is my (User:Innocent bystander) watchlist at Wikipedia today. I merged two items here Koh-e Baba (Q2886920) and Koh-e Baba (Q22089519). In Wikipedia, this resulted in a link to the deletion-log ("raderingslogg" in Swedish, 16:04 CEST=14:04 UTC) here at Wikidata. Nothing has been deleted, why this link? -- Lavallen (talk) 15:00, 7 May 2016 (UTC) (Innocent bystander is currently a Flooder, so I use this account instead.)

Thanks! I will have a closer look. Strange indeed. --Lydia Pintscher (WMDE) (talk) 08:38, 9 May 2016 (UTC)

Add jamwiki (phab:T134017)

Currently Special:SetSiteLink throws an error: The site ID "jamwiki" is unknown. Please use an existing site ID, such as "enwiki".

Please add it.
--- Jura 06:01, 9 May 2016 (UTC)

@aude: Can you have a look please? It is a new wiki. --Lydia Pintscher (WMDE) (talk) 08:37, 9 May 2016 (UTC)

The sites and sites_identifiers tables on all Wikis need to be re-generated, that's known and documented at wikitech:Add a wiki#Wikidata. I guess that will be taken care of soon. Cheers, Hoo man (talk) 09:09, 9 May 2016 (UTC)

Issue with interface language selection

While trying to change my interface language to "Russian", I was not able to locate that language in the entire list - however in the "Common languages" section, language "Plautdietsch" gets listed, which appears to be some German dialect that, IMHO, is not that common. Is there anything I can do to select "Russian"? I had the issue while logged, with Firefox and Chrome. -- LaddΩ chat ;) 14:21, 9 May 2016 (UTC)

@Laddo: The languages are listed with their native names, so searching for русский (or even russki, you don't even need to transcribe it) will work. Cheers, Hoo man (talk) 14:40, 9 May 2016 (UTC)

Got it, thanks. -- LaddΩ chat ;) 16:05, 9 May 2016 (UTC)

Property suggestor: add Freebase ID (P646) to $wgPropertySuggesterDeprecatedIds

As users are unlikely to find and add these ids, please add them to $wgPropertySuggesterDeprecatedIds . This configuration parameter seems to blacklist properties.

For a similar commit by @Matěj Suchánek: see https://gerrit.wikimedia.org/r/#/c/271971/ . Supposedly, the suggestion files will need to be re-generated.
--- Jura 21:30, 11 May 2016 (UTC)

https://gerrit.wikimedia.org/r/#/c/288404/ I am not sure what we actually need to introduce a new suggestions set. Matěj Suchánek (talk) 15:21, 12 May 2016 (UTC)

Let's see what happens once it's live. Currently P646 gets suggested almost everywhere.
--- Jura 07:10, 13 May 2016 (UTC)

@Jura1, Matěj Suchánek: I've just deployed the change in question, I hope it's better now. Cheers, Hoo man (talk) 15:02, 16 May 2016 (UTC)

I haven't seen a suggestion for P646 yet, so I suppose it works. Thanks to both of you (and to the other three reviewers of this change).
--- Jura 18:43, 16 May 2016 (UTC)

Using vertical bar character in monolingual text datatype property

Tracked in Phabricator
Task T135397

I'm trying to use the vertical line character, "|" (ASCII 124, Unicode U+007C) in a monolingual text property, like comment (DEPRECATED) (P2315). My text input gets truncated from that point to the end. Is there a workaround for that limitation? -- LaddΩ chat ;) 17:40, 14 May 2016 (UTC)

| does not work. -- Innocent bystander (talk) 19:50, 14 May 2016 (UTC)

∣ (U+2223 DIVIDES), ǀ (U+1C0 LATIN LETTER DENTAL CLICK) and ❘ (U+2758 LIGHT VERTICAL BAR) offer visual but not semantic approximations and all work. I would imagine they would be confusing at best to users of screen readers though. Thryduulf (talk: local | en.wp | en.wikt) 20:41, 14 May 2016 (UTC)

Thanks for the hint. Any reason why "|" is not handled ? -- LaddΩ chat ;) 19:05, 15 May 2016 (UTC)

I guess is that it is used internally to mark the end of the field but is not being escaped properly (c.f. en:template:! which exists to allow a literal | character in template parameters). @Lydia Pintscher (WMDE): is quite likely to know more than me. Thryduulf (talk: local | en.wp | en.wikt) 23:37, 15 May 2016 (UTC)

@Laddo: I just looked into that briefly and filed T135397. Cheers, Hoo man (talk) 15:29, 16 May 2016 (UTC)

Datatype conversion needed

ARKive ID (archived) (P2833) was wrongly created (due to the age of the proposal) with datatype "string", but should be "external id". Please can someone covert it? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:28, 16 May 2016 (UTC)

@Pigsonthewing: Done. - Hoo man (talk) 15:04, 16 May 2016 (UTC)

Implementing on wiki propertypath

Hi devteam, its been suggested by Izno that I drop a word about a little project of mine here : so please read the message about an extension of SPARQL PropertyPath for wikidata : this https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat&diff=337289018&oldid=337288263 . But what actually motivate me to post here is that in the lua implementation I'd like to implement the retrieving of results in the form of iterators and coroutines would be an incommensurable help to do this. Problem : they are not currently activated by scribunto. If any of you could do anything about it, I'd appreciate :) author  TomT0m / talk page 08:08, 18 May 2016 (UTC)

Template:Ping@Hoo man Can you have a look please? --Lydia Pintscher (WMDE) (talk) 08:47, 18 May 2016 (UTC)

Fix the ping @Hoo man:. --Izno (talk) 11:25, 18 May 2016 (UTC)

I don't think there's much to do for us here, the main problem is to get coroutines security reviewed, also I find the imagination of having multiple parallel threads running for a single web request/ parse scary. Regarding the actual property path implementation: No matter how this is implemented, it will probably be rather slow, given it needs to fully load and examine all entities it "passes", I'm not sure that's ok to do for a wiki page. Cheers, Hoo man (talk) 09:28, 24 May 2016 (UTC)

Problem editing label to remove pathenthetical

Tracked in Phabricator
Task T135714

A user reported to me problems with editing Kevin Williams (Q14951176) to change the label from "Kevin Williams (wide receiver)" to "Kevin Williams". The UI failed to save. I reproduced with the API, and got this response:

I managed to fix the label by deleting both label and description and then readding both. My hypothesis is that we have code to check whether a label/description edit is null, and that it is somehow becoming confused in this case. Cheers, Bovlb (talk) 16:17, 18 May 2016 (UTC)

I've encountered this too and I'm quite sure we have a bug open for this. When you edit several fields (label and description) and you press save, the interface will start saving your changes. It will first try to save the label and after that the description. Because the description is not saved first, the saving of the label will trigger an error, because the <new label> & <old description> combination already exists. The interface should probably first save the descriptions and after that the labels to prevent this from happening. Multichill (talk) 16:41, 18 May 2016 (UTC)

Thanks. I see now what the problem was. I have advised the user to save a unique description first in this case. Maybe the UI could give a clearer explanation of the problem to suggest this action. Cheers, Bovlb (talk) 18:06, 18 May 2016 (UTC)

@Bovlb, Multichill: I think the problems you encounter here are related to T135714, but not to T106456 (which can be worked around by simply reloading the page). Cheers, Hoo man (talk) 09:26, 19 May 2016 (UTC)

preload of items ?

Hi, there is a mediawiki functionality that allows to create wiki pages from another page by "preloading". I'd find it handy to be able to do that to create a wikidata item. Could it be possible to create an item with a set of statements loaded from a wikipage written in a json dump similar format ? author  TomT0m / talk page 19:02, 21 May 2016 (UTC)

This should be doable with a gadget or similar tool. --Lydia Pintscher (WMDE) (talk) 10:38, 23 May 2016 (UTC)

@TomT0m: User:Magnus_Manske/duplicate_item.js can apparently duplicate an item excluding the descriptions and sitelinks. I'm not sure if that's quite what you want (an actual example would help :)). I'm guessing it's not, since I can't think of any reason to duplicate an item and keep all the labels/aliases the same, but it looks like it could be modified quite easily to only duplicate statements or to duplicate descriptions instead of labels and aliases. - Nikki (talk) 10:47, 27 May 2016 (UTC)

Property_talk:P2481#This is identifier

Maybe you want to comment there.
--- Jura 05:46, 28 May 2016 (UTC)

@Jura1:  Done. - Hoo man (talk) 11:42, 28 May 2016 (UTC)

honor format as a regular expression (P1793) when editing properties

Tracked in Phabricator
Task T105126

I am sure there already is a phabricator wishlist item open for this, but I would like to stress how really, really helpful it would be if values that are not allowed according to this property would be rejected. Currently, cleaning up violations takes a lot of editor time and of course values that violate the regexp are basically useless, until fixed. Even a simple validation on the Javascript level would be very welcome. --Srittau (talk) 15:51, 22 May 2016 (UTC)

This is indeed tracked as T105126, but there is no ongoing work on any of the WikibaseQuality extensions right now. Cheers, Hoo man (talk) 23:42, 22 May 2016 (UTC)

I am currently talking to a student who might be willing to work on the quality extensions. --Lydia Pintscher (WMDE) (talk) 09:27, 30 May 2016 (UTC)

Different behavior of qualifier suggestions

Qualifiers suggestions behave different when editing existing value or when adding new value (not working at all). For example, Property:P585 is not suggested for newly added Property:P166. --EugeneZelenko (talk) 01:45, 29 May 2016 (UTC)

I think that's phab:T102324 (and yeah, it's annoying). - Nikki (talk) 07:09, 30 May 2016 (UTC)

That's an old bug. If it can't be solved, I think it would be preferable to suppress suggestions for these entirely.
--- Jura 09:54, 30 May 2016 (UTC)

Adding new statements to large items

Hello, Recently I have added manually statements to large items, for instance Germany (Q183). Adding turned out to be a bit annoying, as I had to scroll down quite a bit and didn't work on the fastest computer with fastest connections. Is there a way to move this to the top of the page? Kind regards, Lymantria (talk) 13:16, 27 May 2016 (UTC)

@Lymantria: Relocation of "add" button may be done as part of the ongoing UI redesign; in the mean time, you may activate gadget KeyShortcuts in your Preferences and use key "i" to jump to the bottom of the statements. -- LaddΩ chat ;) 12:07, 28 May 2016 (UTC)

Thanks for the helpful workaround. Lymantria (talk) 06:59, 30 May 2016 (UTC)

You can press "a" to start adding a new statement, no need to use "i" first. :) - Nikki (talk) 07:00, 31 May 2016 (UTC)