date:20160211

adrianheine added subscribers: Tobi_WMDE_SW, JanZerebecki.
adrianheine added a comment.

@tobi_WMDE_SW @addshore @janzerebecki Rate limiting settings for beta need to 
be adapted, either by IP or in general.


TASK DETAIL
  https://phabricator.wikimedia.org/T126585

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: adrianheine
Cc: JanZerebecki, Tobi_WMDE_SW, Addshore, adrianheine, Aklapper, Izno, 
Wikidata-bugs, aude, Mbch331, greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T126512: flaky qunit test wikibase.getLanguageNameByCode wikibase.getLanguageNameByCode()

gerritbot added a project: Patch-For-Review.

TASK DETAIL
  https://phabricator.wikimedia.org/T126512

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, daniel, Jonas, adrianheine, aude, Aklapper, hoo, JanZerebecki, 
StudiesWorld, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T126512: flaky qunit test wikibase.getLanguageNameByCode wikibase.getLanguageNameByCode()

gerritbot added a subscriber: gerritbot.
gerritbot added a comment.

Change 269919 had a related patch set uploaded (by Adrian Heine):
Always get ULS data through jQuery

https://gerrit.wikimedia.org/r/269919


TASK DETAIL
  https://phabricator.wikimedia.org/T126512

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, daniel, Jonas, adrianheine, aude, Aklapper, hoo, JanZerebecki, 
StudiesWorld, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Reopened] T125521: [Task] Refactor how formatters are passed to valueview

adrianheine reopened this task as "Open".

TASK DETAIL
  https://phabricator.wikimedia.org/T125521

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: adrianheine
Cc: Aklapper, adrianheine, aude, hoo, thiemowmde, Lydia_Pintscher, 
Tobi_WMDE_SW, Bene, gerritbot, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T125521: [Task] Refactor how formatters are passed to valueview

adrianheine moved this task to Review on the Wikidata-Sprint-2016-02-02 
workboard.

TASK DETAIL
  https://phabricator.wikimedia.org/T125521

WORKBOARD
  https://phabricator.wikimedia.org/project/board/1722/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: adrianheine
Cc: Aklapper, adrianheine, aude, hoo, thiemowmde, Lydia_Pintscher, 
Tobi_WMDE_SW, Bene, gerritbot, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T126585: Sitelink browser test sometimes fails with firefox

Tobi_WMDE_SW added a subscriber: aude.
Tobi_WMDE_SW added a comment.

Probably @aude can help with this?


TASK DETAIL
  https://phabricator.wikimedia.org/T126585

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Tobi_WMDE_SW
Cc: aude, JanZerebecki, Tobi_WMDE_SW, Addshore, adrianheine, Aklapper, Izno, 
Wikidata-bugs, Mbch331, greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T125521: [Task] Refactor how formatters are passed to valueview

gerritbot added a comment.

Change 268387 had a related patch set uploaded (by Adrian Heine):
Replace wb.formatters.getStore with ValueFormatterFactory

https://gerrit.wikimedia.org/r/268387


TASK DETAIL
  https://phabricator.wikimedia.org/T125521

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: adrianheine, gerritbot
Cc: Aklapper, adrianheine, aude, hoo, thiemowmde, Lydia_Pintscher, 
Tobi_WMDE_SW, Bene, gerritbot, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Block] T124042: [Task] Adapt UI to use new wbformatvalue parameter

adrianheine reopened blocking task T125521: [Task] Refactor how formatters are 
passed to valueview as "Open".

TASK DETAIL
  https://phabricator.wikimedia.org/T124042

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Bene, adrianheine
Cc: daniel, gerritbot, Bene, Tobi_WMDE_SW, Lydia_Pintscher, thiemowmde, hoo, 
aude, adrianheine, Aklapper, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T125636: [Task] Release Wikibase DataModel 5.0

2016-02-11 Thread thiemowmde

thiemowmde added a comment.

I rechecked all the breaking changes to ReferenceList, Item and Property again 
and uploaded an additional pull request.

- https://github.com/wmde/WikibaseDataModel/pull/616 should be merged first 
because it fixes a critical bug. Note that this is currently not in the release 
notes. I would like to update the release notes manually before doing an actual 
release, to not run into more merge conflicts.
- https://github.com/wmde/WikibaseDataModel/pull/621 is my new pull request.
- I also rebased https://github.com/wmde/WikibaseDataModel/pull/603. It 
contains a series of fixes I uploaded a week ago. Still nobody reviewed the 
changes, all posts in the discussion are about something else.


TASK DETAIL
  https://phabricator.wikimedia.org/T125636

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: thiemowmde
Cc: Aklapper, daniel, adrianheine, JeroenDeDauw, Bene, thiemowmde, 
Tobi_WMDE_SW, Izno, Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T126585: Sitelink browser test sometimes fails with firefox

2016-02-11 Thread Addshore

Addshore added a subscriber: Addshore.
Addshore added a comment.

Probably something relating to 
https://www.mediawiki.org/wiki/Manual:$wgRateLimits ?


TASK DETAIL
  https://phabricator.wikimedia.org/T126585

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: Addshore, adrianheine, Aklapper, Izno, Wikidata-bugs, aude, Mbch331, greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T126510: Allow adding arbitrary languages in the interface

Lydia_Pintscher added a subscriber: Lydia_Pintscher.
Lydia_Pintscher added a comment.

Before we do add the ability to add more I'd like to see an analysis of how 
often the following case actually happens: I want to add a 
label/description/alias for a language that I have not set as my babel 
language, isn't my browser language, isn't inferred based on location and 
doesn't at least have one entry already. My gut feeling this case is very rare 
and I'd like to avoid adding more creep to the user interface it in this case.


TASK DETAIL
  https://phabricator.wikimedia.org/T126510

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Lydia_Pintscher
Cc: Lydia_Pintscher, Mbch331, Aklapper, matej_suchanek, StudiesWorld, Izno, 
Wikidata-bugs, aude



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Retitled] T126585: Sitelink browser test sometimes fails with firefox

adrianheine changed the title from "Sitelink browser test fails with firefox" 
to "Sitelink browser test sometimes fails with firefox".
adrianheine edited the task description.
adrianheine set Security to None.

TASK DETAIL
  https://phabricator.wikimedia.org/T126585

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: adrianheine
Cc: adrianheine, Aklapper, Izno, Wikidata-bugs, aude, Mbch331, greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Created] T126585: Sitelink browser test fails with firefox

adrianheine created this task.
adrianheine added a subscriber: adrianheine.
adrianheine added projects: Browser-Tests, Wikidata.
Herald added a subscriber: Aklapper.

TASK DESCRIPTION
  Edit sitelinks/Remove multiple sitelinks fails on sauce and locally in 
firefox:
  
  ```
  And I remove all sitelinks   # 
features/step_definitions/sitelinks_steps.rb:51
unable to locate element, using 
{:css=>"div[data-wb-sitelinks-group='wikipedia'] .wikibase-toolbar-container 
span.wikibase-toolbar-button-edit:not(.wikibase-toolbarbutton-disabled) > a"} 
(Watir::Exception::UnknownObjectException)
(eval):1:in `process_watir_call'
./features/support/modules/sitelink_module.rb:71:in 
`remove_all_sitelinks'
./features/step_definitions/sitelinks_steps.rb:52:in `/^I remove all 
sitelinks$/'
features/sitelinks.feature:204:in `And I remove all sitelinks'
  ```

TASK DETAIL
  https://phabricator.wikimedia.org/T126585

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: adrianheine
Cc: adrianheine, Aklapper, Izno, Wikidata-bugs, aude, Mbch331, greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T126585: Sitelink browser test sometimes fails with firefox

adrianheine added a comment.

This is a rate limiting problem. Whenever the test fails, I have the following 
in my debug log:

  [ratelimit] User '0:0:0:0:0:0:0:1' (IP ::1) tripped 
my_wiki:limiter:edit:ip:%3A%3A1 at 8 (limit 8 in 60s)


TASK DETAIL
  https://phabricator.wikimedia.org/T126585

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: adrianheine
Cc: adrianheine, Aklapper, Izno, Wikidata-bugs, aude, Mbch331, greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Re: [Wikidata] SPARQL CONSTRUCT results truncated

2016-02-11 Thread Stas Malyshev

Hi!

> For me, it’s perfectly ok when a query runs for 20 minutes, when it
> spares me some hours of setting up a specific environment for one
> specific dataset (and doing it again when I need current data two month
> later). And it would be no issue if the query runs much longer, in
> situations where it competes with several others. But of course, that’s
> not what I want to experience when I use a wikidata service to drive,
> e.g., an autosuggest function for selecting entities.

