Wikidata:Contact the development team/Archive/2019/03

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

wrong edit summaries

Hey, in this edit the statement native language (P103)=Spanish (Q1321) was removed but the edit summary states native language (P103)=Russian (Q7737). --Pasleim (talk) 09:04, 15 February 2019 (UTC)

@Pasleim : your "this edit" is not a link to an edit, but new section. — billinghurst sDrewth 12:12, 18 February 2019 (UTC)

Oops, wrong link copied. Now corrected. --Pasleim (talk) 13:12, 18 February 2019 (UTC)

Thanks. Have you seen this happen anywhere else already or is this the only case? Either way I'll have a look. --Lydia Pintscher (WMDE) (talk) 16:20, 18 February 2019 (UTC)

It might be linked to the vandalism revert a few seconds before [1]. --- Jura 13:08, 3 March 2019 (UTC)

SPARQL endpoint for low-end server

Dear all,

I'm looking to run Wikibase and a corresponding SPARQL endpoint on a low-end server, i.e. 1GB RAM (actually, it's a raspberry pi). Wikibase runs fine and I'm happy with it, however, obviously, the WDQS won't load, it needs more memory. My question is, is there any alternative for running a simple(r) SPARQL endpoint on my wikibase's data, possible for an 1GB server? E.g., could I try to use https://github.com/wmde/WikibaseQuery? Or please indicate who/where to best ask the question.

Many thanks in advance

Kind regards

Ath. Siaperas

Hello, and thanks for your question! @Smalyshev (WMF): can you help? Lea Lacroix (WMDE) (talk) 16:52, 26 February 2019 (UTC)

You could try exploring other SPARQL solutions, like Apache Fuseki or Apache Marmotta or GraphDB. Unfortunately, I imagine most Java solutions would be memory-hungry. I don't think WikibaseQuery is supported anymore. I think the best approach if you want SPARQL would be to use RDF dumps (those still should work on low memory) if your data set is small, and try to find RDF/SPARQL database that is not too memory-hungry. RDF should be compatible with most standard implementations and of course special services from WDQS would not work but most of the things would. You could use lists like https://en.wikipedia.org/wiki/Comparison_of_triplestores and check out triplestores that support SPARQL. Smalyshev (WMF) (talk) 23:13, 26 February 2019 (UTC)

Million thanks! I'll follow-up on the links and will let you know how it goes. Doesn't seem like an easy task as most implementations seem to have higher requirements, but I'll give it a try and if I succeed I will report back. Kind regards. A.siaperas (talk) 14:20, 27 February 2019 (UTC)

Update 1/3/2019: Apache Marmotta seems to work (finally), after having to tweak the default Postgres database schema, so as to accept languages more than 5 characters (e.g. @"simple" and @"tokipona", table: nodes, column: lang, varchar(5) -> varchar(10)). I tried (and failed) to run blazegraph e.g. by increasing swap space: I was getting a java.lang.OutOfMemoryError at java.util.zip.Inflater.inflateBytes. I might also try the chances for Ontotext's GraphDB. --94.67.210.34 18:50, 1 March 2019 (UTC)

Help with Direct Access on custom Wikibase

Dear All, I am writing here to ask for help about a custom Wikibase installation: they told me in IRC channel that the Dev team also support Wikibase and they suggested me to get in touch with you on this page.

Just as a brief introduction: we already have a productive 15.000 pages custom wiki. Since it is quite data-intensive, we would like to implement Wikibase and migrate the more structured data there.
Before going Wikibase on the productive Wiki, I setup a local machine for testing purpose and to gain experience on this extension. So I setup two MediaWiki instances: one with the Repository and Client extensions to act as "database" and the other one with only Client extension, intended to only consume data.

