Blockers for WLM+Wikidata

Background: (T131493)

Eventually, we want WLM to be managed via Wikidata and deprecate the Wiki-Loves-Monuments-Database.

The data migration work will be undertaken in part by Wikimedia Sverige (led by @Lokal_Profil) as part of the Connected Open Heritage project.

During the T131435 meeting, the self-proclaimed WLM Tech Committee (or smth like that) discussed this. We agreed that this will *not* be ready for next WLM edition.

Let’s write down the blockers we determined that currently prevent running WLM with Wikidata as a backend.

The conclusion from the meeting of the WLM Tech Committee is that it would be technically possible to migrate over to using Wikidata as a backend already now. The main blocking factor instead lies with the way in which editors are expecting to interact with the information.

It is the belief of the committee that the main consumers of the monument data (the Wikipedias) are expecting to have this information available as lists which they can edit easily. The current solution allows for this and makes very few restrictions on which values can be entered into which field as well as allowing for a mixture of free-text fields and “data” fields.

Current solutions for constructing such lists from Wikidata data either does not allow for any local changes (Autolist) or require the editors to leave Wikipedia (for Wikidata) whenever they wish to edit a value. Hybrid solutions, where Wikidata data is locally overridden solves some of this but effectively means the lists go out of sync with their Wikidata counterparts. A mechanism which simplifies working with these lists, without (knowingly) leaving Wikipedia would be desirable before fully switching over.

It is the nature of Wikidata that a property can either take a string or an entity as a value. By contrast the current lists allow for free mixing of text and wikilinks in any given cell. Getting the current editors used to using one or the other and being comfortable with the possible drastic increase of (smart?) red links will take an initial effort around communication but should not prove to be insurmountable.

The focus for the near future is instead on importing the existing data to Wikidata and ensure that there is a clear connection between each database object and Wikidata (T55319) to ensure a smoother migration when we are ready. If the field-property mappings are clearly documented and the imports are timestamped it should be easy to synchronize any information which has been added in the meantime.

Once the blockers have been eliminated the Monument Database (or at least it’s main component) should be retired and the API can be replaced by a thin client which instead communicates with the Wikidata API or SPARQL endpoint.

/ André Costa (WMSE) (talk) (for the WLM Tech Committee)