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?

@Addshore, I'm ready to do it 🚜

Rhizome commissioned the LocalMedia extension with Professional.Wiki, which provides this features. The extension has also become part of the official Wikibase Docker distribution.

⛱ re-sent invite 🏖

formatter URI for RDF resource exists…

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.

Latest version has it: https://github.com/wmde/wikibase-release-pipeline/blob/816b8084b7068fa1a49bbcf9e57676bd4092e151/Docker/build/Wikibase/LocalSettings.php.template#L28

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)

For dispatchChanges.php to work on a Wikibase install, the following conditions have to be met:

After adding the LocalSettings changed proposed above ($wgWBClientSettings['repoDatabase'] = false;), changes are getting dispatched, but very irregularly.

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?

I would rather recommend adding desired prefixes to prefixes.conf. Editing ldf-config.json didn't do anything for me.

• The URL was indeed https://artbase.rhizome.org/entity/null with a null
• I am unable to reproduce the log at the moment. This only can be done on the production machine (site links do not work on a localhost-based docker deployment, T268231, T264009) and the project deadline is too close right now. 😅

It would be cool if the munger's validation behaviour would be configurable, which could maybe remedy some weird behavior overall, see T274354

Since this was resolved: what components were determined to be part of the Docker distribution?

In T265198#6883296, @Addshore wrote:

This error could do with it's own phabricator ticket.

With the Wikibase Docker distribution, dispatchChanges.php doesn't seem to work:

Looking into the detailed log in my setup reveals the following behavior:

Also see T271747

How long will extensions for 1.35 be supported?

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.

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:

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.

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.

Reformulated more specifically here: T264007

Also see T246952

• 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.

Superceded by T258932

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.

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!

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

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 :)

wikimedia has custom PHP versions, Apache versions, etc. Are these actually desirable for releases / 3rd party users? How about the docker library images?

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:

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:

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/";

We have been able to put the ttl-dump into Blazegraph now with the following process:

Thank you @Smalyshev!

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...

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

Thanks @Smalyshev! Indeed the double dashes were the issue!

I had to correctly configure the reverse proxy for the .htaccess redirect to function. The problem is indeed fixed, feel free to close.

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.

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.

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.

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

At Rhizome we used the following command to reset Blazegraph: