I work for Rhizome, a digital arts non-profit.
Nov 1 2021
I would like to understand the reasons why there are two versions of Wikibase RDF, one that is for example returned by requesting it for an item such as https://artbase.rhizome.org/wiki/Special:EntityData/Q2585.ttl and one that is first munged and then handed over into the triple store. Given the architecture of WIkibase, the RDF solely exists to enable SPARQL querying and federation, it is not the actual source of truth or canonical storage format, but a derivative of the JSON blobs stored in MySQL. How would already exporting the desired RDF format increase coupling, rather than removing an unnecessary step?
Sep 14 2021
@Addshore, I'm ready to do it 🚜
⛱ re-sent invite 🏖
Sep 13 2021
formatter URI for RDF resource exists…
Sep 3 2021
Current Docker distribution has Scribuntu included: https://github.com/wmde/wikibase-release-pipeline/tree/main/Docker/build/WikibaseBundle
VisualEditor is now part of the Docker distribution: https://github.com/wmde/wikibase-release-pipeline/tree/main/Docker/build/WikibaseBundle 🎉
I think it would be meaningful to review the role of "magic properties" for independent Wikibase deployments. For instance, using them for asynchronous format validation via bots (like the constraints) is probably useful for the scale Wikidata, on smaller instances you'd rather want to use Shape Expressions in real time during data input. Formatter URLs are fine if your main way of using Wikibase data is browsing the Wikibase editing interface (having clickable links there is nice), but how they are represented in RDF and therefore the query service remains undefined.
I suggest using a text file that is parsed and added to both the blazegraph prefices.conf file, and baked into the query service GUI, format could be basic:
To specify: the process of getting triples exported from Wikibase into Blazegraph is not great, a bunch of shell script wrappers around some Java application, neither being documented very well. It leads to weird side effects, such as requiring to use the /wiki/ path on the Mediawiki that holds the Wikibase T274354. The bigger story is to make the process to sync triples with Blazegraph more robust and controllable, ideally not requiring a separate container.
This commit on GitHub lists patches to the WDQS query GUI to achieve custom name spaces: https://github.com/rhizomedotorg/artbase-query-gui/commit/29ce17b225a3fb9d9bcd16896778f94495fdf9c9
Scribuntu is part of the Wikibase Docker distribution, and is activated via a configuration snippet: https://github.com/wmde/wikibase-release-pipeline/blob/main/Docker/build/WikibaseBundle/LocalSettings.d.template/Scribunto.php
I am unfortunately not savvy enough to provide a stack trace, but have the (amateurish) patch that solves the issue for Rhizome available on GitHub: https://github.com/rhizomedotorg/wikibase-docker/commit/d810a86021490b2a9aa99f476251fd4ac754bcb9 (both @Lucas_Werkmeister_WMDE and @Addshore are invited to the repo)
Jun 3 2021
For dispatchChanges.php to work on a Wikibase install, the following conditions have to be met:
May 27 2021
After adding the LocalSettings changed proposed above ($wgWBClientSettings['repoDatabase'] = false;), changes are getting dispatched, but very irregularly.
May 25 2021
I'm not quite understanding what this is supposed to be fixing. Would changes in Wikibase Items trigger a cache purge of local sitelink'ed pages, without having to set up the whole notification system?
Apr 9 2021
I would rather recommend adding desired prefixes to prefixes.conf. Editing ldf-config.json didn't do anything for me.
Mar 19 2021
It would be cool if the munger's validation behaviour would be configurable, which could maybe remedy some weird behavior overall, see T274354
Mar 11 2021
Since this was resolved: what components were determined to be part of the Docker distribution?
Mar 10 2021
Feb 13 2021
With the Wikibase Docker distribution, dispatchChanges.php doesn't seem to work:
Feb 10 2021
Jan 26 2021
Looking into the detailed log in my setup reveals the following behavior:
Jan 18 2021
Jan 12 2021
Jan 11 2021
Also see T271747
Jan 7 2021
How long will extensions for 1.35 be supported?
Nov 26 2020
Is there any progress on searching and displaying the displaytitle in Cirrus? Over here, we're dealing with page titles that cannot be represented in a regular wiki page title, like Gl=v, 1+1+1+1+1+1+1+1+1+1+1+1, about: Saint Luke Drawing the Virgin, or ]...[world]...[ — just your regular titles for digital artworks. 😉 If users cannot search for those, or on the search results page the titles are different, much confusion can be expected.
Nov 21 2020
I was able to fix the local issue by adding WIKIBASE_SCHEME=https to wdqs-updater environment.
When chaning WIKIBASE_HOST to artbase.rhizome.org, SiteLinks are still rejected, probably because the protocol is assumed to be http instead of https:
Nov 19 2020
Nov 6 2020
Scribunto and SyntaxHighlight_GeSHi are already part of the Mediawiki docker image the Wikibase image is built on. However, they are not loaded via the final LocalSettings.php. Both are helpful extensions that would be nice to have activated by default.
Nov 3 2020
It is not entierly clear why the error happens. A hint might be that the last item that was correctly processed was followed by a gap in the item list. Q7246 is fine, Q7247 for some reason does not exist (it was _not_ deleted, it just never was created), then the row continues with Q7248.
Oct 29 2020
Reformulated more specifically here: T264007
Sep 29 2020
Also see T246952
Sep 28 2020
Sep 17 2020
- I would recommend looking at how nextcloud handles docker configuration: defaults shipped in the docker container and configured by environment variables are handled in the default config.php file. Additionally, any file called *.config.php is loaded and can override these settings. Something similar could easily be adopted as a convention for wikibase and satisfy users that would like to just use the defaults, use augmented defaults, or use just their own settings.
Aug 7 2020
Superceded by T258932
Apr 25 2020
Mar 4 2020
The erroneous bug report T246952 is a good illustration of how the current handling of LocalSettings.php in the container is problematic:
Not true, Scribuntu is included in the Docker image and works.
Feb 19 2020
Feb 18 2020
This etherpad contains notes on WDQS namespaces under "Configure your own name space for query service"
OK now I am specifying conceptUri, and now all data is moving fine into the query service!
Feb 17 2020
The environments are the same for wdqs and wdqs-updater containers, here are the full entries:
environment: - WIKIBASE_SCHEME=https - WIKIBASE_HOST=artbase.rhizome.org - WDQS_HOST=wdqs.svc - WDQS_PORT=9999
Feb 16 2020
Dec 12 2019
I don't see a need for this feature anymore, and would even see this as giving people coming from RDBMS wrong ideas on how to transition to linked data. At least this was the case for myself :)
Nov 13 2019
wikimedia has custom PHP versions, Apache versions, etc. Are these actually desirable for releases / 3rd party users? How about the docker library images?
Nov 9 2019
I'd like to share a few thoughts from the perspective of running a Wikibase since 2015 and having switched to the Docker distribution in 2017, including data migration:
Jan 2 2019
Oct 1 2018
I have done some customization with MediaWiki:Common.css, which is pretty easy. But the logo could be set in the docker-compose file indeed.
Screencap of how this looks:
Sep 19 2018
What hast worked is setting WIKIBASE_HOST in the docker-compose file to the actual public hostname and in the Wikibase's LocalSettings.php adding an explicit concep URI prefix with http protocol, like $wgWBRepoSettings['conceptBaseUri'] = "http://staging.catalog.rhizome.org/";
Sep 18 2018
We have been able to put the ttl-dump into Blazegraph now with the following process:
Sep 14 2018
Thank you @Smalyshev!
Sep 13 2018
When removing the alias staging.catalog.rhizome.org from the wikibase container in the docker-compose file, the connection is made via the docker network and can be established. However, the contents of the Wikibase are still rejected:
I think there is lots of ambiguity here...
Sep 12 2018
I think I need more guidance on how to run this script. I did use the --start and --init switches before.
After some consultation with @Tarrow
Jul 31 2018
Thanks @Smalyshev! Indeed the double dashes were the issue!
Jul 10 2018
I had to correctly configure the reverse proxy for the .htaccess redirect to function. The problem is indeed fixed, feel free to close.
Jul 8 2018
Scribuntu is easy enough to install actually, however it would be nice to be included alongside activated GeSHi and CodeEditor extensions.
Mediawiki-initiated redirects have been solved by setting $wgServer in LocalSettings.php.
The SendGrid extension magically worked without running php composer. Closing since I am not sure what exactly composer does and how it does or doesn't affect other extensions.
Jul 7 2018
After adding wfLoadExtension( 'OAuth' ); and $wgSecretKey = "<randomString>"; to LocalSettings.php, and running update.php, the error changes to Error retrieving token: mwoauth-oauth-exception.
@Addshore I am using Caddy.
Jul 6 2018
I am looking at runUpdate.sh inside the wdqs container, which I believe is documented here.
I was able to solve Mediawiki redirection problems by adding the public host name a mounted LocalSettings.php in $wgServer.
Jul 1 2018
Jun 21 2018
Not currently reproducible
Again, plese excuse the brevity of the original ticket.
Is the WIKIBASE_HOST variable used for both communication with Wikibase and the URI prefix?
I see the scoping problem, on the other hand, it would be overkill to require two containers for a simple Wikibase deployment in which I am guessing the regular Wiki part would also be used.
Entity-URLs are auto-generated as http://localhost:8181/entity/Q1996
Please excuse, my last set of tickets was added during a Wikibase workshop.
During the Berlin workshop it seemed like there was an agreement that every Wikibase should provide a manifest with key information about its properties, see T197588
Jun 19 2018
At Rhizome we used the following command to reset Blazegraph: