Commons:Wiki Loves Monuments/Documentation/Monuments lists and Wikidata
So you finally have your monuments data on Wikidata, now what…
Introduction[edit]
Migrating your data to Wikidata (or maybe having your data there from the beginning) is great in that it makes it easily queryable, more multilingual and in general allows for many cool things to be done with it. But to make use of it for organising Wiki Loves Monuments efficiently you also need to make sure you surface the data to the participants. Let's face it: saying "you can find it on Wikidata" is not enough.
One of the very first benefits of having your monuments data on Wikidata is that you can create monuments lists more easily using the data on Wikidata. Your traditional way of creating lists of monuments on Wikipedia (or some other Wikimedia project) is not so useful anymore as you want to make sure your data on Wikidata and in these lists stay in sync.
There are several ways you can go about creating monuments lists for different projects. Which one(s) you select will largely depend on a combination of which data you have, where you wish to surface it, and your community's view on using data from Wikidata. The four ways discussed here are:
- Wikidata powered lists (manual)
- Wikidata powered lists (Listeria)
- Wiki Loves Monuments Map (Monumental)
- Monuments Database powered tools
For all except 1. you will need a SPARQL query (or similar) which isolates just your data from Wikidata. If you want to make use of the automated image categorisation and surfacing of new images of previously unphotographed monuments, you will also need to provide instructions for allowing the Monuments Database to harvest your dataset from Wikidata.
Wikidata powered lists (manual)[edit]
This method may be considered if: you previously had lists containing a lot of unstructured data which was not migrated but which you cannot bear to part from; you want to surface the lists on a wiki which allows for Wikidata material to be included in the desired namespace, but which does not allow Listeria created lists (see below); you have access to someone proficient in combining Lua and templates.
In this method you will normally start by adapting your existing list templates (row templates) so that they fetch data from the Wikidata item corresponding to a monument when a value is not manually provided in the template. Once the template has been modified you can then remove all of the data which is available on Wikidata. E.g. you may wish to get coordinates from Wikidata while still having that intricate description of how to get to the monument directly entered in the list.
While these types of lists will stay synced with Wikidata for all of the listed monuments they still require manual syncing when new monuments are added to Wikidata or when a monument gets delisted. Note that the length of your lists will be limited both by the number of template calls and the amount of Lua complexity.
Example:...
Wikidata powered lists (Listeria)[edit]
This method may be considered if:
- you didn’t have any lists previously or are happy to abandon those lists;
- you are ok with the lists not containing any information that is not on Wikidata;
- you are ok with the lists not being directly editable;
- you want to surface the lists on a wiki which allows Listeria created lists in the desired namespace.
This method relies on the Listeria bot, a tool which automatically generates lists based on a selection criteria. The bot will overwrite the contents of the list once per day, including any edits done by users, for this reason many wikis do not allow these lists in the main namespace.
The formatting of the list can be done using the same row template as for non-Wikidata powered lists, meaning you can still have upload buttons, etc. On the page where you want the list you add the Wikidata list template (you might have to import it to your wiki) any you specify the selection criteria (as SPARQL) for that particular page, along with the information about which bits of data you wish to pass on to your row template and into what sections you wish the list to be divided on the page.
These types of lists will automatically update whenever a new monument is added or removed. Note that the length of your lists will be limited by the number of template calls and for this reason it is necessary to find a way for limiting the size of the lists to 200-300 entries by modifying the selection criteria.
Wiki Loves Monuments Map (Monumental)[edit]
Cautionary note (2022): Monumental is not being actively maintained anymore, only basic troubleshooting is available.
This method may be considered if:
- your data mainly contains monuments with known coordinates;
- you are ok with the information not containing anything that is not on Wikidata;
- you are ok with the surfacing occurring outside of a wiki;
- you want a modern sleek design with a painless upload process;
- you want your participants to easily contribute with images from any country.
The Wiki Loves Monuments Map is a monument discovery tool and upload tool in one. Since it does not live on a wiki it is also not limited by wiki restrictions in layout allowing for a much more modern experience. Because upload takes place from within the tool the users need not visit Wikimedia Commons which removes a hurdle for new users but also introduces some limitations which may be noticed by more experienced users. Note that the images are still uploaded to Wikimedia Commons in the background using the user’s user account.
If you are utilizing a special template for tagging the images on Commons with the corresponding monument id or only allow some types of cultural heritage sites as part of the competition you will need to contact the team behind Monumental to ensure that support for your dataset is implemented.
Note that any monuments in your dataset which do not have coordinates will not be discoverable through Wiki Loves Monuments Map. As the selection criteria is not directly created using SPARQL, your dataset may not be supported by the tool if it requires a very convoluted criteria.
Monuments Database powered tools[edit]
The limitations and use cases of these tools vary, likely you are considering these as a complement to another method or because you were already using one such tool before.
Over the years various tools have been built on top of the Monuments Database which also allow for direct upload or discovery. All that is needed for these to work is that you ensure your data gets harvested by the Monuments Database.
Example: wlm-maps (2018)
Selecting your data[edit]
The largest difference between the traditional lists and having your data in Wikidata is the change from specifying each and every included monument to having to specify how to select only those monuments from among all of the data on Wikidata.
Isolating your monuments from all of the information available on Wikidata largely depends on how well behaved your data is. If you want to select all of the monuments with an (unique) identifier in a specific heritage register that only requires one simple question to Wikidata. If you only want to select some of those monuments (e.g. because there are two levels of protection) then you additionally need to tell Wikidata how to distinguish between the two. But once your monuments can have multiple identifiers from the same heritage register, with multiple protection types the simple truth is that specifying a selection criteria gets very complicated. Luckily most datasets fall in one of the easier categories.
To describe these selection criteria the SPARQL query language is used. You can either try it live on the wikidata query platform where there are multiple ready made examples available or you can ask for help in formulating it.
When composing your criteria it is good to:
- start with one which selects all of the monuments that you want (but nothing else);
- [for Listeria] consider what you need to add to break it down into shorter lists, e.g. by municipality;
- [for Listeria] for multi-valued fields consider how to only get the type of value you are interested in (e.g. if a monument is both a national heritage site and a world heritage site you only want the values related to the former)
Examples:
- All allowed monuments in a Swedish dataset, simple query where every item corresponds to a unique id and all such items are included in the competition.
- Same dataset as above but limited to a particular county, for dividing a list created with Listeria
- Australian monuments in a particular state including protection type and class, a complex example where each Wikidata item may have multiple protections and the id type (property on Wikidata) is also used for items which are not included in the competition.
Telling the Monuments Database how to harvest your data from Wikidata[edit]
The main practical reason for why you want to ensure your dataset is included in the Monuments Database is that it is needed for automated tools providing (amongst other things): basic categorisation of newly uploaded images;
- a report of new images of previously unphotographed monuments, allowing you to quickly put the Wiki Loves Monuments contributions to use;
- a report of new images that don’t contain a valid id, allowing you to contact the uploaders informing them that action is needed for the image to qualify;
- basics statistics for your dataset;
- and that it is used to power more complex tools.
If your data used to live in lists on a wiki and were harvested by the Monuments Database then all that is now needed is a SPARQL selection criteria for the whole dataset.
If your dataset is new or was not harvested before then some additional basic information is needed about your set-up on Wikimedia Commons (templates and categories) as well as the wiki pages where you would like the reports delivered.