I read all the documentation I found and I was able to make everything work, although with some trial-and-error, but I can only read items with Arbitrary Access doing something like {{#statements:P1|from=Q1}}.
Trying the Direct Access like {{#statements:P1}} results in an empty string.

From the documentation I read, it is not fully clear to me why this is not working, but I assume this is because the Direct Access needs a link from the Item page to the Wiki page where I want to use the Direct Access #statements.
My first question is: am I right in this assumption? Is this the reason of the issue?

Following my assumption, I went on creating the proper record in the sites table of the MediaWiki Installation.
After setting up the $wgWBRepoSettings['siteLinkGroups'] variable with the corresponding group in the MediaWiki sites table I modified as above, I was actually able to see the SiteLink boxes in the Item page.
I can properly use the standard Wikipedia box and add links, but this is not working with the sites I customized in the sites table.

I know the site_global_key is recognized because, when I start typing, the full string is suggested with the auto-completion. Nevertheless, the page name is not auto-completed and, even if I type the full title, an error message is shown that the page cannot be found.
I double checked that the page_path is properly set in the site_data field of the sites table.

I am really lost on what I am doing wrong and how to fix the configuration.
Any suggestion from you side will be very appreciated. Thanks.

Lucamauri (talk) 16:44, 13 March 2019 (UTC)

Hello @Lucamauri: and thanks for trying Wikibase!

Your assumptions is right :)
We are aware of this issue, since several people already reported it. The current problem lies in the documentation that is not specific enough, we will work on it as soon as possible. Lea Lacroix (WMDE) (talk) 09:19, 14 March 2019 (UTC)

Thanks @Lea Lacroix (WMDE): for helping and thanks for confirming my conclusion. Thanks also to @Lydia Pintscher (WMDE): 😊
In fact it was my intention to contribute to the documentation page as soon as I get my test environment working.
I see that you prioritized the creation of the documentation, but in the meantime can you briefly explain me how to get it works? Even without a formal full documentation, I would like to move on with my test. Additionally, I would be willing to help with the documentation if I figure it out.
Thanks in advance
Lucamauri (talk) 09:58, 14 March 2019 (UTC)

Could you take a look in your browser's JS console when trying to add a sitelink? This should probably show the failed requests looking for the site to add. Perhaps you could also dump the rows of your sites table and the value of $wgWBRepoSettings['siteLinkGroups']? Cheers! T Arrow (talk) 11:57, 14 March 2019 (UTC)

I finally found out the problem. In sites table I wrote page_path field alone, while I realized file_path field was necessary as well. So I added it and it started working. By the way I realized the addSite.php script cannot be used (either the script is faulty or the documentation does not represent its real usage), so i resolved creating a XML file with the sites and use importSites.php instead. It was very late in the night so I just did a limited test, but everything looks good now.
In the weekend I will surely find some time to contribute to the official documentation with the experience I made.
Again, thanks a lot to all the people here that helped me.
Lucamauri (talk) 08:06, 15 March 2019 (UTC)

This section was archived on a request by: Regards, ZI Jony ^(Talk) 09:13, 20 March 2019 (UTC)

results getting mixed up?

Hi,

If I execute the query (CONSTRUCT {?s ?p ?o.} WHERE { VALUES ?s {wds:Q44578-5412D4A8-8FB0-4347-A5B7-4A50EEA44409} ?s ?p ?o.}):

https://query.wikidata.org/bigdata/namespace/wdq/sparql?format=json&query=CONSTRUCT+%7B%3Fs+%3Fp+%3Fo.%7D+WHERE+%7B+VALUES+%3Fs+%7Bwds%3AQ44578-5412D4A8-8FB0-4347-A5B7-4A50EEA44409%7D+%3Fs+%3Fp+%3Fo.%7D

multiple times in rapid succession (programmatically, though not in parallel) it will return results for a different query (and not the same one every time) 5-10% of the time.

I was unable to reproduce by repeatedly clicking the button at https://query.wikidata.org/, but maybe I'm not fast enough? Both the correct and incorrect results are valid JSON and don't otherwise appear strange (i.e. it's not junk - it's the result of *an actual* query, just not mine). The particular wds:xxx seems irrelevant - I've reproduced it with different URIs.

Is this a known issue?

Edit 1: "rapid succession" is a red herring - I still see the behavior when inserting a 5 second pause between queries (1 out of 20 queries returned the wrong results).

Edit 2: Ok, this is strange, but probably a clue. If I remove the format=json parameter then out of 20 attempts I got 19 correct results in XML and 1 wrong result *in JSON*!

Edit 3: I'm having trouble reproducing this today (which is the day after the original comment and edits 1 and 2). So far, all queries have at least returned the same results, though occasionally (2 out of ~1000 queries) in the wrong format (I specify format=json and it sends xml). I realize that I probably sound crazy :-)

Hi! I don’t think I’ve heard of this issue before, it sounds like some cache might be misbehaving and mixing up requests and responses.

I tried to reproduce the issue, but so far I’ve always gotten identical results for this query, regardless of whether I requested the same URL (i. e. got a cached response) or added some meaningless but cache-breaking URL parameter. Can you share some more details about the requests you’re making? For example, are you running the same query in multiple times quick succession, or similar but different queries?

Also, are you perhaps behind some kind of cache or proxy (e. g. internal corporate network, privacy-preserving VPN, or something else)? If no one has noticed this issue before, even though it sounds like you’re encountering it fairly frequently, then perhaps the issue is closer to your end of the connection than to our servers. --Lucas Werkmeister (WMDE) (talk) 18:06, 15 March 2019 (UTC)

Thanks, I am on a corporate network. I'll do some more tests to try to narrow this down.

Withdrawn, it appears to have been a bug in my client. Sorry for the noise.

This section was archived on a request by: Regards, ZI Jony ^(Talk) 09:14, 20 March 2019 (UTC)

Sandbox-Musical Notation (P6604)

Tracked in Phabricator
Task T218542

Hello.In the Arabic interface, the example appears above the statement.Please fix this error.Thank you David (talk) 06:49, 17 March 2019 (UTC)

Hello,

I tested it, but I'm not sure what you mean by "the example appears above the statement". I created a ticket with a screenshot from what I see on my screen ; feel free to edit the task and add more description/screenshots if needed. Lea Lacroix (WMDE) (talk) 08:42, 18 March 2019 (UTC)

This section was archived on a request by: T218542|Regards, ZI Jony ^(Talk) 09:15, 20 March 2019 (UTC)

Unit http://www.wikidata.org/entity/undefined

Tracked in Phabricator
Task T167565

There are 33 cases where a unit http://www.wikidata.org/entity/undefined (wd:undefined) was inserted into Wikidata, apparently with User:Pasleim's reCh-Tool; an example item is Q5267784#P6125. I am pretty sure that this should not be possible. Can you please investigate? —MisterSynergy (talk) 21:41, 17 March 2019 (UTC)

@MisterSynergy: Apparently this has been a known issue for almost two years: T167565 – the HarvestTemplates issue was also pointed out at that time. (I don’t think reCh allows adding statements like that, but it looks like Pasleim is reusing the same OAuth consumer for different parts of PLtools, so the tag on the edit is a bit confusing – but the “details” link in the summary shows it’s a HarvestTemplates edit.) --Lucas Werkmeister (WMDE) (talk) 12:04, 18 March 2019 (UTC)

This query finds units that aren’t proper Wikidata items – apart from the 32 wd:undefined, the only other results are three items that were turned into redirects. --Lucas Werkmeister (WMDE) (talk) 14:02, 18 March 2019 (UTC)

There is probably just no bot which updates quantity unit IRIs after items have been merged, unlike for regular statements, qualifiers, and references. —MisterSynergy (talk) 14:06, 18 March 2019 (UTC)

Btw. this query gives correct numbers of uses of redirects as units. —MisterSynergy (talk) 14:09, 18 March 2019 (UTC)

[offtopic] not quite… if you remove the grouping and select *, you can see that ?statement is sometimes a value node, and I’m pretty sure this also doesn’t count references correctly :P [/offtopic] --Lucas Werkmeister (WMDE) (talk) 14:15, 18 March 2019 (UTC)

Well, numbers are almost correct AFAICT. Regarding references: correct, it does not count them. Quantity properties are barely used in references, thus we can safely ignore them here. —MisterSynergy (talk) 14:53, 18 March 2019 (UTC)

CCing Ivan A. Krestinin because as far as I’m aware it’s usually his KrBot that cleans up these redirects. --Lucas Werkmeister (WMDE) (talk) 14:17, 18 March 2019 (UTC)

This section was archived on a request by: Regards, ZI Jony ^(Talk) 04:18, 30 March 2019 (UTC)

Sitelink to local private mediawiki

Tracked in Phabricator
Task T220506

Dear Devs,
One question about my private Wikibase installation.

I'm up to using Sitelinks, pointing to my local Mediawiki installation, which has $wgGroupPermissions false for all (i.e. private wiki). I added my site to the Sites table, "Wikipedia" group, via maintenance/exportSites.php and importSites.php. This works, and my new Site is found at the autocomplete, when I Edit the sitelinks in one Item.

Unfortunately, the problem is that no page is found.

By checking the logs, I see that actually, a call is made to the api.php?search="Page" and a "readapidenied" is returned.

In fact, if I turn the $wgGroupPermissions to True in LocalSettings.php, it all works, I get the pages found.

However, I need my wiki to stay private.

What would be possible options? Could I activate API:Login somehow for these calls? Any other way out?

Many thanks in advance

Kind regards

Thanos Siaperas A.siaperas (talk)

Hi Thanos, this is a case we are not supporting so far it seems. Can you file a ticket on phabricator.wikimedia.org? --Lydia Pintscher (WMDE) (talk) 14:19, 31 March 2019 (UTC)

Done: https://phabricator.wikimedia.org/T220506. Many thanks --A.siaperas (talk) 13:51, 9 April 2019 (UTC)

This section was archived on a request by: Regards, ZI Jony ^(Talk) 11:51, 10 April 2019 (UTC)

Using commons sitelinks rather than P373 in the sidebar?

Tracked in Phabricator
Task T145279

I'm not sure if this is the right place to ask this or not. At the moment, on Wikipedias and elsewhere, Commons category (P373) is used in the left-hand sidebar to link to Commons. Ideally that should use the Commons sitelink, though - and it should follow through topic's main category (P910) to get that sitelink from the category item if needed. It should only use P373 as a fallback if no suitable sitelink (to a commons category) is available. Should I file this as a ticket on Phabricator, or does it need consensus to be established somewhere first, and if so, where? Thanks. Mike Peel (talk) 19:24, 29 March 2019 (UTC)

Hey Mike :) The current implementation is based on what people asked for back then so I don't think we should change it unless there is broader consensus to do so. --Lydia Pintscher (WMDE) (talk) 14:21, 31 March 2019 (UTC)

@Lydia Pintscher (WMDE): Do you know where that discussion took place, please? That might be a suitable venue for me to seek consensus for this change. Thanks. Mike Peel (talk) 17:52, 31 March 2019 (UTC)

The thing I can find is phabricator:T145279. I am reasonably sure there were other discussions as well but I am not sure where. --Lydia Pintscher (WMDE) (talk) 10:45, 2 April 2019 (UTC)

This section was archived on a request by: Regards, ZI Jony ^(Talk) 11:50, 10 April 2019 (UTC)