Template talk:Artwork/Archiv/2018

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

What comes first? The Chicken or the Egg? The Artwork template or the wikidata item?

I have lately uploaded files of artwork to Commons. Where I found a Wkidata-Item to the object, I added it. Where there is no Wikidata-Item, it would be nice to have one. Now I hate to do work twice. I use the description the museums provide and add them to the Artwork-Template. Is there already a way that Wikidata extracts this information to built new items, or incorporate them into existing items? Or can I built the Wikidata-Item and than get a meaningful description on Commons. I work with Lightroom and use the LrMediaWiki-Upload Tool.When adding a known Wikidata-Item, it only adds the Wikidata-Icon without further description to the Title of the image.

I shortly want to upload images from museum at home, large enough to have a unique and valuable collection, but still unbothered by the Google Artproject. I think it would be nice, if we could show them what using Wikidata could do to their collection. --Wuselig (talk) 22:38, 18 January 2018 (UTC)

I agree that at the moment proper way is fill both Wikidata item and artwork template, which is tedious and most of the work is duplicated.
At the moment Wikidata are capable to store most of the artwork-related information and it is possible to improve this template so that it can fetch these data from Wikidata. Wikidata paintings project (d:Wikidata:WikiProject sum of all paintings) is very active, so some collections and creators are very well covered (see d:Wikidata:WikiProject_sum_of_all_paintings/Top_collections and d:Wikidata:WikiProject sum of all paintings/Top creators by number of paintings).
I think it is time to start to discuss about that, I'm a big supporter of this improvement.--Jklamo (talk) 14:35, 5 February 2018 (UTC)
@Wuselig: in the past the {{Creator}} template contained a lot of redundant information, but thanks to Jarek we can now just have it fetch the data from Wikidata (example). I expect this to happen with the {{Artwork}} template too and I hope Jarek will have time for that soon :-)
So in the future the work flow would be that you upload an image of an artwork that references the right Wikidata item. The {{Artwork}} template fetches all relevant info about the work of art and you only have add the data about the photograph (own work and that you took it).
I'm slowly getting started with German collections on Wikidata. Last week I worked on the Berlinische Galerie, see d:Wikidata:WikiProject sum of all paintings/Collection/Berlinische Galerie. Looks like a nice collection, I added it to the work list on Wikidata. Multichill (talk) 19:05, 5 February 2018 (UTC)
I am switching to {{Institution}} template / Module:Institution/sandbox now. I hope that great similarity between {{Creator}} and {{Institution}} will allow me to be done with that one faster. Artwork template is the next one on the list as it relies on Creator and Institution templates. --Jarekt (talk) 19:22, 5 February 2018 (UTC)
Thanks, that sounds great. So at the moment, it would be best to do the editing at Wikidata and than just add the wikidata-identifier to the uploaded image. I am still getting started with Wikidata. So excuse the question: Is there a mask in Wikidata, which I could fill out analogous to the Artwork-Template. You see I started here with my local museum. Each object qualifies as a distinct Wikidata-item. So how can I most efficiently get all the information from the museum webpage and/or the Museum label to Wikidata? --Wuselig (talk) 13:33, 6 February 2018 (UTC)
Wuselig So for time being I would be uploading metadata to both Artwork template and Wikidata. However in the long term Wikidata upload is more important because that is where the data should (and likely will) reside eventually. As for data upload to Wikidata, two tool I could not live without are QuickStatements for data upload and wikidata Query service for reading and matching your data to the content of the wikidata. I am frequent client at d:Wikidata:Request a query asking for help with queries I have problems with. There seem to be many users eager to help. --Jarekt (talk) 16:52, 6 February 2018 (UTC)

Fall back to Wikidata for Accession number

Hi, I just enabled fallback to Wikidata if the Accession number is not set. It tries to retrieve the inventory number and, if it works, shows the inventory with the message at MediaWiki:Wm-license-artwork-id-from-wikidata which includes a link to Wikidata (example: "⧼Wm-license-artwork-id-from-wikidata⧽"). It also puts the file in Category:Artworks with accession number from Wikidata. I tested it in the sandbox including some edge cases like multiple inventory numbers and all seemed well. If this is causing problems feel free to revert or ping me to do so. Multichill (talk) 16:32, 9 September 2016 (UTC)

I love the fallback since it exists! To make the difference less obtrusive I'd like to suggest to use the small pencil icon many Wikipedias use in Infoboxes, indicating that the data comes from Wikidata and put a hyperlink to the specific property on the item on it. That could also be might for the creator templates. --Marsupium (talk) 17:05, 23 August 2017 (UTC), 09:48, 25 March 2018 (UTC)
7 months later … what about using Template:EditAtWikidata (Q27038277)/Module:EditAtWikidata (Q27061799) for Template:Artwork? --Marsupium (talk) 09:48, 25 March 2018 (UTC)

Missleading text

Hi, in the description there is the sentence: "for all other dates use {{date}} or {{other date}}". I think we should not mention the date template because (a) is not needed and (b) it is not true that date can be used for other dates. Maybe this is the reason why i found lots of wrong usages of the date template in connection with the artwork template. --Arnd (talk) 19:27, 15 March 2018 (UTC)

Fixed info on {{Date}} template. --Jarekt (talk) 19:32, 14 April 2018 (UTC)

Rewrite in Lua

I am working for a while on Lua version of this template, which would be able to work like the current table, but with Wikidata field it will be able to fetch some data from Wikidata. At the moment Module:Artwork holds stable version and Module:Artwork/sandbox holds developmental one. {{Artwork/sandbox}} calls Module:Artwork. Please help me test it by replacing {{Artwork}} with {{Artwork/sandbox}} and verifying that the page looks properly without saving. Thanks --Jarekt (talk) 04:13, 14 April 2018 (UTC)

New version is live. Please report any issues below. Please ping me in case of Lua errors. --Jarekt (talk) 12:56, 16 April 2018 (UTC)
@Jarekt: Very cool! How does the 'wikidata_cat' variable work? I just tried it with a few values (in preview mode), but couldn't seem to turn off the category for the example I added at Commons:Village pump (which is now in Category:Mona Lisa...). Thanks. Mike Peel (talk) 14:16, 16 April 2018 (UTC)
Fixed, Thanks for reporting that one. --Jarekt (talk) 14:23, 16 April 2018 (UTC)

Proposed tweaks

Thanks for the template. I'll propose here minor, as I think of them:

  • header: when no creator is given by Wikidata, do not show "unknown", leave blank (example)
  • do now show "object type" when it is "painting" or "sculpture" (it is obvious, no need to take up space and reader's time with that). --Zolo (talk) 07:59, 20 April 2018 (UTC)
I agree with the header (null is not unknown), but I don't agree with hiding "object type", that's useful metadata. If you look at museum websites, it's quite common to include it. Maybe better to move it down a bit in the template. Multichill (talk) 09:53, 20 April 2018 (UTC)
I changed Module:Artwork/sandbox to reflect the header suggestion, as for "object type" it was introduced before Wikidata and it seems like people find it useful. --Jarekt (talk) 12:22, 20 April 2018 (UTC)

Future Improvements to Module:Artwork

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

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

author field

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

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

Category:Artworks without Wikidata item and Category:Paintings without Wikidata item broken

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

Category:Artworks with Wikidata item missing image

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)

Accession numbers swallowed

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)

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

Weight

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

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)
Fixed --Jarekt (talk) 12:06, 4 May 2018 (UTC)
Thanks a lot! Bukk (talk) 12:53, 5 May 2018 (UTC)

Incorrect Item IDs

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)

The template is using redundantly the uploaded image on the box

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)

homecat

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)
Fixed --Jarekt (talk) 13:13, 14 May 2018 (UTC)

New version

Tracked in Phabricator
Task T173339

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)

Artwork namespace

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, and 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)
Hello
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)
 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)

institution's name

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

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

Help needed with moving some {{Size}} parameters to Wikidata

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

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)

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

