Template talk:Artwork

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
Info non-talk.svg Template:Artwork has been protected indefinitely because it is a highly-used or visible template. Use {{Edit request}} on this page to request an edit.
Please test any changes in the template's /sandbox or /testcases subpages, or in a user subpage, and consider discussing changes at the talk page before implementing them.

Future Improvements to Module:Artwork[edit]

First version of Module:Artwork is deployed so let's keep track of small improvements we can make:

  • Better Data extraction from Wikidata:
    • Exhibition history fetches data from exhibition history (P608). Currently the dates of the exhibition come from P608 Qualifiers, but they also can be properties of the exhibition item. They should be fetched from there.
    • Some files belong to multiple collections/institutions and can have multiple inventory numbers (one for each collection/institution). Not sure what that means and how to create {{Artwork}} from such data. Maybe item is really for 2 separate artworks.
    • If the subject of the template is a building than the creator/author might be stored in architect (P84). Fetch it from there.
    • Some works use author (P50), so we should recognize it as well.
  • Other:

--Jarekt (talk) 20:09, 16 April 2018 (UTC)

@Jarekt: One of the reasons why I've been focusing on categories rather than files is due to the impending arrival of structured commons. How do you envisage this template changing/migrating to use that once it's available? Maybe @SandraF (WMF): can comment here. I've also been worried about the server load when using arbitrary access to fetch info from Wikidata in the categories, but that's even more of a concern here since there's 1.8 million uses of this already, have you checked into that? Finally, it would be better to replace {{Object photo}} with this template rather than redirect {{Category definition: Object}} here, so we can use the wikidata infobox in those categories and not have a mess of category-content being included in file pages. Thanks. Mike Peel (talk) 20:37, 16 April 2018 (UTC)
Mike Peel, At the moment I am focusing on structured data what will live on Wikidata. When at some point Structured data for Commons arrives I hope we could do something similar. The steps would be:
  1. Ensure structured data has similar capabilities as Wikitext
  2. Write efficient and maintainable code to pull data from structured data and display it in a localized manner on Commons. If possible avoid templates and prefer Lua, as switching back and forth can get confusing.
  3. build mechanism for comparing Commons data to Wikidata, and copying metadata from Commons to Wikidata if possible.
  4. Part of comparing data is to flag mismatches. The final step would be to resolve mismatches and to remove redundant Wikitext.
The same steps can be used with structured data on Wikidata and on Commons. As for performance, I try to write as efficient code as possible but otherwise I believe that en:Wikipedia:Don't worry about performance. Module:Artwork is used on 1.8M pages, Module:Creator is used on 2M mages for last 2 years with no issues. But I did remove some expensive calls done by old {{Artwork}}.

Template Template:Object photo is some bad idea which is unfortunately used on a lot of pages. Lets discuss it on a separate occasion, and {{Category definition: Object}} is designed to work with it. They all call {{Artwork}} and Module:Artwork. --Jarekt (talk) 04:26, 17 April 2018 (UTC)

@Jarekt: I'm okay with your efforts to deploy Lua and wikidata. I'm probably one of the main user of Object photo. I can modify my workflow but I need to know. Because we are not talking about few pictures. I'm dealing with +9500 categories using {{Category definition: Object}} and +40 000 files, most of them using {{Object photo}} Clin Pyb (talk) 17:37, 23 April 2018 (UTC)
At this point I would not modify your flow, and I am also not a big fan of {{Object photo}} template. I found it quite counter-intuitive and I do not like the idea of templates being stored in Category namespace. We have one system for Creator and Institution templates (Creator and institution namespaces) another for book templates (template namespace and third for artworks (category namespace). I think, it might be time again to talk about "Artwork" namespace. But that might be topic for another discussion. --Jarekt (talk) 02:11, 24 April 2018 (UTC)

One of the important missing features is the handling of qualifiers added to creator: anonymous in Wikidata. See d:Wikidata:WikiProject_Visual_arts/Item structure#Use of creator_(P170) in uncertain cases for a list and d:Q19911475 for an example. That should feed the "option" parameter of {{Creator}}. -Zolo (talk) 15:44, 24 April 2018 (UTC)

Zolo, Excellent suggestion. --Jarekt (talk) 14:02, 25 April 2018 (UTC)

Category:Artwork template with implicit creator[edit]

@Jarekt: files in this category (like File:'Autumn Landscape' by William Mason Brown.jpg)) are not actually showing a creator template. Is that intentional or not? Multichill (talk) 09:10, 21 April 2018 (UTC)

Multichill, that category is going away, it was added by old {{Artwork}} when name in the author string matched, existing creator. But there were too many mismatches to add them by the bot. For a while I was adding creator templates by hand but that is too much work. I wrote once a bot that automatically adds creator templates when file is inside a category which is a homecat of the same template, but lost the code somehow after the first run. At the moment local variables take precedent over fields from Wikidata. So for the files that are in Category:Artwork template with implicit creator and have item ID, we should just remove the author field and we should see creator template. --Jarekt (talk) 18:00, 21 April 2018 (UTC)
@Jarekt: that makes sense.
I had a look at the first file in the category (File:'Mandarin Ducks in Snow' from the 'Colorful Realm of Living Beings' by Ito Jakuchu.jpg) in I noticed the "author" field is set, but not showing. Can you fix that? This happens a lot when {{Information}} gets converted to {{Artwork}}. Multichill (talk) 10:22, 24 April 2018 (UTC)
Pictogram voting keep.svg Fixed the "author" field issue in Module:Artwork/sandbox will deploy with the next batch of changes. --Jarekt (talk) 13:53, 25 April 2018 (UTC)

Category:Artworks without Wikidata item and Category:Paintings without Wikidata item broken[edit]

@Jarekt: Category:Artworks without Wikidata item and Category:Paintings without Wikidata item seem to be gone in Module:Artwork. Can you please restore it? Most of my reports are broken now. In this version you can see the logic. I assume more of the tracker categories didn't completely survive the move. Can you also check:

  1. Category:Artworks with Wikidata item should have a space in front of the sortkey and the Wikidata item as the sortkey
  2. Category:Artworks with known accession number should also have a space in front of the sortkey and use the inventory number as the sortkey. Some cleanup needs to be done to remove wikitext crap in the sortkey

The space in the sortkey is a MediaWiki trick to disable some sorting logic. Thanks, Multichill (talk) 09:41, 21 April 2018 (UTC)

I will look into this tonight (in ~ 6 hours) --Jarekt (talk) 18:01, 21 April 2018 (UTC)
@Jarekt: the without categories seemed to have filled up again. Thanks for that! I hope you can also have a look at the sortkey issues. Multichill (talk) 10:15, 24 April 2018 (UTC)
Multichill, I added spaces in front of sortkeys in Module:Artwork/sandbox (around lines 328). The "cleanup" is at the moment only a test based on length. We could come up with some more elaborate cleanup stripping URLs, and wikitext beforehand. I wonder if someone come up with some regexp (like [1]). The issue with sortkeys is that they are not visible, so some external testing will be needed. --Jarekt (talk) 14:23, 24 April 2018 (UTC)
@Jarekt: thanks, please deploy it.
Length is already a good first step. Also stripping out all wikitext special characters is probably a good next step (those were the ones causing problems). As for testing, adding a debug option in the sandbox that shows the stripped string after the accession number fields is probably good to debug. Than you can put in templates, links and urls and see if nothing weird comes out of it. Multichill (talk) 10:10, 27 April 2018 (UTC)
Multichill, The version with spaces is deployed now. I will look into stripping more. Could you create a list of test cases to test the new functions on? Some Accession Number before and after. --Jarekt (talk) 03:00, 28 April 2018 (UTC)

The template is using redundantly the uploaded image on the box[edit]

Hi, please look at File:Berta Lutz no avião do qual se lançaram panfletos de propaganda pelo voto feminino.jpg. The item for that file on Wikidata has image (P18) property and the Artwork template used on the image show the own image uploaded. I don't think the redundancy it's ok. What do you guys think, am I wrong? Ederporto (talk) 05:07, 23 April 2018 (UTC)

Also, the "usage of the file" points to the image itself. Ederporto (talk) 05:10, 23 April 2018 (UTC)
Ederporto the idea is that that is the simplest way to spot when you have a wrong item ID, which is rare but happens. it also shows when the item is missing image (P18). It would not be hard not to show the image if it is the same as the current page. How do others feel about this feature? --Jarekt (talk) 11:52, 23 April 2018 (UTC)
I like the thumbnail, but can agree with it being a bit redundant if it's the same file. Probably better to only show it when it's a different file.
This also opens up the interesting possibility to query the database for {{Superseded}} images that are in use on Wikidata. Multichill (talk) 10:14, 24 April 2018 (UTC)
I think it's useful to always have it there, even if it is a duplicate - otherwise you don't know if the image hasn't been set or if it's the same as the current file. I don't think the redundancy is a problem, as long as it's done by the code not manually. Thanks. Mike Peel (talk) 12:27, 24 April 2018 (UTC)
I find it useful for multiple images of the same artwork. It suggests the preferred one and possibly superseded. For avoiding redundancy the thumbnail could be changed by a text like "Image used in corresponding Wikidata item". --V.Riullop (talk) 09:02, 25 April 2018 (UTC)
Or maybe making the thumbnail much smaller when it's the same image? Multichill (talk) 10:13, 27 April 2018 (UTC)
Or just add an opt-out parameter for the thumbnail display. De728631 (talk) 10:29, 8 May 2018 (UTC)

Category:Artworks with Wikidata item missing image[edit]

I renamed Category:Artworks with Wikidata item without image to Category:Artworks with Wikidata item missing image. That was already done in the template. Some subcategories like Category:Relief No. 1 - Henry Moore (LH 450) still use the old category. It seems to be something with a local image field. @Jarekt: can you have a look, can't seem to find where this is set. Currently we only check for P18 (image) on Wikidata, but we also have a few files like File:Rabier - Oscar roi du désert, 1928.djvu that use a different image property. Would be nice to filter out these too. Either by hard coding a list of relevant properties or just looping over the properties and see if a property with type "commonsMedia" is present. This is a minor improvement, only a few files and they're still hidden because of the MET overload... Multichill (talk) 10:11, 24 April 2018 (UTC)

Multichill, All the "without" categories in the old {{Artwork}} were added if the field was filled on Commons but missing on Wikidata, the only exception was Category:Artworks with Wikidata item without image which was added if image on Wikidata was missing. Now I added field image to {{Artwork}} (still have to update the documentation) to make it compatible with {{Category definition: Object}}, Artwork adds both Category:Artworks with Wikidata item without image (defined on Commons & missing on Wikidata) and Category:Artworks with Wikidata item missing image (not defined on Commons and missing on Wikidata). I could not find any images in the first category when testing, because I wanted to add QuickStatement link to quickly upload such images to image (P18). --Jarekt (talk) 12:06, 24 April 2018 (UTC)
Speaking Category names in Category:Creator template maintenance and Category:Institution template maintenance I tried to follow the following rules:
  • Category is named after the field name in the template not the property on Wikidata
  • The following keywords are used:
  • A single template can only be in one of mismatching/redundant/missing/local categories for each field.
I think it would be less confusing if we adopted similar system with Artworks, especially using the same keywords. Although we would have to invent a new keyword for current Category:Artworks with Wikidata item missing image. --Jarekt (talk) 12:31, 24 April 2018 (UTC)
@Jarekt: sure, go ahead, I just made up some names to be able to track these files. Moving some of them around to get a more consistent naming sounds like an excellent plan. Only the "accession number" are special because I use these for database queries and matching so probably best to leave that logic intact too. Maybe you can list the renames and creations here? Multichill (talk) 10:22, 27 April 2018 (UTC)
I have switched category names to use missing keyword instead of without. --Jarekt (talk) 15:27, 2 May 2018 (UTC)

author field[edit]

The author field doesn't appear, despite being used. --Cold Season (talk) 23:58, 24 April 2018 (UTC)

Pictogram voting keep.svg Fixed in Module:Artwork/sandbox will deploy with the next batch of changes. Thanks for reporting. --Jarekt (talk) 13:51, 25 April 2018 (UTC)

Future Improvements to related to Wikidata (one section per field)[edit]

I find it hard to keep track of different suggestions of improvements. So lets have a section for each. If anybody is interested in writing code to handle any of those cases let me know. --Jarekt (talk) 14:34, 25 April 2018 (UTC)

Collapsing Creator and Institution templates inside Artwork template[edit]

See discussion at Commons:Village_pump#Innercollapse_and_outercollapse. --Jarekt (talk) 13:51, 25 April 2018 (UTC)

Author and Artist fields[edit]

Need to improve wikidata harvesting with possible separate function for it:

--Jarekt (talk) 14:34, 25 April 2018 (UTC)

✓ Done --Jarekt (talk) 19:36, 2 May 2018 (UTC)

Institution and accession number fields[edit]

Need to improve wikidata harvesting with possible separate function for it. Special cases to handle:

--Jarekt (talk) 14:34, 25 April 2018 (UTC)

Wikidata has collection (P195), location (P276) and also owned by (P127) to store this kind of info. The The Night Watch (Q219831) is always a good example, it's in multiple collections at the same time, but has only one "Current location" and currently that comes out correct as Rijksmuseum (not sure if this is by design or by chance). In the Accession number field it should show SK-C-5 (Rijksmuseum inventory number, C indicates a loan) and SA 7392 (Amsterdam Museum inventory number, SA indicates ownership by the city of Amsterdam). With multiple inventory numbers, the collection should be between brackets. Something like: "SK-C-5 (Rijksmuseum) & SA 7392 (Amsterdam Museum)". Only inventory numbers that don't have an end time should be used here. The correct usage of inventory number (P217) is to have it on the item qualified with collection (P195), not the other way around so probably best to just ignore that.
To explain the collection (P195) and location (P276) a bit more (currently about 303K paintings):
Interesting puzzle to solve. I have some notes about it. I'll probably set up a report to find mistakes. Multichill (talk) 10:48, 27 April 2018 (UTC)
Multichill thanks for insight. I will see if I can code some of those rules. --Jarekt (talk) 19:37, 2 May 2018 (UTC)

Multichill, more colorful examples:

Some of those will be a challenge to display in some logical fashion. --Jarekt (talk) 19:08, 4 May 2018 (UTC)

One more thought. I would prefer to create Artwork template while querying as few items as possible, so I might not be able to easily discover parent/child institution relationships between collections and locations. At the moment I load the artwork item, an item for each creator and a single one for institution template. --Jarekt (talk) 19:20, 4 May 2018 (UTC)
@Jarekt: these appear multiple prints (copies) documented on one item. Should probably be split up. Multichill (talk) 18:56, 8 May 2018 (UTC)
Multichill, yes d:Q3898508 and d:Q1218084 are prints witch multiple copies, d:Q26974941 is a group of sculptures which was inventoried separately, d:2702287 are pieces of the same Greek vase which were inventoried separately and possibly can be found in Berlin and Greece, d:Q398126 is a painting which maybe was bought by group of museums (?), d:Q20200892 is a painting where ownership history is saved using collection (P195) field. A problem with d:Q20200892 is that we know the order of ownership but not the precise dates of changing ownership. Probably owned by (P127) should be used instead. Anyway, I am trying to come up with some logic that would work with those test cases. I should probably check how frequent they are and figure out which are just hopeless or wrong and which should be supported. At the moment I am ignoring collections/locations with the end date, I might have some special treatment for Louwre. --Jarekt (talk) 20:43, 8 May 2018 (UTC)
The current owner and collection should probably have the "preferred" rank in Wikidata, which may solve most of the relevant cases. Other cases will be more complex, I think the template could simply categorize them so that we can either fix data in Wikidata or pass a local parameter in Commons.
File:Berckheyde, after - City hall in Amsterdam - 1668-1670.jpg does not show actual institution and the ranks and dates do not help--Oursana (talk) 19:15, 7 July 2018 (UTC)


It may be worth reconsidering how we display collections / locations / owners. We currently have two fields called "collection" and "department" and the label for both is "location". In some cases, that is not really accurate. A sculpture shown in the street typically has neither a collection nor a department. More fundamentally, "collection" may not be related to the location. Here again French public museums are a thorny case. Many works in various museums are actually long term loans from the Louvre or the Musée d'Orsay. Take File:Vue du port de Brest.jpg, I think the collection is technically the departement of paintings of the Louvre (source) but the painting has been in the musée de la Marine for years, and is likely to remain so in the foreseeable future. Note that the owner is yet something else, namely the French State. (user:Shonagon may be able to correct me if I am wrong.) --Zolo (talk) 09:09, 9 May 2018 (UTC)

Commons Creator page (Q24731821) is the wrong item for the QuickStatements export here[edit]

Thanks for updating to Wikimedia Commons (Q565) or perhaps a new item "Commons Artwork template", --Marsupium (talk) 21:59, 26 April 2018 (UTC)

I was thinking about adding references of imported from Wikimedia project (P143) Wikimedia Commons (Q565) and reference URL (P854) with actual page URL to QuickStatements exports. I debated about creating a new item for "Commons Artwork template", but was not sure what else would be in such item. --Jarekt (talk) 03:44, 27 April 2018 (UTC)
Marsupium, I can not get addition of reference URL (P854) to work. Maybe image (P18) and Commons category (P373) as references? What do you think? --Jarekt (talk) 19:36, 2 May 2018 (UTC)
Sorry for answering that late! Oh, neither imported from Wikimedia project (P143) (whether with a new value item or not), nor reference URL (P854) is the right property, but evidently Wikimedia import URL (P4656). I think in combination with retrieved (P813). image (P18) and Commons category (P373) would feel a bit of a misuse of these properties, no? What is the problem with getting it to work? A QuickStatements bug/missing feature? --Marsupium (talk) 07:54, 3 May 2018 (UTC)
I described the issue here and here, but in the nutshell I can create identical URL the QS tool produces, but clicking it changes the URL (replacing space, underscore and "%5F" characters with "%20") and reference URL inside it, which fails some check latter (check for spaces in URL perhaps?). It is not the issue of tool or URL but how browsers deal with underscores in URLs. It is possible Magnus could do something about it in QS tool and it is also possible that one can create URL which when clicked will produce URL with underscores, but in the mean time We are stuck with QuickStatements that is not working right. I could just disable it until we figure it out, or we could use image (P18) and Commons category (P373) as references. But I agree it is a bit of a misuse of these properties. --Jarekt (talk) 12:28, 4 May 2018 (UTC)

Accession numbers swallowed[edit]

This fixes the problem of accession numbers getting swallowed since recently. Random example: File:"Among Friends", Stanley Park, Vancouver, B.C..jpg. Thanks in advance for deploying! --Marsupium (talk) 21:05, 26 April 2018 (UTC)

Face-smile.svg Thank you--Jarekt (talk) 03:44, 27 April 2018 (UTC)
The fix was deployed. --Jarekt (talk) 15:29, 2 May 2018 (UTC)


For some archelogical artefacts and other objects, weight (ok mass) may be relevant information, like in File:Cray-2-p1010255.jpg. I think we can put that in the dimensions fields. For Wikidata data, it might be a good idea to make use of d:Property:P2067. --Zolo (talk) 09:20, 2 May 2018 (UTC)

We could expand Module:Size to include weight. It would be bigger change as at the moment we only have code for length measurements. --Jarekt (talk) 11:39, 2 May 2018 (UTC)
Symbol support vote.svg Support Yes, I thought that before, we should get this. But I don't think we are in hurry with that improvement!? --Marsupium (talk) 07:57, 3 May 2018 (UTC)

Object history: (wrong) value without entry[edit]

Hi, I observed several values without entries like this one:

I don't believe these paintings were meant to be "discovered". Where do these values come from? Wrong connection to Wiki Data? Greetz! Bukk (talk) 06:41, 3 May 2018 (UTC)

Good question. Not from Venus in front of the Mirror (Q9358938). --Marsupium (talk) 07:55, 3 May 2018 (UTC)
Pictogram voting keep.svg Fixed --Jarekt (talk) 12:06, 4 May 2018 (UTC)
Thanks a lot! Bukk (talk) 12:53, 5 May 2018 (UTC)

Incorrect Item IDs[edit]

Category:Artworks with wrong Wikidata item hold pages with Wikidata item ID which link to items for people, taxons, etc. (human (Q5), Wikimedia template (Q11266439), Wikimedia disambiguation page (Q4167410), film (Q11424), village (Q532), album (Q482994), taxon (Q16521), Wikimedia category (Q4167836)). Most files in the category links to items about subjects and authors. Please help me review those cases and replace or remove item IDs. The only tricky case I encountered are bog bodies, as the mummy is at the same time human (Q5) and archaeological artifact (Q220659). I will have to add some logic to exclude those from the category. --Jarekt (talk) 14:19, 4 May 2018 (UTC)

Artwork namespace[edit]

We currently have "Creator" and "Institution" namespaces that host metadata related to specific creator or institution. Over the years we had several discussions of creating Artwork namespace (or Object namespace) which would host metadata related to a specific artworks or objects. At the moment we store such data in several places:

  • Individual files - that is fine if we only have one image of a given artwork, but once we have more than one than we duplicate the data and there is high potential for conflicting info
  • Wikidata - Wikidata is great for storing majority of the metadata; however as with Creator and Institution templates custom changes are occasionally needed to to overwrite values from Wikidata, also sometimes objects are not notable enough for Wikidata item (like individual gravestones)
  • {{object photo}} and {{Category definition: Object}} is a system of templates that allows to store the metadata in the Category namespace page and transclude it from there as if it was a template. It is quite confusing and surprising to uninitiated. It is hard to figure out where the data is stored, if something need fixing.
  • Category:Single artwork templates stores many templates (in template namespace) which store metadata for individual artworks.
  • We also have pages like Artwork:Ruhendes Mädchen (1751, Wallraf-Richartz Museum) or Artwork:Pascale Marthine Tayou, La Colonne Pascale storing the metadata in gallery namespace. Many of those pages have incorrect categories, since categorizing template adds categories to all images transcuding it.

I would like to propose to create a new Artwork namespace, which would work like "Creator" and "Institution" namespaces and store pages about individual artworks, something like Artwork:Mona_Lisa. Than we could create "artwork pages" for all current templates storing such metadata in variety of formats. We would add linkback field to the template so we could provide the link to the page where the data is stored and uniform format would allow us to make it compatible with {{Art Photo}} template. The issue was discussed many times over the years (here, here, or here, but we never finalized it. I thought we can discuss it here first before going to Commons:Village pump/Proposals. @Multichill, Rama, Zolo, Jean-Frédéric, Marsupium: Pinging participants in past related discussions.

As for Artwork vs. Object, I prefer "Artwork" as it matches the template name and "Object" I so broad we might get pages with {{Book}} and {{Photograph}} or {{Map}} templates. --Jarekt (talk) 18:01, 7 May 2018 (UTC)

Not quite sure. It might be better than what we currently have, but for many works, most data should eventually be pulled from Wikidata. For others we have just one file, and using a separate namespace sounds like an overkill. I have not closely followed the development of structured data for Commons, so I don't know if that will help for that too. Zolo (talk) 11:21, 8 May 2018 (UTC)
Zolo, The idea is not to put all Artwork templates in Artwork namespace, just to place all the templates we have now, which are currently stored in Category, Template and Gallery namespaces. We need some uniformity and predictability, and designated namespace model worked well for Creator and Institution templates. And as with Creator and Institution templates if there is associated Wikidata item we could remove local metadata in favor of unified metadata from Wikidata. --Jarekt (talk) 11:45, 8 May 2018 (UTC)
Maybe a "pseudo-namespace" is ok for the time being ? Like what we had at the beginning of {{Institution}}. That would make it possible to unify things without software changes. And if we transclude it through {{Art Photo}}, the difference will be essentially invisible to people working in the file namespace (the ":" that has to be added to transclusion can be put directly in {{Art Photo}} ~--Zolo (talk) 15:27, 9 May 2018 (UTC)
Zolo, "pseudo-namespace" could work and we can always create a real namespace latter if needed. --Jarekt (talk) 20:16, 11 May 2018 (UTC)
(edit conflict)
thank you @Jarekt: for starting this thread, this is very useful. My two Euro cents would be:
  • Maybe ping our disinguished colleagues at Commons:Structured data as not to duplicate work and seize opportunities to make each other's work easier from the design stage
  • for Artwork vs. Object, how about things that as not Artwork, such as museum exhibits? For instance, with Category:Galvanometer-MHS 229, saying that Nobili is the "author" of a galvanometer pushes the boundaries of what our culture considers to be an artwork (which is an entirely social construct, and possibly a rather silly one at that, but it is not our place to agitate for change in this respect).
Cheers! Rama (talk) 11:29, 8 May 2018 (UTC)
Rama I intended this discussion to be in smaller settings so if we propose it at Commons:Village pump/Proposals we have coherent idea that most people active in the field support. I assume Structured data will be similar to Wikidata so it will have the same limitations. Artwork namespace would allow us to create unified way to store meatdata in the way people are already used to. Unification of current infoboxes can only help with with migration to Structured data. As for Category:Galvanometer-MHS 229, it is definitely an object or artifact not an artwork. Term "Artwork" was always a bit narrower than what {{Artwork}} was used for. That is why some argued to switch to wider "Object" term. I am fine either way. Maybe if we create Object namespace we could allow in it pages using {{Artwork}}, as well as {{Photograph}}, {{Map}}, {{Book}}, etc. templates. They could share the namespace and we could have separate maintenance categories for them. --Jarekt (talk) 12:13, 8 May 2018 (UTC)
Symbol oppose vote.svg Oppose I think it's better to skip this step, and just use the info from Wikidata. There's not much point having an Artwork namespace if it just consists of small aliases to Wikidata like e.g. Creator:Werner Haberkorn does. Personally, I'd like to see the Creator and Institution namespaces deprecated in the near future. Thanks. Mike Peel (talk) 11:57, 8 May 2018 (UTC)
Mike Peel I also do not see much point having templates that just consists of small aliases to Wikidata like e.g. Creator:Werner Haberkorn. Before rewrite of {{Artwork}} you kind of had to do that as {{Creator:Werner Haberkorn}} was much more readable than {{Creator|Wikidata=Q16941108}}. But now if you add item ID to Artwork template than it can look up Creator on Wikidata. We could start removing Creator and Institution templates from Artworks if they are redundant. Also if a Creator/Institution template is called only from Artwork template and does not have any local fields, like those templates, than they can be removed. However I do not think we will be deprecating Creator and Institution namespaces anytime soon as it will take a lot of manual labor to reconcile all the mismatches between Commons and Wikidata metadata, like here, and as far as manual cleanup goes for last decade we are working on adding infoboxes to files that do not have them. I think we need Artwork/Object namespace so we can clean up the mess we have with current Artwork templates living in 3 namespaces, and especially 15k Categories used as templates, now. I would like to clean up current use of {{Artwork}} templates, without loss of any metadata Commons users curated over last decade. If there is a way to do it without a new namespace, I will support it. --Jarekt (talk) 12:50, 8 May 2018 (UTC)
My first response was: Oh no, not another namespace, we have structured data for Commons coming up, but I think I agree with Jarek: The jump from the current mixed setup to everything to Wikidata is to big. It's like going from crawling to running and skipping the walking step. This is a nice intermediate step in the process. It also offers us more flexibility like with the creator and institution templates. Multichill (talk) 14:21, 8 May 2018 (UTC)
I'm not convinced. I think we can do that jump if we want - and doing so lets us focus on the tools we need to ultimately have and the migration that needs to be done to get there, rather than spending time on the intermediary step. Or if we can't do that, then why can't we use the existing namespaces (i.e., the template namespace) instead of creating a new one (which to me implies more permanency/a longer-term need)? Thanks. Mike Peel (talk) 23:38, 11 May 2018 (UTC)
The namespaces creator and institution are very nice as all the templates inside them follow the same set of rules, and if you understand one of them all the rest operates in exactly the same way. Also properties on Wikidata link to pages that are only in a single specific namespace. Book templates live in template namespace and there is much larger variety to them also one can not create link from wikidata that would link only to those templates. Maybe the best solution would be to follow User:Zolo advice and start using Artwork pseudo namespace, so the pages would technically live in gallery namespace but they would always start with "Artwork:". One would call it as a template not be calling {{Artwork:XYZ}}, but rather {{:Artwork:XYZ}}. And in the future we can always change them to real templates in their own namespace if we want. A bit of "try before you buy" approach --Jarekt (talk) 20:37, 13 May 2018 (UTC)
@Jarekt: Can you use the template namespace instead, as that might be less confusing? Something like {{Artwork/XYZ}} (or {{ArtworkTemplate/XYZ}} or something else if you want to avoid confusion with this template). Thanks. Mike Peel (talk) 13:21, 14 May 2018 (UTC)
Mike Peel, Something like Template:Artwork/Girl with a Pearl Earring I guess. That is a possibility, but I dislike creating thousands of sub templates to Template:Artwork or Template:ArtworkTemplate. Maybe {{Artwork:XYZ}} would work better. --Jarekt (talk) 13:49, 14 May 2018 (UTC)
I don't like the subtemplates at all. Namespace is much cleaner. @Jarekt: maybe get some more input? Multichill (talk) 14:11, 2 June 2018 (UTC)
Multichill I am unsure what my preferred solution is, and it seems like most users working with Artworks are not sure either. So my plan at the moment is to postpone the decision and get some better feeling on how many pages are we talking about. I noticed that great many pages with artwork templates in category namespace call User:Rama/Catdef template which is an early attempt to rewrite {{Artwork}} to pull data from Wikidata written by User:Rama. His template still does some things better than mine, so I will concentrate my efforts on merging capabilities of both templates. I will also try to look again at {{Art Photo}} and merge its capabilities with {{Object photo}}. Afterwards if we move as many pages towards regular {{Artwork}} and {{Art photo}} pages than eventually we will see how many pages actually need specialized Artwork templates for individual artworks. --Jarekt (talk) 14:38, 3 June 2018 (UTC)
I seize the opportunity to mention that my intent with User:Rama/Catdef was always as a mere demonstrator, and that I expect a bot to mass-change the relevant pages to Jarekt's template when the time is right. Rama (talk) 14:46, 3 June 2018 (UTC)


Hi there, we have a bunch of wrong usages of this template ending up in Category:Pages using Artwork template with incorrect parameter: homecat. Since i am not involved in the changes of the artwork template i wonder if it is connected resp. how we can fix it? --Arnd (talk) 13:39, 9 May 2018 (UTC)

I will fix that. --Jarekt (talk) 17:11, 9 May 2018 (UTC)
Pictogram voting keep.svg Fixed --Jarekt (talk) 13:13, 14 May 2018 (UTC)

New version[edit]

I just released a new version of the template / module. Main differences:

  • improved handling of extracting institution/department fields from wikidata, as discussed above with user:Multichill
  • improvements to maintenance categories
  • creator/institution templates fetched from wikidata by Artwork template will be autocollapsed by default in all namespaces (request by User:Zolo)
  • Files in Category:Artworks with Wikidata item without image will now have a icon for QuickStatements 2-clicks addition of the current image to image (P18). Please help me populate image (P18) fields of artworks on Wikidata. Please pick the best image to add to Wikidata, do not add multiple images to the same item. and be aware that the image might be in that category because of the lag between changes to wikidata and commons maintanance category updates (phabricator:T173339)

--Jarekt (talk) 13:43, 14 May 2018 (UTC)

institution's name[edit]

is repeated, see Venus and Mars Surprised by Vulcan (Tintoretto) and files--Oursana (talk) 17:58, 15 May 2018 (UTC)

I will look into it. Thanks for heads up. --Jarekt (talk) 04:11, 16 May 2018 (UTC)
Pictogram voting keep.svg Fixed by changing Venus and Mars Surprised by Vulcan (Tintoretto). Oursana the issue was a strange interplay of local fields and fields pulled from Wikidata. --Jarekt (talk) 12:15, 16 May 2018 (UTC)
Jarekt, not fixed, you changed the Institution >Alte Pinakothek to Bayerische Staatsgemäldesammlungen, which should be kept as Alte Pinakothek. Still as department shows WP Alte Pinakothek which is redundant.
See https://commons.wikimedia.org/w/index.php?title=File:Agnolo_gaddi,_storie_di_san_nicola_02.JPG&oldid=241329577 I reverted my wikidata-changes, which solved the problem, just to show you. I think it is only the problem with Alte Pinakothek. Grüße --Oursana (talk) 22:16, 23 May 2018 (UTC)
@Jarekt: this is one of the edge situations I described before. The location statement should trump the collection if it is linked to it using part of (P361). That would cover most of the German collections where we have a huge state collection spread over multiple locations. Multichill (talk) 09:20, 24 May 2018 (UTC)
Oursana & Multichill, I do have special treatment for Louvre ( Module:Wikidata art/sandbox (line 514) ) and not I added special treatment for Bavarian State Painting Collections (Q812285) ( Module:Wikidata art/sandbox (line 525) ), which is ignored and replacement with whatever is in the "location" property. See case 1 and 3 in Module_talk:Wikidata_art/sandbox/testcases#Institution. Is that correct behavior? --Jarekt (talk) 14:17, 24 May 2018 (UTC)

I give you another example Met/cloisters File:Robert Campin - Mérode Altarpiece - WGA14409.jpg, but IB, see cat, refers to collection:Met--Oursana (talk) 02:33, 25 May 2018 (UTC)

I think that in case of that image the institution, which issued accession number is the MET and cloisters is the actual collection. BTW, I released the new version of the code, so let me know if there are any additional improvements one can do for institutions and IDs. --Jarekt (talk) 03:13, 25 May 2018 (UTC)
Seems much better, see https://commons.wikimedia.org/w/index.php?title=File:Agnolo_gaddi,_storie_di_san_nicola_02.JPG&diff=next&oldid=302718619, adding "not on display" influenced additional collection information concerning the accession numbers

Category:Judith and her Maidservant by Artemisia Gentileschi Inv. Palatina 398 gives again double information institution/department--Oursana (talk) 22:38, 1 June 2018 (UTC)

Pictogram voting keep.svg Fixed That was a case of local variables conflicting with Wikidata variables. --Jarekt (talk) 23:04, 1 June 2018 (UTC)

Category:Pages using Artwork template with incorrect parameter[edit]

Info non-talk.svg
It is requested that an edit or modification be made to this protected page. Administrators: Please apply <nowiki> or {{tl}} to the tag after the request is fulfilled.


This maintenance category does not work properly anymore since the template has been replaced by Lua code: The errors (affected parameters) are not shown. Instead, non-existing categories are being added. --Leyo 19:48, 6 June 2018 (UTC)

I thought it was identical to the old functionality. I only added "non-existing categories" so it is easier to figure out what parameter is not recognized. --Jarekt (talk) 01:41, 7 June 2018 (UTC)
Not at all. The incorrect parameter name was shown on the file description page (Error in template * unknown parameter name (Template:Artwork): 'example'). If this malfunctioning cannot be fixed, a revert to the revision as of April 10, 2018 is the best option. --Leyo 20:56, 7 June 2018 (UTC)
Leyo, anything can be fixed. I am just trying to understand what is not working properly. From what I understand you would prefer some message in file description naming the incorrect parameter, instead of red category. I can do that. --Jarekt (talk) 13:05, 8 June 2018 (UTC)
Just as it used to be before (see e.g. File:Henri Lafontaine signature.png if you don't remember). --Leyo 13:16, 8 June 2018 (UTC)
[2] should do the trick. Multichill (talk) 21:08, 9 June 2018 (UTC)
Yes we could employ a call to Module:TemplatePar to do that, but I did not like calling two separate modules from a template for somethings so trivial, so I added a few lines of code to get the same effect. I forgot how Module:TemplatePar provides info on the name of the wrong parameter and I implemented my own way (red category), but having some message in red is also trivial. I just deployed a small tweak to the current approach, which should make it very similar to the old approach. --Jarekt (talk) 03:57, 10 June 2018 (UTC)
There is a shortcoming in your implementation: Only one incorrect parameter is indicated, even if there are multiple errors. --Leyo 21:43, 10 June 2018 (UTC)
You are right. I fixed it in the sandbox and will release the fix with next changes. --Jarekt (talk) 02:27, 11 June 2018 (UTC)
This issue seems to have been solved, but there is another one: If I introduce spelling errors such as | Permissin = or | other_versionss = I don't get any error message. --Leyo 09:30, 6 July 2018 (UTC)
It's actually the fact that only incorrect/inexistent parameters with a value are triggering an error message. I don't think this is a good idea. When e.g. an inexperienced user is eventually adding information to the file description page, they may get an error message without having made an error themselves. This may make them to remove valuable information to get rid of the error message. --Leyo 07:50, 9 July 2018 (UTC)
Tacking unused parameter does not seem to be worth the code changes which would be required or performance/maintenance expense to use one module for used and other module for unused parameters. I would argue for removal of any unused parameters for templates with Wikidata. --Jarekt (talk) 22:30, 18 July 2018 (UTC)

Help needed with moving some {{Size}} parameters to Wikidata[edit]

Category:Artworks with Wikidata item: quick statements lists files which have size info on Commons which is missing on Wikidata. In last week or 2 I exported many thousands of dimensions from Commons files to Wikidata, but those 100+ require more investigative work, since dimensions listed in several files do not match. Some of the reasons could be that item is not for a single item but for set of items and which should be split on Wikidata, or dimensions in some of the files are wrong and we should check in the source websites. I would appreciate some help with those as they are slow to process. --Jarekt (talk) 16:49, 2 July 2018 (UTC)

Link text too long with set language of work or name (P407) qualifier[edit]

When helping with the above I found in the references field on File:Gentile Bellini 002.jpg that the opening bracket for the language is included in the link. It shouldn't. Thanks, --Marsupium (talk) 00:45, 7 July 2018 (UTC)

Pictogram voting keep.svg Fixed -- User: Perhelion 07:38, 7 July 2018 (UTC)
Thank you! --Marsupium (talk) 11:10, 7 July 2018 (UTC)

Exporting artwork metadata to Wikidata[edit]

Just to keep community informed {{Artwork}} template is currently comparing metadata on Wikidata with metadata stored in Artwork templates on Commons and if some data is missing on Wikidata it tries to create QuickStatements URL which end up in Category:Artworks with Wikidata item: quick statements those could be run one at a time, but a faster approach is to run a query like this one and create large batch of QuickStatements which can be run few thousands at a time. Using that approach I exported large number of images to image (P18), artwork sizes to height (P2048) and width (P2049) and data from medium/technique field to material used (P186). I will also work on dates -> inception (P571), artist and institution fields, so eventually I hope to have basic metadata fields synchronized with Wikidata. If you have any questions, comments or improvements to the process let me know. --Jarekt (talk) 03:25, 13 July 2018 (UTC)

@Jarekt: noticed your bot, quite nice. What are the biggest collections with missing height and width (and maybe other fields?)? Might be able to grab it from the collection website and properly source it. Multichill (talk) 11:37, 13 July 2018 (UTC)
From Commons end it is hard to tell as Category:Artworks with Wikidata item missing dimensions is probably way out of date due to phabricator:T173339 issue. We can probably write SPARQL query to look for Artworks without sizes or with missing or weak sources. Any statement sourced to Commons files, ideally will be confirmed with proper source, and I think we should have a bot removing references to wikimedia projects when proper sources are present for a given statement. Problem with dimensions is that many collections do not identify which dimension is which and only provide something like "100 x 200 cm". Usually that is height by width, but not always. Lately, Module:Size was trying to figure out which dimension is height and which is width by comparing them to height and width of the files. --Jarekt (talk) 12:09, 13 July 2018 (UTC)

Multichill to think of it, two collections with a lot of images that could use big help with missing items or metadata on Wikidata are:

  1. Images from MET, like File:Adam MET DP338629.jpg. The upload is done by User:Pharos. Some are linked to existing items but great many does not have wikidata items, like this one. It would be better to pull the data from www.metmuseum.org instead of scraping it from images.
  2. tombs in Père-Lachaise Cemetery, like Category:Grave of Albrecht (Père-Lachaise, division 91) with metadata from Base Mérimée(no metadata about individual objects). We have over 10k categories in Category:Graves in the Père-Lachaise Cemetery, mostly created by User:Pyb. Most of them transclude {{Category definition: Object}} templates stored in category namespace into individual files, so a better way would be to move some of that data to Wikidata and for files to pull it from there.

--Jarekt (talk) 15:06, 13 July 2018 (UTC)

Multilingual Object type support requested[edit]

If I use

|object type = painting

painting points to https://www.wikidata.org/wiki/Q3305213 and is replaced by its multilingual equivalent found there.

That isn't true for

|object type = illustration

(doesn't point to https://www.wikidata.org/wiki/Q178659, nor is it replaced by its multilingual equivalent). I wish it would be.

Carl Larsson Spring Princess 1898.jpg might be a painting, or maybe just a magazine illustration. So, I used

|object type = painting {{or possibly}} illustration

In that case, it turned off the multilingual equivalent generation of painting for some reason, and you end up with the multilingual {{or possibly}} between two English words. I wish that at least painting would be recognized in that context (doesn't have to be a standalone value).

Thank you.Mabrndt (talk)

Object types are translated by {{i18n/objects}}. Only types appearing there exactly as typed in the {{Artwork}} template (except for leading/trailing whitespace) are internationalized. Illustration can be added, but support for {{or possibly}} seems impossible for me. You can use
{{i18n/objects|painting}} {{or possibly}} {{i18n/objects|illustration}}
to internationalize everything (illustration will not work at the moment, of course, as that’s not present in the template currently). —Tacsipacsi (talk) 22:04, 15 July 2018 (UTC)

Title parameter[edit]

I am not sure whether we have already talked about it, but there seems to be slightly wrong with the parameter "title" when the object is not really an artwork. Take this for example. "Blade PRE 2009.0.214.4" does not really feel like a title, just a description (with an accession number for disambiguation). What can we do about it ? I think we should be at least able to locally disable the title parameter with a special value like |title = ~. When data come from Wikidata, maybe we should only use title (P1476) and official name (P1448). native label (P1705) would still be used in the header, but not in the "title" field within the box. I don't think we would really miss anything that way. --Zolo (talk) 13:54, 18 July 2018 (UTC)

I guess we could be more inclusive with the name in the top bar and a bit more selective in "title" field. I will look into it. --Jarekt (talk) 19:17, 18 July 2018 (UTC)