Hi All!
I'm trying to figure out possible ways to launch Mediawiki-Wikibase
software to allow collaborative creation of wiki pages and
corresponding knowledge graph.
As well as I understand, it is possible to configure a single installation
of Mediawiki with Wikibase extension, and have all wiki pages in the Main
namespace like https://example.org/wiki/ and all graph items in the
namespace https://example.org/wiki/Item:
I want to build something more similar to Wikipedia-Wikidata -- wiki pages
in the namespace https://wiki.example.org/wiki/ and wikibase graph in the
namespace https://graph.example.org/wiki/ . Am I right that I have to
launch two instances of MediaWiki for that, one without Wikibase extension
and one with it?
Or is there a simpler way to configure the system to get such namespace
structure?
Thank you for help!
Victor Agroskin
Hi!
I have a problem with a SPARQL query. Hopefully you can help me.
I'd like to get wikidata articles which use a specific image in the P18
property. I'm using this simple query:
SELECT ?item WHERE { ?item wdt:P18 "item.jpg". }
This works for some items, but not all.
Example 1:
SELECT ?item
WHERE { ?item wdt:P18 "1936-ChirkovAntonNikolaevich.jpg". }
-> returns "wd:Q16718402" (https://www.wikidata.org/wiki/Q16718402)
Example 2:
SELECT ?item
WHERE { ?item wdt:P18 "GuentherZ 2010-02-27 0207 Wien10 Scheunenstrasse2 Bildstock.jpg". }
-> returns nothing, although it is used by https://www.wikidata.org/wiki/Q33231166
This might be related to the following fact:
Example 1A:
SELECT ?item ?image
WHERE {
?item wdt:P18 ?image.
?item wdt:P214 "307433452".
}
-> the field "image" shows a string "1936-ChirkovAntonNikolaevich.jpg"
Example 2A:
SELECT ?item ?foo
WHERE {
?item wdt:P18 ?image.
?item wdt:P2951 "86578".
}
-> the field "image" shows a link to
https://commons.wikimedia.org/wiki/File:GuentherZ%202010-02-27%200207%20Wie…
with the text "commons:GuentherZ 2010-02-27 0207 Wien10 Scheunenstrasse2 Bildstock.jpg"
(I also tried prefixing the query image name by 'commons:', like "?item
wdt:P18 "commons:image.jpg")
Please tell me if you have an idea how to solve this problem!
greetings,
Stephan
--
Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich
,----------------------------------------------------------------------.
| Stephan Bösch-Plepelits ❤ code ❤ urbanism ❤ free software ❤ cycling |
| Projects: |
| > OpenStreetMap: openstreetbrowser.org > openstreetmap.at |
| > Urbanism: Radlobby Wien > Platz für Wien |
| Contact: |
| > Mail: skunk(a)xover.mud.at > Blog: plepe.at > Code: github.com/plepe |
| > Twitter: twitter.com/plepe > Jabber: skunk(a)jabber.at |
| > Mastodon: @plepe@en.osm.town |
`----------------------------------------------------------------------'
Hi everyone!
This is an announcement for a change to the example configuration of the
WikibaseClient extension, which only affects Client wikis which are not
also Repository wikis. If you don’t operate a non-Repo Client wiki, or if
you don’t use the example settings, you can ignore this message.
(Wikibase-Docker users, in particular, can ignore it.) The change will
become effective on the master branch soon, and then in the future 1.36
release (but not yet in the upcoming 1.35 release).
Currently, the WikibaseClient example settings (client/ExampleSettings.php
or client/config/WikibaseClient.example.php) define an example Repo for the
Client if the WikibaseRepository extension is not also being loaded. As we
are moving towards using extension registration for Wikibase (T88258
<https://phabricator.wikimedia.org/T88258>), this will no longer be
possible (extensions loaded using wfLoadExtension() are processed later, so
the example settings file can’t detect if WikibaseRepo is loaded or not).
Therefore, we will be removing this code from the Client example settings,
and if your wiki is not also a Repo wiki, you will have to configure the
Repo manually. (For wikis that are both Repo and Client, the default Client
settings are sufficient, and nothing needs to be done.) This means that if
your configuration (LocalSettings.php) currently contains a line like
require_once "$IP/extensions/Wikibase/client/ExampleSettings.php";
or
require_once
"$IP/extensions/Wikibase/client/config/WikibaseClient.example.php";
but not a line like
require_once "$IP/extensions/Wikibase/repo/Wikibase.php";
then you should copy the example settings
<https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/7613b87c619…>
into your configuration and adjust them as needed (at least the repoUrl,
http://repo.example.org, is certainly wrong). If you already configure some
of these client settings, then you can skip copying the corresponding
example settings lines.
We will be making this change on the Wikibase master branch very soon, so
if you use the latest MediaWiki and Wikibase from Git, then you will
probably have to update your configuration ahead of the next update too.
However, the change will not be in the upcoming MediaWiki 1.35 release (or
the REL1_35 Wikibase branch), so if you are sticking to release versions,
you don’t need to change anything yet. That said, you could still update
your configuration in preparation for this future change – the only
potential problem with copying this block is the repeated define(), which
may raise a PHP Notice, so you might want to wrap those two lines
<https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/7613b87c619…>
in an if ( !defined( 'WB_REPO_NS_ITEM' ) ) block when copying them (unless
you stop loading the example settings altogether, which is also an option).
I also want to stress that, while the eventual goal of this work is to load
WikibaseRepo and WikibaseClient using extension registration (i. e., JSON
files, not PHP entry points), we do not yet recommend that third-party
installs do this. When Wikibase is fully ready for extension registration,
we will send another announcement, and the PHP entry points will probably
still be kept for compatibility for a good while longer even after they’re
no longer required.
If you have any issue or question, feel free to leave a comment at T257449
<https://phabricator.wikimedia.org/T257449>. For more information, see also
T256238 <https://phabricator.wikimedia.org/T256238>.
Cheers,
Lucas
--
Lucas Werkmeister (he/er)
Full Stack Developer
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30 219 158 26-0
https://wikimedia.de
Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
https://spenden.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
This is an announcement for a breaking change to the pageterms submodule of
the query API module, which only affects Wikibase repository wikis. If you
do not use that API module, or only use it on client wikis (e. g.
Wikipedias) and not on repository wikis (Wikidata, Wikimedia Commons), you
can ignore this message.
For years, the pageterms
<https://www.wikidata.org/wiki/Special:ApiHelp/query%2Bpageterms> API
module has served a double role: on client wikis, it returned the “terms”
(Label, Description, Aliases) of the Wikidata Item linked to the given
page(s), whereas on repo wikis, it would return the terms of the Item (or
other Entity) on that page itself. For example, querying for the Label of
Wikipedia:Village pump on English Wikipedia
<https://en.wikipedia.org/w/api.php?action=query&prop=pageterms&titles=Wikip…>
would return “Project:Village pump” (the Label of Q16503
<https://www.wikidata.org/wiki/Q16503>), but querying for the Label of
Wikidata:Project chat on Wikidata
<https://www.wikidata.org/w/api.php?action=query&prop=pageterms&titles=Wikid…>
would not return anything, even though that page is linked to the same Item
– you would have to query for the Label of Q16503
<https://www.wikidata.org/w/api.php?action=query&prop=pageterms&titles=Q1650…>
instead. This behavior is inconsistent and also mixes repo and client
concerns in a way that makes the Wikibase code harder to maintain.
To resolve this, we introduced a new entityterms
<https://www.wikidata.org/wiki/Special:ApiHelp/query%2Bentityterms> API
module (a submodule of the query module, just like the pageterms module)
which has the same behavior as the pageterms module currently has for Item
(or other Entity) pages, and which is only available on repo wikis. If you
want to get the terms of Q16503, you can now use
action=query&prop=entityterms&titles=Q16503
<https://www.wikidata.org/w/api.php?action=query&prop=entityterms&titles=Q16…>
instead of action=query&prop=pageterms&titles=Q16503
<https://www.wikidata.org/w/api.php?action=query&prop=pageterms&titles=Q16503>.
(You can also use wbgetentities
<https://www.wikidata.org/wiki/Special:ApiHelp/wbgetentities>, which gives
you much more control over the returned data; pageterms/entityterms may be
faster and can also be combined with other submodules of the query module.)
On or shortly after 5 August 2020, we will remove the special repo behavior
of the pageterms module, and it will then behave just like it always has on
client wikis, and return the terms of the Item linked to a page, not the
terms of the Item (or other Entity) on a page. (Because the new API module
is already available on Wikidata, and you can start using it immediately,
we are not making this pageterms behavior change available on Test Wikidata
significantly before that date.)
If you have any issue or question, feel free to leave a comment at T257658
<https://phabricator.wikimedia.org/T257658>. For more information, see also
T115117 <https://phabricator.wikimedia.org/T115117>, T255882
<https://phabricator.wikimedia.org/T255882> and T256255
<https://phabricator.wikimedia.org/T256255>.
Cheers,
Lucas
--
Lucas Werkmeister (he/er)
Full Stack Developer
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30 219 158 26-0
https://wikimedia.de
Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
https://spenden.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
Hi,
I hope this is an appropriate question for this mailing list.
I am a software developer at Reactome and am working on our bot that writes Reactome data to Wikidata.
Our bot currently uses the property https://www.wikidata.org/wiki/Property:P3937 (the Reactome ID property) to identify and update Reactome items.
We are running into the issue that this property is being used by other people and our bot inadvertently ends up changing items that have not been created by the Reactome bot.
Is there any way to uniquely identify the items created by our bot?
Thanks and warm regards,
Yusra Hader
Dear all,
I'm loading the whole wikidata dataset into Blazegraph using a High
Performance Computer. I gave 120 GB RAM and 3 processing cores to the job.
After almost 24 hours of load the "wikidata.jnl" file has only 28 GB as
size. Initially the process was fast, but as the file increased its size
the loading speed has decreased. I realize that only 14 GB of RAM are being
used. I already implemented the recomendations given in
https://github.com/blazegraph/database/wiki/IOOptimization Do you have some
other recommendations to increase the loading speed?
Leandro