Exporting artwork metadata to Wikidata

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 made from material (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

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.

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

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)

Source indication at file-independent usages of the template

In edits around July 7 |source={{unknown|source}} has been added by Jcb to file-independent usages of the template in categories, probably accidentally. Perhaps someone likes to remove the |source= parameter from all usages in the category namespace if you think it is safe. Otherwise perhaps someone with rollback rights likes to undo the edits. Thank you! --Marsupium (talk) 17:46, 10 August 2018 (UTC)

I Agree that "Source" field in {{Artwork}} template used in Category namespace seems wrong. I do not know why Jcb added it, and I think we should remove it. --Jarekt (talk) 20:48, 10 August 2018 (UTC)
Make sure that any action does not cause the involved files to fall back into Category:Images without source. A lot of unwanted side effects have been caused by the artwork template related edits. Jcb (talk) 18:57, 11 August 2018 (UTC)
I just undid one Category:Ceremonial axe head-AO 24799 and there were no side effects like inclusion into Category:Images without source. So I guess it is safe. --Jarekt (talk) 20:31, 11 August 2018 (UTC)
@Jarekt: You are wrong. Both files in the category are now in Category:Images without source. Please fix this. Jcb (talk) 20:55, 11 August 2018 (UTC)
Jcb, you are right, I think I understand now what the issue is. The transcluded categories had another strange side effect: Template:Object_photo should have passed the info to the Artwork template that we have the source, but there is no mechanism to do that. Adding "|strict=" works better in this case than adding "source" field, but it makes template harder to understand. --Jarekt (talk) 21:37, 11 August 2018 (UTC)

Google-specific templates

We have two artwork-based templates for images from the Google Cultural Institute: {{Google Art Project}} and {{Google Cultural Institute}}. Both were largely developped by user:Dcoetzee who, for some reason, is now banned on WIkimedia.

{{Google Cultural Institute}} is mostly a {{Artwork}}, with additional parameters 'google..' parameters that are apparently metadata imported directly from Google and are used as a fallback default when no other local data are provided. That makes Wikidata integration a bit awkward.

I don't think we need all those raw Google data here. I would say that we should replace this templates with standard {{Artwork}}. We shuold try to make it while losing as little useful data as possible (though these data should still be retrievable from Google if needed). -Zolo (talk) 10:26, 29 July 2018 (UTC)

@Zolo:  Support --Marsupium (talk) 16:17, 9 August 2018 (UTC)
From what I understand, the template was designed to store data from Google in fields that are shown only if no local data ovverides them. Without reading the Wikicode, one cannot tell whether data comme from Google or somewhere else. So I guess the purpose is to preserve Google data from some archival purposes. I am not totally convinced it is useful. Data are accessible from Google, and ultimately, the data seem to come from the museums rather than from Google's staff. Beside, these are data about the artworks and not about the image. If we want to keep them, Wikidata would seem like a better place to have them (many Google artworks already have their item).
I guess we could replace these template with template:Artwork, and keep the Google specific content in mute fields, or commented out. -Zolo (talk) 17:34, 14 August 2018 (UTC)
Best way in my eyes also is to migrate date and source to statements and references in Wikidata for that. Only it will be some work … --Marsupium (talk) 08:55, 15 August 2018 (UTC)

Implementation of horizontal depth (P5524)

The new Wikidata property horizontal depth (P5524) needs implementation here for upstream (QuickStatements upload) and downstream. Upload will be a bit tricky as type differentiation will be needed, for sculpture (Q860861) per default horizontal depth (P5524) should be used, for other types thickness (P2610) is still the main "depth property". Cheers, --Marsupium (talk) 16:26, 9 August 2018 (UTC)

I will work on that once I am back from vacations. Maybe someone want to look at sculpture items on wikidata with "thickness" property which might need to be changed to "horizontal depth". --Jarekt (talk) 20:23, 10 August 2018 (UTC)
Thank you! --Marsupium (talk) 09:02, 15 August 2018 (UTC)

Category:Pages using Artwork template with incorrect parameter

