Hi all -
We've been using a locally installed wikidata stand-alone service
(https://www.mediawiki.org/wiki/Wikidata_query_service/User_Manual#Standalon…)
for several months now. Recently the service went down for a significant
amount of time, and when we ran runUpdate.sh -n wdq, instead of catching
up to real time as it usually does, the update process lagged, failing
even to keep parity with real time.
Example output from the log:
09:30:39.805 [main] INFO org.wikidata.query.rdf.tool.Update - Polled up
to 2016-10-24T23:01:05Z at (0.0, 0.0, 0.0) updates per second and
(271.8, 56.2, 18.8) milliseconds per second
This is normal when starting the update of course, but the system never
seems to find its feet, and continues to stumble and lag. Restarting
both the blazegraph process and the update process has no lasting effect.
From time to time, a message like this will appear:
INFO org.wikidata.query.rdf.tool.RdfRepository - HTTP request failed:
org.apache.http.NoHttpResponseException: wikidata.cb.ntent.com:9999
failed to respond, retrying in 2175 ms.
I have experienced this effect in the past, and had success replacing an
old journal which was the product of a long update process with a new
journal rebuilt from the latest dump. This strategy did not work. I
tried rebuilding with the latest git pull from origin and rebuilding the
journal, again with no effect.
This problem started about 3 days ago, and we're now polling up to a
point in time 18 hours earlier than real time.
I would appreciate any guidance.
Also: is this an appropriate list to write to with such problems? Are
there more appropriate places?
Thanks,
Eric Scott
Hi all -
We've been using a locally installed wikidata stand-alone service
(https://www.mediawiki.org/wiki/Wikidata_query_service/User_Manual#Standalon…)
for several months now. We're becoming increasingly plagued by
performance issues, and are wondering if one approach to the problem
might be to adopt the Blazegraph multi-GPU architecture
(https://www.blazegraph.com/product/gpu-accelerated/).
Could anyone provide guidance as to how much pain would be involved in
making such a transition?
Thanks,
Eric Scott
Hey folks,
we plan to drop the "wb-status" page prop as it's unused as far as we
can tell and of questionable value, see
https://phabricator.wikimedia.org/T146792
<https://phabricator.wikimedia.org/T146792>. This will affect you if you
use the action=query API to retrieve page props from entity pages or if
you use the page_props table (on tool labs for example), to retrieve
this page property.
Please let us know if and how you use this page prop, so that we can
find a solution for your use cases.
In case there are no issues with removing this, we will drop it in
December 2016 (or later).
Cheers,
Marius
Hello!
The Wikimedia Developer Summit
<https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit> is the annual
meeting to push the evolution of MediaWiki and other technologies
supporting the Wikimedia movement. The next edition will be held in San
Francisco on January 9-11, 2017.
We welcome all Wikimedia technical contributors, third party developers,
and users of MediaWiki and the Wikimedia APIs. We specifically want to
increase the participation of volunteer developers and other contributors
dealing with extensions, apps, tools, bots, gadgets, and templates.
Important deadlines:
- Monday, October 24: This is the last day to request travel
sponsorship. Applying takes less than five minutes.
- Monday, October 31: This is the last day to propose an activity. Bring
the topics you care about!
Subscribe to weekly updates: https://www.mediawiki
.org/wiki/Topic:Td5wfd70vptn8eu4
Please feel free to forward this email to anyone who might be interested in
attending!
Thanks,
Srishti
--
Srishti Sethi
ssethi(a)wikimedia.org
Hey folks,
we will soon change how Wikibase outputs data as Wikitext per default.
This might affect users of the "action=wbformatvalue" API that either
use "generate=text/x-wiki" or omit the "generate" parameter (Wikitext
output is the default for that API module). I briefly looked through our
API logs in order to see how many users will be affected by this and
found that no one uses this feature[0].
Please note that for our internal functionality (like the property
parser function, or the Lua functionality), we made sure that the output
wont change.
Only the output obtained via the wbformatvalue-API module might change!
Cheers,
Marius
[0]: https://phabricator.wikimedia.org/T147591
Hello All
Property filter does not seem to be working for me.
My code:
WikibaseDataFetcher wbdf = WikibaseDataFetcher.getWikidataDataFetcher();
wbdf.getFilter().setPropertyFilter(Collections.singleton(this.dataObjectFactory.getPropertyIdValue("P57",
"http://www.wikidata.org/entity")));
wbdf.getFilter().setPropertyFilter(Collections.singleton(PropertyIdValueImpl.create("P57",
"http://www.wikidata.org/entity")));
i am still receiving all statements. what am i missing ?
Thanks in advance
Assaf
Hi,
I have a question regarding the tags [1] added to the edit history of
Wikidata.
When I look at the contributions of a user at the wiki [2], I see the
comment of the edit (e.g. " (Created claim: country (P17): Denmark (Q35),
#petscan)") and a special tag that indicates that WiDaR-based software was
used to edit (e.g. (Tag: Widar [1.4]), reCh).
However, when I look up the contributions of the same user that I have
checked in the Wiki, this time via the API [3], I don't see the "Widar" tag
in the comment.
Is there a way to identify these special tags (programmatically) in the
edit history?
Cristina
[1] https://www.wikidata.org/wiki/Special:Tags
[2]
https://www.wikidata.org/w/index.php?limit=50&title=Special%3AContributions…
[3]
https://www.wikidata.org/w/api.php?action=query&list=usercontribs&ucuser=us…
--
Cristina Sarasua
Institute for Web Science and Technologies (WeST)
Universität Koblenz-Landau
Universitätsstraße 1
56070 Koblenz
Germany
e-mail: csarasua(a)uni-koblenz.de
phone: +49 261 287 2772
fax: +49 261 287 100 2772
web site: http://west.uni-koblenz.de