I understand that, but this is a shared server which is supposed to
serve many users, and if we allow to run 20-minute queries on this
service, soon enough it would become unusable. This is why we have
30-second limit on the server.

Now, we have considered having an option for the server or setup that
allows to run longer queries, but currently we don't have one. It would
require some budget allocation and work to make it, so it's not
something we can have right now. There are use cases for very long
queries and very large results, the current public service endpoint is
just not good in serving them, because it's not what it was meant for.

> And do you think the policies and limitations of different access
> strategies could be documented? These could include a high-reliability

I agree that limitations better to be documented, the problem is we
don't know everything we may need to document. Such as "what are queries
that may be bad". When I see something like "I want to download
million-row dataset" I know it's probably a bit too much. But I can't
have hard rule that says 1M-1 is ok, but 1M is too much.

> preferred option). And on the other end of the spectrum something what
> allows people to experiment freely. Finally, the latter kind of

I'm not sure how I could maintain an endpoint that would allow people to
do anything they want and still provide adequate experience for
everybody. Maybe if we had infinite hardware resources... but we do not.

Otherwise, it is possible - and should not be extremely hard - to set
one's own instance of the Query Service and use it for experimenting
with heavy lifting. Of course, that would require resources - but
there's no magic here, it'd require resources from us too, both in terms
of hardware and people that would maintain it. So some things we can do
now, some things we would be able to do later, and some things we
probably would not be able to offer with any adequate quality.
-- 
Stas Malyshev
smalys...@wikimedia.org

___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

[Wikidata-bugs] [Maniphest] [Commented On] T126671: Quantity values are recorded as 0 because of Munger bug

gerritbot added a comment.

Change 270149 merged by jenkins-bot:
Fix number parsing

https://gerrit.wikimedia.org/r/270149


TASK DETAIL
  https://phabricator.wikimedia.org/T126671

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Smalyshev, gerritbot
Cc: gerritbot, Aklapper, Smalyshev, debt, Gehel, Izno, jkroll, Wikidata-bugs, 
Jdouglas, aude, Deskana, Manybubbles, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T57755: allow time values more precise than day

2016-02-11 Thread Jobu0101

Jobu0101 added a subscriber: Jobu0101.
Jobu0101 added a comment.

I tried a few weeks ago to set a time value more precise than day than day 
using the API. This also did not work. So I don't agree with duplicatebug that 
this is only a GUI problem. I think the API problem should be of higher 
priority.


TASK DETAIL
  https://phabricator.wikimedia.org/T57755

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Jobu0101
Cc: Jobu0101, Laddo, Aklapper, MGChecker, Yair_rand, Apsdehal, Wikidata-bugs, 
Ricordisamoa, Lydia_Pintscher, Ltrlg, Izno, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T117520: Index Wikidata labels, aliases and descriptions as separate fields in ElasticSearch

Tobi_WMDE_SW added a project: Wikidata-Sprint-2016-02-16.

TASK DETAIL
  https://phabricator.wikimedia.org/T117520

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Tobi_WMDE_SW
Cc: hoo, Ricordisamoa, aude, Deskana, StudiesWorld, Aklapper, Smalyshev, debt, 
Gehel, Izno, Wikidata-bugs, jayvdb, Mbch331, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118860: [RFC] Use Role Object Pattern to represent derived data in the data model

Tobi_WMDE_SW added a subscriber: Tobi_WMDE_SW.
Tobi_WMDE_SW added a comment.

@daniel is this resolved by now?


TASK DETAIL
  https://phabricator.wikimedia.org/T118860

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel, Tobi_WMDE_SW
Cc: Tobi_WMDE_SW, Bene, Lydia_Pintscher, mkroetzsch, adrianheine, hoo, 
thiemowmde, aude, Jonas, JanZerebecki, JeroenDeDauw, Aklapper, StudiesWorld, 
daniel, Izno, Luke081515, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T119067: Adjust rescoring config for Wikidata to consider sitelink count

aude added a comment.

we definitely need to also include labels as part of the scoring.

otherwise I get strange results like Q4 on Wikidata would rank higher than Q3 
when searching for "life", just because Q4 mentions "life" in the description. 
(and Q4 has more sitelinks, e.g. on Wikiquote)

so, I'd like to somehow like to treat labels in the search (and maybe fallback 
languages) like titles are treated now in Cirrus, and probably labels in other 
languages and aliases with secondary weighting.  and descriptions just part of 
the all (general text) field.


TASK DETAIL
  https://phabricator.wikimedia.org/T119067

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude
Cc: Aklapper, aude, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T73992: [Story] JSON should (optionally) contain full URIs for referenced external entities

Tobi_WMDE_SW added a project: Wikidata-Sprint-2016-02-16.

TASK DETAIL
  https://phabricator.wikimedia.org/T73992

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Tobi_WMDE_SW
Cc: JanZerebecki, Aklapper, Liuxinyu970226, Tpt, Lydia_Pintscher, daniel, Izno, 
Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T126597: [Task] Move WikibaseDataModel to Gerrit

2016-02-11 Thread Qgil

Qgil removed a subscriber: Qgil.

TASK DETAIL
  https://phabricator.wikimedia.org/T126597

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Qgil
Cc: Jonas, hoo, Dereckson, Lydia_Pintscher, MZMcBride, aude, JanZerebecki, 
JeroenDeDauw, Legoktm, GPHemsley, Tobi_WMDE_SW, adrianheine, daniel, 
thiemowmde, Aklapper, mmodell, chasemp, Ricordisamoa, Liuxinyu970226, Addshore, 
Bene, Lazowik, Tpt, Krenair, Izno, Luke081515, Wikidata-bugs, Mbch331, QChris, 
greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Re: [Wikidata] SPARQL CONSTRUCT results truncated


Hi Joachim,

I think the problem is not to answer your query in 5min or so (Wikidata 
Toolkit on my laptop takes 27min without a database, by simply parsing 
the whole data file, so any database that already has the data should be 
much faster). The bigger issue is that you would have to configure the 
site to run for 5min before timeout. This would mean that other queries 
that never terminate (because they are really hard) also can run for at 
least this time. It seems that this could easily cause the service to 
break down.


Maybe one could have an "unstable" service on a separate machine that 
does the same as WDQS but with a much more liberal timeout and less 
availability (if it's overloaded a lot, it will just be down more often, 
but you would know when you use it that this is the deal).


Cheers,

Markus


On 11.02.2016 15:54, Neubert, Joachim wrote:

Hi Stas,

Thanks for your answer. You asked how long the query runs: 8.21 sec (having 
processed 6443 triples), in an example invocation. If roughly linear, that 
could mean 800-1500 sec for the whole set. However, I would expect a clearly 
shorter runtime: I routinely use queries of similar complexity and result sizes 
on ZBW's public endpoints. One arbitrary selected query which extracts data 
from GND runs for less than two minutes to produce 1.2m triples.

Given the size of Wikidata, I wouldn't consider such an use abusive. Of course, 
if you have lots of competing queries and resources are limited, it is 
completely legitimate to implement some policy which formulates limits and 
enforces them technically (throddle down long-running queries, or limit the 
number of produced triples, or the execution time, or whatever seems reasonable 
and can be implemented).

Anyway, in this case (truncation in the middle of a statement), it looks much 
more like some technical bug (or an obscure timeout somewhere down the way). 
The execution time and the result size varies widely:

5.44s empty result
8.60s 2090 triples
5.44s empty result
22.70s 27352 triples

Can you reproduce this kind of results with the given query, or with other 
supposedly longer-running queries?

Thanks again for looking into this.

Cheers, Joachim

PS. I plan to set up an own Wikidata SPAQL endpoint to do more complex things, but that 
depends on a new machine which will be available in some month. For now, I'd just like to 
know which for "our" persons (economists and the like) have wikipedia pages.

PPS. From my side, I would much more have liked to build a query which asks for 
exactly the GND IDs I'm interested in (about 430.000 out of millions of GNDs). 
This would have led to a much smaller result - but I cannot squeeze that query 
into a GET request ...


-Ursprüngliche Nachricht-
Von: Wikidata [mailto:wikidata-boun...@lists.wikimedia.org] Im Auftrag von Stas 
Malyshev
Gesendet: Donnerstag, 11. Februar 2016 01:35
An: Discussion list for the Wikidata project.
Betreff: Re: [Wikidata] SPARQL CONSTRUCT results truncated

Hi!


I try to extract all mappings from wikidata to the GND authority file,
along with the according wikipedia pages, expecting roughly 500,000 to
1m triples as result.


As a starting note, I don't think extracting 1M triples may be the best way to 
use query service. If you need to do processing that returns such big result 
sets - in millions - maybe processing the dump - e.g. with wikidata toolkit at 
https://github.com/Wikidata/Wikidata-Toolkit - would be better idea?


However, with various calls, I get much less triples (about 2,000 to
10,000). The output seems to be truncated in the middle of a statement, e.g.


It may be some kind of timeout because of the quantity of the data being sent. 
How long does such request take?

--
Stas Malyshev
smalys...@wikimedia.org

___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata




___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] SPARQL CONSTRUCT results truncated

2016-02-11 Thread Neubert, Joachim

Hi Marcus,

thank you very much, your code will be extremely helpful for solving my current 
need. And though not a Java programmer, I may be even able to adjust it to 
similar queries.

On the other side, it's some steps away from the promises of Linked data and 
SPARQL endpoints. I extremely value the wikidata endpoint for having the 
current data, so if I add some bit in the user interface, I can query for it 
immediately afterwards, and I can do this in a uniform way via standard SPARQL 
queries. I can imagine how hard that was to achieve.

And I completely agree that it's impossible to build a SPARQL endpoint which 
reliably serves arbitrary comlex queries for multiple users in finite time. 
(This is the reason why all our public endpoints at http://zbw.eu/beta/sparql/ 
are labeled beta.) And you easily can get at a point, where some ill-behaved 
query is run over and over again by some stupid program, and you have to be 
quite restrictive to keep your service up.

So an "unstable" endpoint with wider limits, as you suggested in your later 
mail, could be a great solution for this. In both instances, it would be nice 
if the policy and the actual limits could be documented, so users would know 
what to expect (and how to act appropriate as good citizens).

Thanks again for the code, and for taking up the discussion.

Cheers, Joachim

-Ursprüngliche Nachricht-
Von: Wikidata [mailto:wikidata-boun...@lists.wikimedia.org] Im Auftrag von 
Markus Krötzsch
Gesendet: Donnerstag, 11. Februar 2016 15:05
An: Discussion list for the Wikidata project.
Betreff: Re: [Wikidata] SPARQL CONSTRUCT results truncated

Hi Joachim,

Here is a short program that solves your problem:

https://github.com/Wikidata/Wikidata-Toolkit-Examples/blob/master/src/examples/DataExtractionProcessor.java

It is in Java, so, you need that (and Maven) to run it, but that's the only 
technical challenge ;-). You can run the program in various ways as described 
in the README:

https://github.com/Wikidata/Wikidata-Toolkit-Examples

The program I wrote puts everything into a CSV file, but you can of course also 
write RDF triples if you prefer this, or any other format you wish. The code 
should be easy to modify.

On a first run, the tool will download the current Wikidata dump, which takes a 
while (it's about 6G), but after this you can find and serialise all results in 
less than half an hour (for a processing rate of around 10K items/second). A 
regular laptop is enough to run it.

Cheers,

Markus

On 11.02.2016 01:34, Stas Malyshev wrote:
> Hi!
>
>> I try to extract all mappings from wikidata to the GND authority 
>> file, along with the according wikipedia pages, expecting roughly 
>> 500,000 to 1m triples as result.
>
> As a starting note, I don't think extracting 1M triples may be the 
> best way to use query service. If you need to do processing that 
> returns such big result sets - in millions - maybe processing the dump 
> - e.g. with wikidata toolkit at 
> https://github.com/Wikidata/Wikidata-Toolkit - would be better idea?
>
>> However, with various calls, I get much less triples (about 2,000 to 
>> 10,000). The output seems to be truncated in the middle of a statement, e.g.
>
> It may be some kind of timeout because of the quantity of the data 
> being sent. How long does such request take?
>

___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

[Wikidata-bugs] [Maniphest] [Commented On] T118739: Push dumps.wm.o logs files to stat1002

2016-02-11 Thread Ottomata

Ottomata added a subscriber: Ottomata.
Ottomata added a comment.

Hey sorry, I don't think I've seen this ticket before, hence the silence!  I 
just commented on ticket about pull vs. push.


TASK DETAIL
  https://phabricator.wikimedia.org/T118739

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: ArielGlenn, Ottomata
Cc: Ottomata, gerritbot, ArielGlenn, hoo, Deskana, Aklapper, Addshore, Izno, 
Wikidata-bugs, aude, Svick, Mbch331, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T112715: Enable different URL shorteners for WDQS

Lydia_Pintscher added a subscriber: Lydia_Pintscher.
Lydia_Pintscher added a comment.

I have emailed someone a link to a query that was shortened using tinyurl. The 
email did not get through twice. Once I sent the full URL the email went 
through fine. We should probably move away from tinyurl sooner rather than 
later.


TASK DETAIL
  https://phabricator.wikimedia.org/T112715

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Smalyshev, Lydia_Pintscher
Cc: Lydia_Pintscher, Aklapper, Smalyshev, debt, Gehel, Izno, jkroll, 
Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Re: [Wikidata] SPARQL CONSTRUCT results truncated

2016-02-11 Thread Gerard Meijssen

Hoi,
This is the kind of (technical) feedback that makes sense as it is centred
on need. It acknowledges that more needs to be done as we are not ready for
what we expect of ourselves in the first place.

In this day and age of big data, we are a very public place where a lot of
initiatives gravitate to. If the WMF wants to retain its relevance, it is
to face its challenges. Maybe the WDQS can steal a page out of the
architecture in what Magnus build. It is very much replicable and multiple
instances have been running. This is not to say that it becomes more and
more relevant to have the Wikidata toolkit available from Labs with as many
instances as needed.
Thanks,
 GerardM

On 12 February 2016 at 00:04, Stas Malyshev  wrote:

> Hi!
>
> > We basically have two choices: either we offer a limited interface that
> only
> > allows for a narrow range of queries to be run at all. Or we offer a very
> > general interface that can run arbitrary queries, but we impose limits
> on time
> > and memory consumption. I would actually prefer the first option,
> because it's
> > more predictable, and doesn't get people's hopes up too far. What do you
> think?
>
> That would require implementing pretty smart SPARQL parser... I don't
> think it worth the investment of time. I'd rather put caps on runtime
> and maybe also on parallel queries per IP, to ensure fair access. We may
> also have a way to run longer queries - in fact, we'll need it anyway if
> we want to automate lists - but that is longer term, we'll need to
> figure out infrastructure for that and how we allocate access.
>
> --
> Stas Malyshev
> smalys...@wikimedia.org
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

[Wikidata-bugs] [Maniphest] [Commented On] T126597: [Task] Move WikibaseDataModel to Gerrit

2016-02-11 Thread Bene

Bene added a comment.

How do releases work on gerrit? Do they integrate with packagist the same way 
it works on github currently?


TASK DETAIL
  https://phabricator.wikimedia.org/T126597

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Bene
Cc: Jonas, hoo, Dereckson, Lydia_Pintscher, MZMcBride, aude, JanZerebecki, 
JeroenDeDauw, Legoktm, GPHemsley, Tobi_WMDE_SW, adrianheine, daniel, 
thiemowmde, Aklapper, mmodell, chasemp, Ricordisamoa, Liuxinyu970226, Addshore, 
Bene, Lazowik, Tpt, Krenair, Izno, Luke081515, Wikidata-bugs, Mbch331, QChris, 
greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T126597: [Task] Move WikibaseDataModel to Gerrit

JanZerebecki added a comment.

Currently we have the github mirror configured to tigger packagist and 
packagist configured to use the github mirror. There is 
https://phabricator.wikimedia.org/T87768. Also I think using something that is 
not github with packagist currently would result in composer not being able to 
use archives instead of git clones.

Basically you create a tag on gerrit, that gets mirrored to github, which on 
good days triggers packagist, which updates its meta data from github.


TASK DETAIL
  https://phabricator.wikimedia.org/T126597

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: JanZerebecki
Cc: Jonas, hoo, Dereckson, Lydia_Pintscher, MZMcBride, aude, JanZerebecki, 
JeroenDeDauw, Legoktm, GPHemsley, Tobi_WMDE_SW, adrianheine, daniel, 
thiemowmde, Aklapper, mmodell, chasemp, Ricordisamoa, Liuxinyu970226, Addshore, 
Bene, Lazowik, Tpt, Krenair, Izno, Luke081515, Wikidata-bugs, Mbch331, QChris, 
greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T125045: fix flaky test LuaSandbox: Scribunto_LuaSandboxTests::testArgumentParsingTime Recursive argument access time was counted

gerritbot added a comment.

Change 270023 merged by jenkins-bot:
Waste CPU cycles, not wall clock time

https://gerrit.wikimedia.org/r/270023


TASK DETAIL
  https://phabricator.wikimedia.org/T125045

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, Anomie, Aklapper, JanZerebecki, StudiesWorld, Izno, 
Wikidata-bugs, aude, Dinoguy1000, jayvdb, MrStradivarius, Jackmcbarn, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Closed] T125045: fix flaky test LuaSandbox: Scribunto_LuaSandboxTests::testArgumentParsingTime Recursive argument access time was counted

JanZerebecki closed this task as "Resolved".
JanZerebecki claimed this task.

TASK DETAIL
  https://phabricator.wikimedia.org/T125045

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: JanZerebecki
Cc: gerritbot, Anomie, Aklapper, JanZerebecki, StudiesWorld, Izno, 
Wikidata-bugs, aude, Dinoguy1000, jayvdb, MrStradivarius, Jackmcbarn, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T126585: Sitelink browser test sometimes fails with firefox

gerritbot added a project: Patch-For-Review.

TASK DETAIL
  https://phabricator.wikimedia.org/T126585

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, aude, JanZerebecki, Tobi_WMDE_SW, Addshore, adrianheine, 
Aklapper, Izno, Wikidata-bugs, Mbch331, greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T126585: Sitelink browser test sometimes fails with firefox

gerritbot added a subscriber: gerritbot.
gerritbot added a comment.

Change 269944 had a related patch set uploaded (by Aude):
Exclude Sauce Labs IP ranges from rate limits on beta

https://gerrit.wikimedia.org/r/269944


TASK DETAIL
  https://phabricator.wikimedia.org/T126585

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, aude, JanZerebecki, Tobi_WMDE_SW, Addshore, adrianheine, 
Aklapper, Izno, Wikidata-bugs, Mbch331, greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T125503: [Story] Reduce initialization time of Statementview

Tobi_WMDE_SW added a project: Wikidata-Sprint-2016-02-16.

TASK DETAIL
  https://phabricator.wikimedia.org/T125503

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Tobi_WMDE_SW
Cc: gerritbot, Agabi10, thiemowmde, adrianheine, Jonas, Aklapper, Izno, 
Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T121395: [Bug] Term constraints not working

gerritbot added a comment.

Change 260585 abandoned by Aude:
Use common baserevid for label and description changes [WIP]

Reason:
we probably want to ultimately solve this by having one api request 
(wbeditentity), but then the edit summaries might not be as fine-grained as 
they are now.

https://gerrit.wikimedia.org/r/260585


TASK DETAIL
  https://phabricator.wikimedia.org/T121395

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: thiemowmde, gerritbot, Bene, Lydia_Pintscher, hoo, aude, Aklapper, daniel, 
Jonas, StudiesWorld, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T125996: Invalidate (caching) PropertyInfoStore when rebuilding wb_property_info

gerritbot added a comment.

Change 268690 abandoned by Aude:
Invalidate PropertyInfoStore when rebuilding PropertyInfoTable

Reason:
not sure we want this but i need to check more if this is an issue, and if so 
how best to solve

https://gerrit.wikimedia.org/r/268690


TASK DETAIL
  https://phabricator.wikimedia.org/T125996

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude, gerritbot
Cc: gerritbot, Aklapper, aude, StudiesWorld, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Created] T126597: [Task] Move WikibaseDataModel to Gerrit

Tobi_WMDE_SW created this task.
Tobi_WMDE_SW added subscribers: Krenair, Tpt, Lazowik, Bene, Addshore, 
Liuxinyu970226, Ricordisamoa, chasemp, mmodell, Aklapper, thiemowmde, Qgil, 
daniel, adrianheine, Tobi_WMDE_SW, GPHemsley, Legoktm, JeroenDeDauw, 
JanZerebecki, aude, MZMcBride, Lydia_Pintscher, Dereckson, hoo, Jonas.
Tobi_WMDE_SW added projects: Gerrit, Wikidata, Wikibase-DataModel.

TASK DESCRIPTION
  I suggest moving https://github.com/wmde/WikibaseDataModel to Gerrit. 
Personally, I see no strong arguments against doing this. Are there any 
blockers for this?

TASK DETAIL
  https://phabricator.wikimedia.org/T126597

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Tobi_WMDE_SW
Cc: Jonas, hoo, Dereckson, Lydia_Pintscher, MZMcBride, aude, JanZerebecki, 
JeroenDeDauw, Legoktm, GPHemsley, Tobi_WMDE_SW, adrianheine, daniel, Qgil, 
thiemowmde, Aklapper, mmodell, chasemp, Ricordisamoa, Liuxinyu970226, Addshore, 
Bene, Lazowik, Tpt, Krenair, Izno, Luke081515, Wikidata-bugs, Mbch331, QChris, 
greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Edited] T126596: During update.php (and install), add an entry in the sites table / SiteStore for the local wiki

JanZerebecki edited the task description.
JanZerebecki set Security to None.

TASK DETAIL
  https://phabricator.wikimedia.org/T126596

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: JanZerebecki
Cc: JanZerebecki, Aklapper, aude, StudiesWorld, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T126596: During update.php (and install), add an entry in the sites table / SiteStore for the local wiki

JanZerebecki added a subscriber: JanZerebecki.

TASK DETAIL
  https://phabricator.wikimedia.org/T126596

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: JanZerebecki
Cc: JanZerebecki, Aklapper, aude, StudiesWorld, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118860: [RFC] Use Role Object Pattern to represent derived data in the data model

adrianheine added a comment.

Not quite. I want to see facet usage to have more opportunities at explaining 
you why I think they are bad, since my abstract points didn't get to you yet :)


TASK DETAIL
  https://phabricator.wikimedia.org/T118860

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel, adrianheine
Cc: Tobi_WMDE_SW, Bene, Lydia_Pintscher, mkroetzsch, adrianheine, hoo, 
thiemowmde, aude, Jonas, JanZerebecki, JeroenDeDauw, Aklapper, StudiesWorld, 
daniel, Izno, Luke081515, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T114251: [RFC] Magic Infobox implementation

2016-02-11 Thread FreedomFighterSparrow

FreedomFighterSparrow added a subscriber: FreedomFighterSparrow.

TASK DETAIL
  https://phabricator.wikimedia.org/T114251

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: FreedomFighterSparrow
Cc: FreedomFighterSparrow, jmadler, Trizek-WMF, Bianjiang, Ricordisamoa, 
He7d3r, Izno, StudiesWorld, brion, Krenair, Addshore, Smalyshev, Qgil, Lucie, 
MrStradivarius, Aklapper, Lydia_Pintscher, aude, GWicke, Jdforrester-WMF, 
cscott, daniel, hoo, Wikidata-bugs, Dinoguy1000, jayvdb, Jackmcbarn, Mbch331, 
Jay8g, Ltrlg, bd808, Legoktm



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T126512: flaky qunit test wikibase.getLanguageNameByCode wikibase.getLanguageNameByCode()

gerritbot added a comment.

Change 269954 had a related patch set uploaded (by Thiemo Mättig (WMDE)):
Select first heading by class, not by id

https://gerrit.wikimedia.org/r/269954


TASK DETAIL
  https://phabricator.wikimedia.org/T126512

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, daniel, Jonas, adrianheine, aude, Aklapper, hoo, JanZerebecki, 
StudiesWorld, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T126512: flaky qunit test wikibase.getLanguageNameByCode wikibase.getLanguageNameByCode()

adrianheine added a comment.

I don't get how this fails. If `ExtensionRegistry::getInstance()->isLoaded( 
'UniversalLanguageSelector' )`, we require `ext.uls.mediawiki`. 
`ext.uls.mediawiki` depends on `ext.uls.init` as well as `jquery.uls`, which in 
turn depends on `jquery.uls.data`. Both `$.fn.uls` and `$.uls.data` should be 
initialized consistently when `wikibase.getLanguageNameByCode` is loaded. 
Unless extension registry does something strange here.


TASK DETAIL
  https://phabricator.wikimedia.org/T126512

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: adrianheine
Cc: gerritbot, daniel, Jonas, adrianheine, aude, Aklapper, hoo, JanZerebecki, 
StudiesWorld, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T126585: Sitelink browser test sometimes fails with firefox

aude added a comment.

do we need more than saucelabs ip range for this? e.g. our office IP range if 
we run these also from the office?


TASK DETAIL
  https://phabricator.wikimedia.org/T126585

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude
Cc: aude, JanZerebecki, Tobi_WMDE_SW, Addshore, adrianheine, Aklapper, Izno, 
Wikidata-bugs, Mbch331, greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T126585: Sitelink browser test sometimes fails with firefox

aude added a comment.

I think 
https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/InitialiseSettings-labs.php#L555-L557
 is where this can be set.

https://webcache.googleusercontent.com/search?q=cache:4MupWMgYdcEJ:https://support.saucelabs.com/customer/en/portal/questions/13054963
 tells us their ip range, current of at least December.


TASK DETAIL
  https://phabricator.wikimedia.org/T126585

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude
Cc: aude, JanZerebecki, Tobi_WMDE_SW, Addshore, adrianheine, Aklapper, Izno, 
Wikidata-bugs, Mbch331, greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Triaged] T125996: Invalidate (caching) PropertyInfoStore when rebuilding wb_property_info

aude triaged this task as "Normal" priority.
aude removed a project: Patch-For-Review.
aude set Security to None.

TASK DETAIL
  https://phabricator.wikimedia.org/T125996

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude
Cc: gerritbot, Aklapper, aude, StudiesWorld, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T126512: flaky qunit test wikibase.getLanguageNameByCode wikibase.getLanguageNameByCode()

gerritbot added a comment.

Change 269919 merged by jenkins-bot:
Always get ULS data through jQuery

https://gerrit.wikimedia.org/r/269919


TASK DETAIL
  https://phabricator.wikimedia.org/T126512

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, daniel, Jonas, adrianheine, aude, Aklapper, hoo, JanZerebecki, 
StudiesWorld, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T126512: flaky qunit test wikibase.getLanguageNameByCode wikibase.getLanguageNameByCode()

adrianheine added a comment.

They are not flaky imho, they consistently fail since yesterday ~ 6PM


TASK DETAIL
  https://phabricator.wikimedia.org/T126512

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: adrianheine
Cc: gerritbot, daniel, Jonas, adrianheine, aude, Aklapper, hoo, JanZerebecki, 
StudiesWorld, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T75496: [Epic] Support new types of Entities in Wikibase Repository

Tobi_WMDE_SW added a project: Wikidata-Sprint-2016-02-16.

TASK DETAIL
  https://phabricator.wikimedia.org/T75496

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Tobi_WMDE_SW
Cc: Bene, Ricordisamoa, Aklapper, adrianheine, GPHemsley, thiemowmde, 
JeroenDeDauw, JanZerebecki, aude, Lydia_Pintscher, daniel, hoo, Izno, 
Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T109675: [Task] Enable phase 1 for Wikiversity

Tobi_WMDE_SW added a project: Wikidata-Sprint-2016-02-16.

TASK DETAIL
  https://phabricator.wikimedia.org/T109675

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Tobi_WMDE_SW
Cc: Lydia_Pintscher, Lsanabria, Ricordisamoa, Liuxinyu970226, Bugreporter, 
Aklapper, TerraCodes, Johan, Izno, Luke081515, Wikidata-bugs, aude, Mbch331, 
Jay8g



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T109675: [Task] Enable phase 1 for Wikiversity

Lydia_Pintscher added a subscriber: Lydia_Pintscher.
Lydia_Pintscher added a comment.

We'll do this on February 23rd.


TASK DETAIL
  https://phabricator.wikimedia.org/T109675

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Lydia_Pintscher
Cc: Lydia_Pintscher, Lsanabria, Ricordisamoa, Liuxinyu970226, Bugreporter, 
Aklapper, TerraCodes, Johan, Izno, Luke081515, Wikidata-bugs, aude, Mbch331, 
Jay8g



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T126512: flaky qunit test wikibase.getLanguageNameByCode wikibase.getLanguageNameByCode()

gerritbot added a comment.

Change 269948 had a related patch set uploaded (by Thiemo Mättig (WMDE)):
Fix outdated CSS selectors in non_existing_item_page.rb

https://gerrit.wikimedia.org/r/269948


TASK DETAIL
  https://phabricator.wikimedia.org/T126512

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, daniel, Jonas, adrianheine, aude, Aklapper, hoo, JanZerebecki, 
StudiesWorld, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118860: [RFC] Use Role Object Pattern to represent derived data in the data model

2016-02-11 Thread daniel

daniel added a comment.

@Tobi_WMDE_SW *sigh* no. I need to write down an updated plan, to summarize the 
current state of discussion. I'm pushing back the final decision on the details 
until we are have a concrete plan to work on this. Perhaps we can talk about 
that at the next story time?

@adrianheine it's always easier to assess an idea once there is code. But in 
order to get to that point, quite a bit of work has to be done. It will be hard 
to go back, then. I suppose  I could write strawman code for the RDF mapping 
based on the proposed changes to the data model...

Interestingly, Adrian wants to see how facets are used, while Thiemo is 
concerned with how they are defined.


TASK DETAIL
  https://phabricator.wikimedia.org/T118860

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: Tobi_WMDE_SW, Bene, Lydia_Pintscher, mkroetzsch, adrianheine, hoo, 
thiemowmde, aude, Jonas, JanZerebecki, JeroenDeDauw, Aklapper, StudiesWorld, 
daniel, Izno, Luke081515, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T126512: flaky qunit test wikibase.getLanguageNameByCode wikibase.getLanguageNameByCode()

adrianheine added a comment.

qunit now passes with patch set 4, but selenium started being flaky. 
`recheck`'d.


TASK DETAIL
  https://phabricator.wikimedia.org/T126512

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: adrianheine
Cc: gerritbot, daniel, Jonas, adrianheine, aude, Aklapper, hoo, JanZerebecki, 
StudiesWorld, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T117520: Index Wikidata labels, aliases and descriptions as separate fields in ElasticSearch

Tobi_WMDE_SW added a blocked task: T119067: Adjust rescoring config for 
Wikidata to consider sitelink count.

TASK DETAIL
  https://phabricator.wikimedia.org/T117520

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Tobi_WMDE_SW
Cc: hoo, Ricordisamoa, aude, Deskana, StudiesWorld, Aklapper, Smalyshev, debt, 
Gehel, Izno, Wikidata-bugs, jayvdb, Mbch331, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T119067: Adjust rescoring config for Wikidata to consider sitelink count

Tobi_WMDE_SW added a blocking task: T117520: Index Wikidata labels, aliases and 
descriptions as separate fields in ElasticSearch.

TASK DETAIL
  https://phabricator.wikimedia.org/T119067

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Tobi_WMDE_SW
Cc: Aklapper, aude, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Re: [Wikidata] SPARQL CONSTRUCT results truncated

2016-02-11 Thread Daniel Kinzler

Am 11.02.2016 um 10:17 schrieb Gerard Meijssen:
> Your response is technical and seriously, query is a tool and it should 
> function
> for people. When the tool is not good enough fix it.

What I hear: "A hammer is a tool, it should work for people. Tearing down a
building with it takes forever, so fix the hammer!"

The query service was never intended to run arbitrarily large or complex
queries. Sure, would be nice, but that also means committing an arbitrary amount
of resources to a single request. We don't have arbitrary amounts of resources.

We basically have two choices: either we offer a limited interface that only
allows for a narrow range of queries to be run at all. Or we offer a very
general interface that can run arbitrary queries, but we impose limits on time
and memory consumption. I would actually prefer the first option, because it's
more predictable, and doesn't get people's hopes up too far. What do you think?

Oh, and +1 for making it easy to use WDT on labs.

-- 
Daniel Kinzler
Senior Software Developer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

[Wikidata-bugs] [Maniphest] [Created] T126596: During update.php (and install), add an entry in the sites table / SiteStore for the local wiki

aude created this task.
aude added a subscriber: aude.
aude added projects: Wikidata, MediaWiki-Sites.
Herald added subscribers: StudiesWorld, Aklapper.

TASK DESCRIPTION
  otherwise we may see stuff like:
  
  
https://integration.wikimedia.org/ci/job/mwext-mw-selenium-composer/1395/artifact/log/Non%20existing%20item%3A%20Edit%20tab.png
  
  an entry for at least the wiki itself would be helpful.

TASK DETAIL
  https://phabricator.wikimedia.org/T126596

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude
Cc: Aklapper, aude, StudiesWorld, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T91505: [Epic] Adding new datatypes to Wikidata

2016-02-11 Thread Qgil

Qgil removed a subscriber: Qgil.

TASK DETAIL
  https://phabricator.wikimedia.org/T91505

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Qgil
Cc: Swpb, ArthurPSmith, gerritbot, Smalyshev, Shrutika719, MGChecker, Sannita, 
Ricordisamoa, mgrabovsky, Liuxinyu970226, Rits, Physikerwelt, Lydia_Pintscher, 
Niharika, Aklapper, Izno, Wikidata-bugs, aude, Mbch331, Jay8g



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T126512: flaky qunit test wikibase.getLanguageNameByCode wikibase.getLanguageNameByCode()

gerritbot added a comment.

Change 269948 merged by jenkins-bot:
Fix outdated CSS selectors in non_existing_item_page.rb

https://gerrit.wikimedia.org/r/269948


TASK DETAIL
  https://phabricator.wikimedia.org/T126512

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, daniel, Jonas, adrianheine, aude, Aklapper, hoo, JanZerebecki, 
StudiesWorld, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Re: [Wikidata] SPARQL CONSTRUCT results truncated

2016-02-11 Thread Gerard Meijssen

Hoi,
What I hear is that the intentions were wrong in that you did not
anticipate people to get actual meaningful requests out of it.

When you state "we have two choices", you imply that it is my choice as
well. It is not. The answer that I am looking for is yes, it does not
function as we would like, we are working on it and in the mean time we
will ensure that toolkit is available on Labs for the more complex queries.

Wikidata is a service and the service is in need of being better.
Thanks,
  GerardM

On 11 February 2016 at 12:32, Daniel Kinzler 
wrote:

> Am 11.02.2016 um 10:17 schrieb Gerard Meijssen:
> > Your response is technical and seriously, query is a tool and it should
> function
> > for people. When the tool is not good enough fix it.
>
> What I hear: "A hammer is a tool, it should work for people. Tearing down a
> building with it takes forever, so fix the hammer!"
>
> The query service was never intended to run arbitrarily large or complex
> queries. Sure, would be nice, but that also means committing an arbitrary
> amount
> of resources to a single request. We don't have arbitrary amounts of
> resources.
>
> We basically have two choices: either we offer a limited interface that
> only
> allows for a narrow range of queries to be run at all. Or we offer a very
> general interface that can run arbitrary queries, but we impose limits on
> time
> and memory consumption. I would actually prefer the first option, because
> it's
> more predictable, and doesn't get people's hopes up too far. What do you
> think?
>
> Oh, and +1 for making it easy to use WDT on labs.
>
> --
> Daniel Kinzler
> Senior Software Developer
>
> Wikimedia Deutschland
> Gesellschaft zur Förderung Freien Wissens e.V.
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] SPARQL CONSTRUCT results truncated

Hi Joachim,

Here is a short program that solves your problem:

https://github.com/Wikidata/Wikidata-Toolkit-Examples/blob/master/src/examples/DataExtractionProcessor.java

It is in Java, so, you need that (and Maven) to run it, but that's the
only technical challenge ;-). You can run the program in various ways as
described in the README:

https://github.com/Wikidata/Wikidata-Toolkit-Examples

The program I wrote puts everything into a CSV file, but you can of
course also write RDF triples if you prefer this, or any other format
you wish. The code should be easy to modify.

On a first run, the tool will download the current Wikidata dump, which
takes a while (it's about 6G), but after this you can find and serialise
all results in less than half an hour (for a processing rate of around
10K items/second). A regular laptop is enough to run it.

Cheers,

Markus

On 11.02.2016 01:34, Stas Malyshev wrote:

Hi!

I try to extract all mappings from wikidata to the GND authority file,
along with the according wikipedia pages, expecting roughly 500,000 to
1m triples as result.

As a starting note, I don't think extracting 1M triples may be the best
way to use query service. If you need to do processing that returns such
big result sets - in millions - maybe processing the dump - e.g. with
wikidata toolkit at https://github.com/Wikidata/Wikidata-Toolkit - would
be better idea?

However, with various calls, I get much less triples (about 2,000 to
10,000). The output seems to be truncated in the middle of a statement, e.g.

It may be some kind of timeout because of the quantity of the data being
sent. How long does such request take?

___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] SPARQL CONSTRUCT results truncated

On 11.02.2016 15:01, Gerard Meijssen wrote:

Hoi,
What I hear is that the intentions were wrong in that you did not
anticipate people to get actual meaningful requests out of it.

When you state "we have two choices", you imply that it is my choice as
well. It is not. The answer that I am looking for is yes, it does not
function as we would like, we are working on it and in the mean time we
will ensure that toolkit is available on Labs for the more complex queries.

Wikidata is a service and the service is in need of being better.

Gerard, do you realise how far away from technical reality your wishes 
are? We are far ahead of the state of the art in what we already have 
for Wikidata: two powerful live query services + a free toolkit for 
batch analyses + several Web APIs for live lookups. I know of no site of 
this scale that is anywhere near this in terms of functionality. You can 
always ask for more, but you should be a bit reasonable too, or people 
will just ignore you.

Markus

On 11 February 2016 at 12:32, Daniel Kinzler
> wrote:

Am 11.02.2016 um 10:17 schrieb Gerard Meijssen:
> Your response is technical and seriously, query is a tool and it should 
function
> for people. When the tool is not good enough fix it.

What I hear: "A hammer is a tool, it should work for people. Tearing
down a
building with it takes forever, so fix the hammer!"

The query service was never intended to run arbitrarily large or complex
queries. Sure, would be nice, but that also means committing an
arbitrary amount
of resources to a single request. We don't have arbitrary amounts of
resources.

We basically have two choices: either we offer a limited interface
that only
allows for a narrow range of queries to be run at all. Or we offer a
very
general interface that can run arbitrary queries, but we impose
limits on time
and memory consumption. I would actually prefer the first option,
because it's
more predictable, and doesn't get people's hopes up too far. What do
you think?

Oh, and +1 for making it easy to use WDT on labs.

--
Daniel Kinzler
Senior Software Developer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

___
Wikidata mailing list
Wikidata@lists.wikimedia.org 
https://lists.wikimedia.org/mailman/listinfo/wikidata

___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

[Wikidata-bugs] [Maniphest] [Commented On] T125503: [Story] Reduce initialization time of Statementview

adrianheine added a comment.

I'd consider this done when the last linked change is merged. It reduces 
loading time of big items by around 50% for me.


TASK DETAIL
  https://phabricator.wikimedia.org/T125503

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: adrianheine
Cc: gerritbot, Agabi10, thiemowmde, adrianheine, Jonas, Aklapper, Izno, 
Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T126512: flaky qunit test wikibase.getLanguageNameByCode wikibase.getLanguageNameByCode()

JanZerebecki moved this task to Done on the Wikidata-Sprint-2016-02-02 
workboard.

TASK DETAIL
  https://phabricator.wikimedia.org/T126512

WORKBOARD
  https://phabricator.wikimedia.org/project/board/1722/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: adrianheine, JanZerebecki
Cc: gerritbot, daniel, Jonas, adrianheine, aude, Aklapper, hoo, JanZerebecki, 
StudiesWorld, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Reassigned] T126512: flaky qunit test wikibase.getLanguageNameByCode wikibase.getLanguageNameByCode()

JanZerebecki reassigned this task from JanZerebecki to adrianheine.

TASK DETAIL
  https://phabricator.wikimedia.org/T126512

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: adrianheine, JanZerebecki
Cc: gerritbot, daniel, Jonas, adrianheine, aude, Aklapper, hoo, JanZerebecki, 
StudiesWorld, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Closed] T126512: flaky qunit test wikibase.getLanguageNameByCode wikibase.getLanguageNameByCode()

JanZerebecki closed this task as "Resolved".
JanZerebecki claimed this task.
JanZerebecki added a comment.

It seems Adrians patch fixed it.


TASK DETAIL
  https://phabricator.wikimedia.org/T126512

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: JanZerebecki
Cc: gerritbot, daniel, Jonas, adrianheine, aude, Aklapper, hoo, JanZerebecki, 
StudiesWorld, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T125503: [Story] Reduce initialization time of Statementview

adrianheine moved this task to Review on the Wikidata-Sprint-2016-02-02 
workboard.

TASK DETAIL
  https://phabricator.wikimedia.org/T125503

WORKBOARD
  https://phabricator.wikimedia.org/project/board/1722/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: adrianheine
Cc: gerritbot, Agabi10, thiemowmde, adrianheine, Jonas, Aklapper, Izno, 
Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T126512: flaky qunit test wikibase.getLanguageNameByCode wikibase.getLanguageNameByCode()

gerritbot added a comment.

Change 269954 merged by jenkins-bot:
Select first heading by class, not by id

https://gerrit.wikimedia.org/r/269954


TASK DETAIL
  https://phabricator.wikimedia.org/T126512

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, daniel, Jonas, adrianheine, aude, Aklapper, hoo, JanZerebecki, 
StudiesWorld, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T125503: [Story] Reduce initialization time of Statementview

gerritbot added a comment.

Change 269962 had a related patch set uploaded (by Adrian Heine):
Defer sub-widget initialization in statementview

https://gerrit.wikimedia.org/r/269962


TASK DETAIL
  https://phabricator.wikimedia.org/T125503

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: gerritbot, Agabi10, thiemowmde, adrianheine, Jonas, Aklapper, Izno, 
Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T118860: [RFC] Use Role Object Pattern to represent derived data in the data model

Tobi_WMDE_SW added a project: Wikidata-Sprint-2016-02-16.

TASK DETAIL
  https://phabricator.wikimedia.org/T118860

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel, Tobi_WMDE_SW
Cc: Tobi_WMDE_SW, Bene, Lydia_Pintscher, mkroetzsch, adrianheine, hoo, 
thiemowmde, aude, Jonas, JanZerebecki, JeroenDeDauw, Aklapper, StudiesWorld, 
daniel, Izno, Luke081515, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Edited] T125503: [Story] Reduce initialization time of Statementview

adrianheine edited the task description.

TASK DETAIL
  https://phabricator.wikimedia.org/T125503

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: adrianheine
Cc: gerritbot, Agabi10, thiemowmde, adrianheine, Jonas, Aklapper, Izno, 
Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Created] T126609: [Task] Display performance statistic notification

2016-02-11 Thread Jonas

Jonas created this task.
Jonas claimed this task.
Jonas added subscribers: adrianheine, thiemowmde, Addshore.
Jonas added projects: Wikidata, Wikidata-Sprint-2016-02-02, Performance.
Herald added a subscriber: Aklapper.

TASK DESCRIPTION


TASK DETAIL
  https://phabricator.wikimedia.org/T126609

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Jonas
Cc: Aklapper, Addshore, thiemowmde, adrianheine, Izno, Wikidata-bugs, aude, 
GWicke, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T126609: [Task] Display performance statistic notification

2016-02-11 Thread Jonas

Jonas moved this task to Review on the Wikidata-Sprint-2016-02-02 workboard.

TASK DETAIL
  https://phabricator.wikimedia.org/T126609

WORKBOARD
  https://phabricator.wikimedia.org/project/board/1722/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Jonas
Cc: Aklapper, Addshore, thiemowmde, adrianheine, Izno, Wikidata-bugs, aude, 
GWicke, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Claimed] T126355: Extensions should be able to provide a custom URI for wikibase data-types they define

2016-02-11 Thread daniel

daniel claimed this task.

TASK DETAIL
  https://phabricator.wikimedia.org/T126355

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: Smalyshev, Aklapper, Physikerwelt, StudiesWorld, daniel, Izno, 
Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T126596: During update.php (and install), add an entry in the sites table / SiteStore for the local wiki

aude added a project: Wikidata-Sprint-2016-02-16.

TASK DETAIL
  https://phabricator.wikimedia.org/T126596

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude
Cc: JanZerebecki, Aklapper, aude, StudiesWorld, Izno, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T126355: Extensions should be able to provide a custom URI for wikibase data-types they define

2016-02-11 Thread daniel

daniel moved this task to Doing on the Wikidata-Sprint-2016-02-02 workboard.

TASK DETAIL
  https://phabricator.wikimedia.org/T126355

WORKBOARD
  https://phabricator.wikimedia.org/project/board/1722/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: Smalyshev, Aklapper, Physikerwelt, StudiesWorld, daniel, Izno, 
Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T126597: [Task] Move WikibaseDataModel to Gerrit

2016-02-11 Thread mmodell

mmodell added a comment.

Have you considered moving to Phabricator + Differential instead of gerrit?


TASK DETAIL
  https://phabricator.wikimedia.org/T126597

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: mmodell
Cc: Jonas, hoo, Dereckson, Lydia_Pintscher, MZMcBride, aude, JanZerebecki, 
JeroenDeDauw, Legoktm, GPHemsley, Tobi_WMDE_SW, adrianheine, daniel, 
thiemowmde, Aklapper, mmodell, chasemp, Ricordisamoa, Liuxinyu970226, Addshore, 
Bene, Lazowik, Tpt, Krenair, Izno, Luke081515, Wikidata-bugs, Mbch331, QChris, 
greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Re: [Wikidata] SPARQL CONSTRUCT results truncated


Hi Joachim,

Stas would be the right person to discuss service parameters and the 
possible setup of more servers with other parameters. He is part of the 
team at WMF who is in charge of the SPARQL ops.


You note that "it isn’t always obvious what is right and what the 
limitations of a tool are". I think this is the key point here. There is 
not enough experience with the SPARQL service yet to define very clear 
guidelines on what works and what doesn't. On this mailing list, we have 
frequently been reminded to use LIMIT in queries to make sure they 
terminate and don't overstress the server, but I guess this is not part 
of the official documentation you refer to. There was no decision 
against supporting bigger queries either -- it just did not come up as a 
major demand yet, since typical applications that use SPARQL so far 
require 10s to 1000s of results but not 100,000s to millions. To be 
honest, I would not have expected this to work so well in practice that 
it could be considered here. It is interesting to learn that you are 
already using SPARQL for generating custom data exports. It's probably 
not the most typical use of a query service, but at least the query 
language could support this usage in principle.


Cheers,

Markus



On 11.02.2016 19:32, Neubert, Joachim wrote:

Hi Lydia,

I agree on using the right tool for the job. Yet, it isn’t always
obvious what is right and what the limitations of a tool are.

For me, it’s perfectly ok when a query runs for 20 minutes, when it
spares me some hours of setting up a specific environment for one
specific dataset (and doing it again when I need current data two month
later). And it would be no issue if the query runs much longer, in
situations where it competes with several others. But of course, that’s
not what I want to experience when I use a wikidata service to drive,
e.g., an autosuggest function for selecting entities.

So, can you agree to Markus suggestion that an experimental “unstable”
endpoint could solve different use cases and expectiations?

And do you think the policies and limitations of different access
strategies could be documented? These could include a high-reliability
interface for a narrow range of queries (as Daniel suggests as his
preferred option). And on the other end of the spectrum something what
allows people to experiment freely. Finally, the latter kind of
interface could allow new patterns of usage to evolve, with perhaps a
few of them worthwhile to become part of an optimized, highly reliabile
query set.

I could imagine that such a documentation of (and perhaps discussion on)
different options and access strategies, limitations and tradeoffs could
solve Gerards claim to give people what they need, or at least let them
make informed choises when restrictions are unavoidable.

Cheers, Joachim

*Von:*Wikidata [mailto:wikidata-boun...@lists.wikimedia.org] *Im Auftrag
von *Lydia Pintscher
*Gesendet:* Donnerstag, 11. Februar 2016 17:55
*An:* Discussion list for the Wikidata project.
*Betreff:* Re: [Wikidata] SPARQL CONSTRUCT results truncated

On Thu, Feb 11, 2016 at 5:53 PM Gerard Meijssen
> wrote:

Hoi,'

Markus when you read my reply on the original question you will see
that my approach is different. The first thing that I pointed out
was that a technical assumption has little to do with what people
need. I indicated that when this is the approach, the answer is fix
it. The notion that a large number of returns is outrageous is not
of this time.

My approach was one where I even offered a possible solution, a crutch.

The approach Daniel took was to make me look ridiculous. His choice,
not mine. I stayed polite and told him that his answers are not my
answers and why. The point that I make is that Wikidata is a
service. It will increasingly be used for the most outrageous
queries and people will expect it to work because why else do we put
all this data in there. Why else is this the data hub for Wikipedia.
Why else

Do appreciate that the aim of the WMF is to share in the sum of all
available knowledge. When the current technology is what we have to
make do with, fine for now. Say so, but do not ridicule me for
saying that it is not good enough, it is not now and it will
certainly not be in the future...

Thanks,

GerardM

Gerard, it all boils down to using the right tool for the job. Nothing
more - nothing less. Let's get back to making Wikidata rock.

Cheers
Lydia

--

Lydia Pintscher - http://about.me/lydia.pintscher

Product Manager for Wikidata

Wikimedia Deutschland e.V.

Tempelhofer Ufer 23-24

10963 Berlin

www.wikimedia.de 

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.

Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 Nz. Als gemeinnützig anerkannt

[Wikidata-bugs] [Maniphest] [Commented On] T126597: [Task] Move WikibaseDataModel to Gerrit

Lydia_Pintscher added a comment.

Do we want to have yet another place we need to tell people to get our code 
from and submit patches to?  Github and gerrit is already a challenge for 
people apparently. If you think the benefits outweight the drawbacks I will not 
object but please keep this in mind.


TASK DETAIL
  https://phabricator.wikimedia.org/T126597

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Lydia_Pintscher
Cc: Jonas, hoo, Dereckson, Lydia_Pintscher, MZMcBride, aude, JanZerebecki, 
JeroenDeDauw, Legoktm, GPHemsley, Tobi_WMDE_SW, adrianheine, daniel, 
thiemowmde, Aklapper, mmodell, chasemp, Ricordisamoa, Liuxinyu970226, Addshore, 
Bene, Lazowik, Tpt, Krenair, Izno, Luke081515, Wikidata-bugs, Mbch331, QChris, 
greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T126671: Quantity values are recorded as 0 because of Munger bug

gerritbot added a project: Patch-For-Review.

TASK DETAIL
  https://phabricator.wikimedia.org/T126671

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Smalyshev, gerritbot
Cc: gerritbot, Aklapper, Smalyshev, debt, Gehel, Izno, jkroll, Wikidata-bugs, 
Jdouglas, aude, Deskana, Manybubbles, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T126671: Quantity values are recorded as 0 because of Munger bug

gerritbot added a subscriber: gerritbot.
gerritbot added a comment.

Change 270149 had a related patch set uploaded (by Smalyshev):
Fix number parsing

https://gerrit.wikimedia.org/r/270149


TASK DETAIL
  https://phabricator.wikimedia.org/T126671

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Smalyshev, gerritbot
Cc: gerritbot, Aklapper, Smalyshev, debt, Gehel, Izno, jkroll, Wikidata-bugs, 
Jdouglas, aude, Deskana, Manybubbles, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Unblock] T18976: Wikis waiting for creation (tracking)

2016-02-11 Thread Krenair

Krenair closed blocking task T125501: Create Adyghe Wikipedia as "Resolved".

TASK DETAIL
  https://phabricator.wikimedia.org/T18976

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Krenair
Cc: JEumerus, greg, Krenair, Aklapper, Meno25, Matanya, Arseny1992, aude, 
brion, Amire80, Ebe123, SPQRobin, mxn, TTO, Az1568, Pathoschild, Merl, Petrb, 
Steinsplitter, revi, Glaisher, Rschen7754, Peachey88, Kanjy, Snowolf, 
Hkjacksonhk, Liuxinyu970226, jeremyb, MF-Warburg, Stryn, zhuyifei1999, Dcljr, 
Dereckson, JohnLewis, Izno, Luke081515, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T67397: [Story] add a new datatype for formulae

gerritbot added a comment.

Change 269386 merged by jenkins-bot:
Add Math property type to ontology.owl

https://gerrit.wikimedia.org/r/269386


TASK DETAIL
  https://phabricator.wikimedia.org/T67397

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Physikerwelt, gerritbot
Cc: ArthurPSmith, TomT0m, Llyrian, WickieTheViking, Aklapper, MGChecker, Micru, 
Sannita, Ricordisamoa, Rits, Liuxinyu970226, Tpt, Physikerwelt, Wikidata-bugs, 
Bene, Tobias1984, Lydia_Pintscher, daniel, Izno, mobrovac, Prod, aude, fredw, 
Pkra, scfc, Mbch331, Ltrlg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Re: [Wikidata] SPARQL CONSTRUCT results truncated

2016-02-11 Thread Stas Malyshev

Hi!

> 5.44s empty result
> 8.60s 2090 triples
> 5.44s empty result
> 22.70s 27352 triples

That looks weirdly random. I'll check out what is going on there.

-- 
Stas Malyshev
smalys...@wikimedia.org

___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

[Wikidata-bugs] [Maniphest] [Changed Project Column] T126122: Blazegraph Query optimizer pessimises query Deprecated_statements

EBernhardson moved this task to WDQS on the Discovery workboard.

TASK DETAIL
  https://phabricator.wikimedia.org/T126122

WORKBOARD
  https://phabricator.wikimedia.org/project/board/1174/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: EBernhardson
Cc: Aklapper, JanZerebecki, StudiesWorld, debt, Gehel, Izno, jkroll, Smalyshev, 
Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T126121: Blazegraph Query optimizer pessimises query Aliases_of_properties_which_are_used_more_than_once

EBernhardson moved this task to WDQS on the Discovery workboard.

TASK DETAIL
  https://phabricator.wikimedia.org/T126121

WORKBOARD
  https://phabricator.wikimedia.org/project/board/1174/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: EBernhardson
Cc: Aklapper, JanZerebecki, StudiesWorld, debt, Gehel, Izno, jkroll, Smalyshev, 
Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Edited] T102476: RFC: Requirements for change propagation

2016-02-11 Thread GWicke

GWicke edited the task description.

TASK DETAIL
  https://phabricator.wikimedia.org/T102476

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: GWicke
Cc: ArielGlenn, hoo, Addshore, RobLa-WMF, StudiesWorld, intracer, Qgil, 
JanZerebecki, brion, Ltrlg, Anomie, Milimetric, mark, BBlack, aaron, daniel, 
Eevans, mobrovac, GWicke, Izno, Hardikj, Wikidata-bugs, aude, jayvdb, Mbch331, 
Jay8g, bd808, Legoktm



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T126597: [Task] Move WikibaseDataModel to Gerrit

JanZerebecki added a comment.

How would that fulfill our CI needs?


TASK DETAIL
  https://phabricator.wikimedia.org/T126597

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: JanZerebecki
Cc: Jonas, hoo, Dereckson, Lydia_Pintscher, MZMcBride, aude, JanZerebecki, 
JeroenDeDauw, Legoktm, GPHemsley, Tobi_WMDE_SW, adrianheine, daniel, 
thiemowmde, Aklapper, mmodell, chasemp, Ricordisamoa, Liuxinyu970226, Addshore, 
Bene, Lazowik, Tpt, Krenair, Izno, Luke081515, Wikidata-bugs, Mbch331, QChris, 
greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T125900: NotMaterializedException on Blazegraph 2.0

EBernhardson moved this task to WDQS on the Discovery workboard.

TASK DETAIL
  https://phabricator.wikimedia.org/T125900

WORKBOARD
  https://phabricator.wikimedia.org/project/board/1174/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Smalyshev, EBernhardson
Cc: Aklapper, Smalyshev, debt, Gehel, Izno, jkroll, Wikidata-bugs, Jdouglas, 
aude, Deskana, Manybubbles, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T124196: Notice: Unable to unserialize job_params in some CirrusSearch jobs (when using JobQueueDB)

EBernhardson moved this task to Search on the Discovery workboard.

TASK DETAIL
  https://phabricator.wikimedia.org/T124196

WORKBOARD
  https://phabricator.wikimedia.org/project/board/1174/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: EBernhardson
Cc: hoo, aude, Aklapper, debt, Gehel, Izno, Wikidata-bugs, Deskana, jayvdb, 
Mbch331, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T102476: RFC: Requirements for change propagation

2016-02-11 Thread GWicke

GWicke removed a project: Wikimedia-Developer-Summit-2016.

TASK DETAIL
  https://phabricator.wikimedia.org/T102476

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: GWicke
Cc: ArielGlenn, hoo, Addshore, RobLa-WMF, StudiesWorld, intracer, Qgil, 
JanZerebecki, brion, Ltrlg, Anomie, Milimetric, mark, BBlack, aaron, daniel, 
Eevans, mobrovac, GWicke, Izno, Hardikj, Wikidata-bugs, aude, jayvdb, Mbch331, 
Jay8g, bd808, Legoktm



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T126597: [Task] Move WikibaseDataModel to Gerrit

2016-02-11 Thread Bene

Bene added a comment.

In https://phabricator.wikimedia.org/T126597#2020048, @mmodell wrote:

> Have you considered moving to Phabricator + Differential instead of gerrit?


I'd really appreciate that. Having code and tickets at one place will help us a 
lot imo.

Is there already code hosted here on phabricator, or would that be a jump into 
the deep end?


TASK DETAIL
  https://phabricator.wikimedia.org/T126597

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Bene
Cc: Jonas, hoo, Dereckson, Lydia_Pintscher, MZMcBride, aude, JanZerebecki, 
JeroenDeDauw, Legoktm, GPHemsley, Tobi_WMDE_SW, adrianheine, daniel, 
thiemowmde, Aklapper, mmodell, chasemp, Ricordisamoa, Liuxinyu970226, Addshore, 
Bene, Lazowik, Tpt, Krenair, Izno, Luke081515, Wikidata-bugs, Mbch331, QChris, 
greg



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T126441: Support PHP 5.5 in CI for Wikidata stuff