{{Editprotected}} 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)
What do you mean exactly with the last sentence? That unused parameters should be removed by a bot? Or something else? --Leyo 09:10, 25 July 2018 (UTC)
For {{Artworks}} with Wikidata field it would be preferable to add more metadata on Wikidata instead of into every file, so it can be shared among of all files showing that artwork. My preference would be to remove all the empty fields from such templates to make them less cluttered. Such change would not change the look of the template, and that is what we do with {{Creator}} templates. It is also low priority task which should be done while doing other tasks. --Jarekt (talk) 17:20, 25 July 2018 (UTC)
Either the (incorrect or all) empty parameters are removed by a bot within a short period or we need to have maintenance categories as they used to be. --Leyo 20:16, 9 August 2018 (UTC)
I think it is a good idea to search and remove incorrect empty parameters, as removal of all empty parameters might be more controversial. Maybe Commons:Bots/Work requests? --Jarekt (talk) 16:04, 28 August 2018 (UTC)

"homecat" parameter

There seems to be a "homecat" parameter. Could we document it? Is it of any use at Category:Axe preform from Denmark - MHNT PRE.2009.0.223.1? Could it get removed there? Thanks, --Marsupium (talk) 07:46, 10 September 2018 (UTC)

It is a remnant of the idea at some point to move some {{Artwork}} templates from categories (see here) to pages in "Artwork:" pseudo-namespace (see Category:Artwork templates). In such pages homecat would be used to classify the page, like we do with Creator or Institution templates. However the idea is not used at the moment and I am not sure if it ever will be. If we decide against it at some point than we should remove this parameter. --Jarekt (talk) 17:27, 10 September 2018 (UTC)
Okay, I see, thank you for your answer! --Marsupium (talk) 23:39, 11 September 2018 (UTC)

Integration with Wikidata

I am looking for ideas of better integration of content of Artwork template with Wikidata. At present, {{Artwork}} can pull and display most of relevant metadata from Wikidata, and some of metadata stored in {{Artwork}} templates on Commons can be easily uploaded to Wikidata using QuickStatements. I am thinking about ways to extending this to more files and wikidata items:

  1. At the moment we about ten files without {{Artwork}} template for one with it. We also have a lot of wikidata items not connected to any images. Are there any ways to link more files with wikidata items and vice versa. User:Multichill worked on this problem and others might as well.
  2. We still have a lot of metadata locked in Commons files which is missing on Wikidata, see Category:Artwork template maintenance "Artworks with Wikidata item missing..." much of this is not formatted properly, using {{Size}}, {{Other date}}, {{Technique}}, and other similar templates. I you are familiar with some of those collections, please help me identify patterns used so they can be bot converted to use standard templates and which allow Artwork template to construct QuickStatement commands.

Any other ideas of ways to improve integration with Wikidata? --Jarekt (talk) 18:46, 11 September 2018 (UTC)

Thank you for bringing this up! Ad 2.:
  • {{I18n/objects}} is almost ready as a valid 1:1 mapping to Wikidata, then upload can be implemented. For {{Period}} it shouldn't be too hard to make this possible as well. I'll let you know when either of them is finished.
  • I've recently spotted “early 18th century” in File:Cappelli pietra-dura.jpg … and didn't format it thinking there has to be a better automatic approach. :-) No idea, how frequent this pattern is though.
  • And a special group of objects of which anyway most aren't on Wikidata: Probably >50k Template:Artwork transclusions in Category:Portable Antiquities Scheme use size indication like “Length: 57.4mm; width: 59.2mm; thickness: 29.3mm; weight: 101.22g.” (from here) in the description field.
Cheers, --Marsupium (talk) 15:50, 12 September 2018 (UTC)
I did run bunch of bot jobs converting many strings like “early 18th century” or “Length: 57.4mm; width: 59.2mm; thickness: 29.3mm; weight: 101.22g.” to proper templates, but I only run them on files in "Artworks with Wikidata item missing..." categories and only files with Wikidata field would end up there. Maybe we should create some tracking categories for files that do not use proper internationalization in specific fields (with or without Wikidata field), but that would be tricky. --Jarekt (talk) 18:48, 12 September 2018 (UTC)

Schrödinger’s artworks

There seem to be 16,775 file pages (petscan) at the same time in Category:Artworks with Wikidata item and Category:Artworks without Wikidata item, for example File:Self-portrait with the Colosseum, by Maerten van Heemskerck.png. Where is the problem? --Marsupium (talk) 15:57, 12 September 2018 (UTC)

{{Art Photo}} causes this, as it uses two {{Artwork}} templates: one for the artwork itself, where Wikidata ID is passed if given, and another for the photograph without any Wikidata ID. It tries to suppress the category for the second, but |wikidata_cat=false doesn’t work; actually |wikidata_cat=true would hide the categorization. It looks a bit weird for me, I don’t know if Jarekt did this intentionally. —Tacsipacsi (talk) 17:46, 12 September 2018 (UTC)
Tacsipacsi, you diagnosed it perfectly. Parameter wikidata_cat was around for a while but I guess it never worked properly. I fixed Module:Artwork and File:Self-portrait with the Colosseum, by Maerten van Heemskerck.png only shows in Category:Artworks with Wikidata item. So hopefully this is Fixed. Thanks all. --Jarekt (talk) 18:39, 12 September 2018 (UTC)
Looks good. Thank you both! --Marsupium (talk) 21:43, 12 September 2018 (UTC)

Future Improvements to related to Wikidata (one section per field)

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

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

Author and Artist fields

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

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)
Multichill, another case that might fit in this „collection“ of issues: objects that belong to the collection of one institution, but are on permanent loan in another. In this case I use to (maybe wrongly) set collection = owner collection, and location = current location. In this template it renders "current location" = "collection" which is misleading. Example: Q58335721--Elya (talk) 21:38, 7 November 2018 (UTC)

Location

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

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)

Suggestion: title in original language

An artwork title usually is not translated at Wikidata – if there is no source for it. So a painting without translated title will not have a title here. It might be nice to render the original title in this case. I find it confusing if there is no title at all. Any thoughts? --Elya (talk) 17:48, 3 October 2018 (UTC)

Lua error in Module:Size at line 132: Unit name is not recognized: 1.

E. g. File:Comissao-Geologica-do-Imperio-Album1-Foto038-Getty.jpg. --Arnd (talk) 08:28, 13 October 2018 (UTC)

The size values must have units specified. Maybe it should fail nicer, but it’s an error anyway. I’ve reverted the edit adding these unitless values. (There was no source given, so I couldn’t figure out in what unit the values were given.) —Tacsipacsi (talk) 09:34, 13 October 2018 (UTC)

Current location retrieved from accession number

In File:Giuseppe cesari (le cavalier d'arpin) - portrait d'un architecte - 1591.jpg, the Louvre shown in the current location field, apparently because the painting has an accession number from the Louvre. I don't think that really makes sense. The painting is a long term loan from the Louvre to the Grenoble Museum, but the Louvre is not the "current location". Zolo (talk) 19:08, 21 October 2018 (UTC)

Perhaps we should simply break up "collection" out of "current location" field like in Wikidata? --Marsupium (talk) 23:07, 21 October 2018 (UTC)
Yes, that sounds like the cleanest solution. We should probably not show both when they have the same value though. --Zolo (talk) 09:52, 22 October 2018 (UTC)
Yes, sure! --Marsupium (talk) 14:18, 22 October 2018 (UTC)
That would be perhaps the cleanest solution. --Jarekt (talk) 17:47, 23 October 2018 (UTC)
I agree too--Oursana (talk) 22:21, 11 November 2018 (UTC)
✓ Done --Jarekt (talk) 14:21, 16 November 2018 (UTC)

place of creation

The "place of creation" entry hasn't been capitalized like all other entries. --Cold Season (talk) 13:06, 30 November 2018 (UTC)

Should be Fixed now. --Jarekt (talk) 19:02, 30 November 2018 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Template_talk:Artwork/Archiv/2018&oldid=385956433"