Wikidata talk:WikiProject Visual arts

Considering the goals[edit]

We should perhaps think about the goals or the agenda of this „task force“. There is a section overleaf to them. But I think the first one should be stated more precisely. I've in mind the following steps:

establish a structure for artwork/material artefact/object items (cf. #Determining yet existing items for the domain of the task force) – yet begun here
collect data for artwork items on Wikidata (probably mostly from Commons (especially from commons:Template:Artwork-templates) and other Wikimedia projects – requiring template mapping)
1. create items for every artwork with a commons:Template:Artwork
harmonize the data at Wikidata with those of Commons and other Wikimedia projects
– probably nothing controversial up to here –
(in remote future) fill commons:Template:Artwork or at least most of its parameters through Wikidata – requiring template mapping

advantages apart from those structured data always have: object-centered information instead of file-centered information

What is false? What else has to be done? --Marsupium (talk) 13:46, 18 October 2013 (UTC), expanded 01:28, 7 November 2013 (UTC), changed 22:53, 9 November 2013 (UTC)[reply]

Determining yet existing items[edit]

Any ideas how to safely determine if there is yet an item for an artwork during working on point 2.1. of #Considering the goals? ATM I am afraid we have to do solve the problem (half-)manually? If there is no possibility it might be the best way to identify all items for works concerned with a query like http://208.80.153.172/wdq/?q=claim[31:(CLAIM[279:838948])] (though the current use of the class work of art (Q838948) is not appropriate for this task force's scope and there is not yet an other more useful class) and to link to all of them from a commons:Template:Artwork if existing with the new Wikidata parameter and to link to the best file with image (P18) from the item. After that items for all works on Commons with a commons:Template:Artwork without Wikidata parameter could be created. And there is still another problem with those works with more than one file on commons. However, it should be possible to determine them automatically? --Marsupium (talk) 01:28, 7 November 2013 (UTC), slightly changed 14:03, 8 November 2013 (UTC)[reply]

I do not think there is any reliable way to find the Wikidata item for all files on Commons. I guess we should add the "wikidata" parameter to as many files as possible. A bot can certainly help (based on various things, for instance I have tired to add Joconde work ID (P347) to all Wikidata items for which it is available, and I think it should be reliable). But still, all that will certainly require a lot of manual work. --Zolo (talk) 08:28, 7 November 2013 (UTC)[reply]

D'accord, dommage! Joconde work ID (P347) is inverse functional (Property talk:P347 says so). We should collect all other inverse functional properties for that purpose! At least inventory number (P217) should be inverse functional used the way with the properties we agreed on. --Marsupium (talk) 14:03, 8 November 2013 (UTC)[reply]

Ok, good to know the technical name. It should be roughly equivalent to properties with a {{Constraint:Unique value}} on their talk page. --Zolo (talk) 17:08, 13 November 2013 (UTC)[reply]

Proposal for the task force's page structure[edit]

I propose to move all template and other mapping pages yet existing to Wikidata:Artwork task force/Mappings/… subpages. This task force seems to be a better place for them than the template subpages at Commons. I talk about:

You may simply move the pages, if you consent. --Marsupium (talk) 14:26, 15 November 2013 (UTC)[reply]

Support, except that if everything in commons:Template:I18n/objects/wikidata has been copied to User:Marsupium/Artworks task force item trees, I think we can simplu delete it.--Zolo (talk) 15:05, 15 November 2013 (UTC)[reply]

I have moved User:Marsupium/Artworks task force item trees as a start. I am not that experienced in cross-project moving. As you have written most of the other documents you can just copy them without a copyright violation. For commons:Template:I18n/objects/wikidata you are the only editor, for commons:Template:Technique/wikidata you can simply copy my edits and Oursanas edit shouldn't be a problem, too. And yes, it should be possible to merge commons:Template:I18n/objects/wikidata into Wikidata:Artwork task force/Mappings/AAT Objects Facet. We will have to work it in further somewhen. BTW: Would you mind to move Wikidata talk:Artworks task force/Item structure#Root item to this page? --Marsupium (talk) 16:03, 15 November 2013 (UTC)[reply]

Administrators can import pages with their history :). I have done that for technique at Wikidata:WikiProject Visual arts/Commons mappings/Technique. Wikidata is CC0 while other projects have more restrictive licenses, and that can be a problem if we want to import long texts, but I don't think it really matters for simple data like this. --Zolo (talk) 07:38, 23 November 2013 (UTC)[reply]

Ping test[edit]

Notified participants of WikiProject Visual arts. Just wondering, did anyone receive a "you have been mentioned" notification for this talk page ? --Zolo (talk) 08:51, 8 December 2013 (UTC)[reply]

No idea what you are doing, but yes, I've got a notification: Zolo mentioned you on WikiProject Visual arts talk page in "Ping test". --Marsupium (talk) 10:24, 8 December 2013 (UTC)[reply]

I was thinking that sometimes, there are discussion about a topic related to a project like a discussion about artworks on the Project Chat - and perhaps it would be nice to have a way to automatically notify participants to the project (apart from the incongruous bullet points) ? --Zolo (talk) 18:58, 8 December 2013 (UTC)[reply]

YEs, I received one ping! :)--Kippelboy (talk) 06:25, 10 December 2013 (UTC)[reply]

I just got it now. Jane023 (talk) 08:43, 13 December 2013 (UTC)[reply]

"Showcase items"[edit]

We seem to need a showcase item for artworks. I first thought of Mona Lisa, but it is a bit complicated, then of the Girl with a Pearl Earring but I wonder what went through my head given that the proble are almost exactly the same (partially unknown history, date and identity of the model disputed, various wild speculations about it). Any idea. I think it should be a well known item with a relatively simple topic and a well documented and relatively simple history. An artist dead before 1943 would be a plus so that we do not have anu problem with image copyright. --Zolo (talk) 08:57, 8 December 2013 (UTC)[reply]

Let's take one of those artworks listed at en:Wikipedia:WikiProject Visual arts#Featured articles. So we can start with a good documentation understandable and accessible to most of us. The Battle of Alexander at Issus (Q241455) might be suitable. It has the advantage that I dealt with it some time ago, so I can supply the relevant literature if necessary. Regards, --Marsupium (talk) 13:01, 6 January 2014 (UTC)[reply]

The Battle of Alexander at Issus (Q241455) is nice if you can expand it :). I was thinking of proposing Guennol Lioness (Q1553211) but I have some issues with it:

Material used: the source says "either limestone or magnetite" (not both), and we have not yet settled on a standard way to express that.
Date, the source says: 3000/2800 BC, but this can't be entered through the UI (I think it can through the API)
depicts (P180): how do I say lioness with a male human torso ?--Zolo (talk) 15:58, 1 May 2014 (UTC)[reply]

Rijksmuseum[edit]

http://ultimategerardm.blogspot.nl/2014/04/wikidata-and-naval-history.html … that shouldn't be a problem, hein? The Rijksstudio is anyhow an amazing database published under CC-0, with high-res images and more than 75,000 works with Iconclass tags. I am considering to use it as a starting point for the more expansive description of image content. It might even be a good first example for importing content directly from a museum's page by bot. What do you think? --Marsupium (talk) 14:42, 13 April 2014 (UTC)[reply]

That sounds great. It seems that much of the database could be mapped onto Wikidata.

How should we proceed with Iconclass ? The most obvious solution would be to try to map Iconclass to Wikidata items through an "Iconclass ID" property, and then use the Iconclass value from the Rijksstudio to add depicts (P180) values in Wikidata. But sometimes we will want to change the p180 value for something more specific that do not have any Iconclass equivalent. In the process the simple 1 to 1 mapping between Wikidata p180 and the Rijksmuseum's Iconclass will be broken. And, if our subclass-tree is not perfect (which sounds likely for quite a while) it may not be possible to know the Iconclass on an artwork based on just its depicts (P180). Do we want to be able to know the Iconclass of an artwork using only Wikidata ? If so I think we would need two properties, for instance:

milkmaid (Q1934482): Iconclass ID: 47I22311
The Milkmaid (Q167605): depicts Iconclass ID 47I22311.

--Zolo (talk) 19:09, 13 April 2014 (UTC)[reply]

Good idea(s)! Let's implement the double property structure just as you proposed. I had yet thought about a double structure which will partially be redundant when I made the post above. The way you proposed it is the best I can think of. The Iconclass IDs from Rijksstudio can simply be imported by bot and will become more useful when we will have a way to filter strings with regex through SPARQL or whatever. Transforming the information to our own system that will be hopefully somewhen better than the current Iconclass is neither trivial nor will we be able to do it in the short run I guess, so using Iconclass and our own system at once looks like the best way to me. Getting the data shouldn't be a big issue: https://www.rijksmuseum.nl/en/api … Shonagon might know more how about importing the data here? A task to manage will be the matching so that we avoid to create duplicate items though the wikidataquery queries collection (P195):Rijksmuseum (Q190804) and inventory number (P217):XXXXX, qualifier: collection (P195):Rijksmuseum (Q190804) (is that already possible with WDQ; unfortunately WDQ does not load for me ATM) could make the matching simple. I hope this page was OK for posting the mixed content post, parts of it should have gone to the item structure talk, but we well have to do some better documentation of everything we have yet discussed somewhen soon anyway I guess. If there is somebody who gets confused, please complain now! --Marsupium (talk) 03:48, 15 April 2014 (UTC)[reply]

For the record: Zolo proposed the two properties addressed above: Iconclass ID, and depicts Iconclass. --Marsupium (talk) 11:55, 18 April 2014 (UTC)[reply]

They have been created by user:Jakec (Iconclass notation (P1256) and depicts Iconclass notation (P1257)), but I just realised that we had an issue with this particular example. The Rijksmuseum says that it depicts Iconclass 47I22311, with en label: "milkmaid" (de: "Milchmädchen", fr: "vachère, trayeuse"), but it does not give any definition of the word. Most images [1] seem to match en:Milkmaid (girl who milks cows), but there is no definitive sign that it is the case for Vermeer's milkmaid (actually Wikipedia suggests that she is a "kitchen maid"). It seems that we have three solutions:

find a more detailed scholarly article showing that Vermeer's maid acutally milks cow (unlikely, I would guess :])
decide that the Rijksmuseum has made an erroneous tagging. In that case, I imagine that we should put "depicts Iconclass 47I22311, rank: depcrecated, source: Rijksmuseum" in Wikidata and ideally elaborate a error reporting system to discuss that with the museum.
decide that the Rijksmuseum is right, but uses a broader (or just different) definition of milkmaid than Wikipedia. The issue is that Iconclass does not provide any explicit definition, making this point of view appears difficult to either vindicate or rule out. I noticed the hierachy: milking -> transportation of milk -> milking. But I do not quite know what to make of it (nor of the seeming type mismatch, with a person (milkmaid) placed below an action (transportation of milk)). -Zolo (talk)

This kind type mismatch is pretty common, I usually create an item for a profession and for the action the professional does. This mismatch even exists in the properties, there is field of this occupation (P425), field of work (P101), occupation (P106) and maybe I miss some. I'm not sure I understand why we have 3 properties, TomT0m ^(talk) 22:29, 24 April 2014 (UTC)[reply]

A milkmaid in art historical terms does more than milk the cow. She also walks gracefully with a yoke holding two pails of milk, and it is this activity which gives her the burly arms and muscular upper body torso that Vermeer's milkmaid has. The fact that she is pouring milk suggests that she is the one who just brought it in fresh from the cow. You don't need to be an expert to figure that out. Jane023 (talk) 16:53, 26 April 2014 (UTC)[reply]

It does not seem self-evident from the image that she is a milkmaid in the Wikipedia milk-the-cow sense (as noted here or [2] that say that she is "not specifically a milkmaid". If there is an accepted broader meaning in Art History, I think it should be a separate item.

Physical Object Class Identification Problems[edit]

I just created Wikidata:WikiProject Visual arts/Physical Object Class Identification Problems to establish a place to solve problems within the physical objects class tree. Up to now I sometimes tried to solve those problems myself and sometimes I simply let them unsolved. I hope we will cope with them this way. Any help is welcome. Thanks, --Marsupium (talk) 15:08, 21 April 2014 (UTC)[reply]

Works after[edit]

I do not remember if that is already been discussed. How should we say that Mary Magdalene (Q17320091) is a copy of a work by Guido Reni. Mary Magdalene (Q17320091)creator (P170)Guido Reni (Q109061)applies to part (P518)original ? One issue with this approach would be that the paintins would be listed by default in a list of paintings by Reni (I assume that default list = list not taking qualifiers into account). --Zolo (talk) 17:08, 9 July 2014 (UTC)[reply]

This is part of the problem addressed here, though no solution yet. --Marsupium (talk) 13:18, 19 July 2014 (UTC)[reply]

Wikidata:WikiProject sum of all paintings[edit]

Starting a new project. Let's get all paintings on Wikidata! I could use some help. I already imported 4 museums in the Netherlands. Multichill (talk) 11:32, 8 August 2014 (UTC)[reply]

Yes, we should do this for all of the museums in the UK that are already listed on the Your paintings website. If we do the National Portrait gallery of London we will probably discover that we have a lot of those paintings already because the paintings were in one of the very first mass upload projects. Jane023 (talk) 05:35, 9 August 2014 (UTC)[reply]

Editions/copies[edit]

I'm looking at mapping some of the sculpture objects on svwiki to wikidata using the item structure described here. What I quickly noted though is that it isn't uncommon with various editions of the same sculpture. Often in different materials, sizes etc. The Wikipedia article normally talks about them in general so the structure that I'm seeing is a wikidata object about the artwork in general and then sub-objects about the various editions.

My question is whether this has already been considered within this WikiProject. If it hasn't would a has edition or translation (P747)/edition or translation of (P629) combination serve that need? The English description of P629 hints at it only being designed with text in consideration. /Lokal Profil (talk) 12:14, 15 August 2014 (UTC)[reply]

I am not so sure. I think you should make one item (pick one or make a neutral one) to become the iconic one (and it may have an iconclass code?), and then each edition could be an instance of that one. I am thinking of the Lacoon statue with raised arm vs lowered arm. Jane023 (talk) 14:18, 4 September 2014 (UTC)[reply]

Recreating exhibitions through Wikidata[edit]

We now have arbitrary access to data on Wikidata. This may actually be a much more important condition to generate automatic list than the existence of a built-in query namespace (for the list of items, we just need a copy-paste from Wikidataquery) So what about starting experimenting with it ? I have had a try at recreating the 1808 Salon at Talk:Q15273842, with the works sorted by catalogue number (well ok, most works are still missing). --Zolo (talk) 22:59, 2 September 2014 (UTC)[reply]

very cool - this is exactly what I want to do on Wikipedia. I am working on the last definitive Seymour Slive catalog on Frans Hals from 1974. Slive died of cancer this summer and was laying his hand on the proofs of his update, which is not out yet. When I am done I will have completed c:Frans Hals catalog raisonné, 1974. Jane023 (talk) 11:45, 3 September 2014 (UTC)[reply]

Hmm I made Talk:Q17616737 but it doesn't list the items as numbered values. Jane023 (talk) 12:31, 3 September 2014 (UTC)[reply]

That works now (good list !). The first function was designed for exhibition catalogue numbers, it had to be adapted for artist's catalogue numbers that are stored in catalog code (P528) rather than as qualifiers of exhibition history (P608) (well we could probably also add exhibition catalogue numbers in catalog code (P528) so that we need only one template. --Zolo (talk) 14:29, 3 September 2014 (UTC)[reply]

Thanks! When I am done I could do an exhibition catalog using many of the same items, such as c:Frans Hals Exhibition catalog, 1989. I was going to use the catalog code for this too. Jane023 (talk) 17:43, 3 September 2014 (UTC)[reply]

Pretty cool Zolo, maybe your next project can be to make a local version of Commons:Template:Artwork that grabs data from the Wikidata item? Take for example this image, it already has a link to Portrait of Philip the Good, Duke of Burgundy (Q17334940).

Would be great to give people an idea what is ahead of us and we can already play around with it to see if it fits or needs improvements. Multichill (talk) 10:57, 4 September 2014 (UTC)[reply]

That usage is problematic. If there is a general wikidata link in the artwork template, it should link to a wikidata item about that specific artwork SK-A-3835, not to the wikidata item about the subject of the artwork Philips de Goede, hertog van Bourgondië. This comes back to the suggestion here: c:Commons talk:Wikidata for media info#Missing properties where it is stated that we need a "depicts" property in the Commons artwork template. Jane023 (talk) 14:57, 4 September 2014 (UTC)[reply]

User talk:Jane023 look again please, the file doesn't link to Philip III the Good (Q239337), it only links to Portrait of Philip the Good, Duke of Burgundy (Q17334940) (I added that link myself). Multichill (talk) 17:10, 4 September 2014 (UTC)[reply]

Ok got it. It would be nice if these could be bot-created from items which are instances of "painting". Jane023 (talk) 22:34, 4 September 2014 (UTC)[reply]

@Multichill:. See thread below. --Zolo (talk) 18:06, 6 September 2014 (UTC)[reply]

Template:Artwork[edit]

Template:Artwork aims to provide a description and could be an alternative to the current template on Commons. This is still rough and buggy, but just to get the idea, you can see Template:Artwork/testcases (you can also add other artworks there, especially "unusual" ones, as I use the page for developping the template.

A few points:

I would favor something less obtrusive than Common's blue box with named headers (the image should be more eye cathing then the text :). the artist / title / date layout is pretty standard and imo self explaining.
I have added links to user:Shonagon's Crotos. I think this is pretty nice but in a wide-usage template, it would probably need to be replaced by some internal stuff (hopefully, Wikidata will allow to finally get a decent gallery namespace on Commons.
The formatting/i18n of titles is inadequate, but I will wait until we have a new monolingual-text type property rather than the current string-type one (the datatype is available, so that should be soon).
I have distinguished between "main topic" and "other depicted things" using depicts (P180), rank = normal and P180 rank = valid. Another solution would be to use main subject (P921), but I do not think it would a good idea.
when there are two creators given, there is no way to know if the attribution is disputed or if there are several creators. --Zolo (talk) 18:06, 6 September 2014 (UTC)[reply]

That's quick Zolo! I really like the fact that we can make mock ups here now!

I don't really get the i18n part. Why do we need the monolingual-text? Can you explain a bit more? I do see you have hardcoded messages in Module:Artwork. That doesn't seem to be right. I also see a "type d'affirmation inconnu." on Portrait of Philip the Good, Duke of Burgundy (Q17334940). Why is this in French while I currently don't have my interface set to French?

I added some paintings based on their page size. These seem to include a lot of claims and sitelinks. Multichill (talk) 11:11, 7 September 2014 (UTC)[reply]

@Multichill:

To get the title, the module uses P357 (P357) with a fallback on the label. A simpler solution would be to use only the label, but that is somewhat less powerful. For example, in Talk:Q17616737 we may want to use the title given in the catalogue, but we cannot know that through labels alone. The only difference between a mono-lingual and a string property is that the former stores the language the mainsnak rather than as a qualifier. This is fairly minor but that makes it easier to retrieve.

Much of the internationalization is done through data themselves but there are cases where it seems that we need something else (hard to get "no catalogue number" or even "artwork history" from the data). I used a i18n table at the beginning of the page but it can go to somewhere else, or even to translatewiki if needed. For "oil on canvas", "on" is in a function, but that is because the line about the medium is currently a placeholder of sorts. It may well need to be expanded into a module of its own. The messages in French are because I imported Module:Wikidata from fr.wikipedia, and I have not yet (back) translated all comments/messages. Actually, considering that error messages should usually not be shown to the end-user, I do not know if we really need to make them multilingual or if English is enough.

Just a note: with the current testcases, around 2/3 of the loading time it is due to the "depicted topics" section (it has to load every item in order to retrieve the label. Using mw.wikibase.label seems to make it faster, but it only works for English). --Zolo (talk) 15:59, 7 September 2014 (UTC)[reply]

Very impressive!

But can I suggest that it would be good to separate out the new skin/new look issue from the issue of drop-in replacement functionality. So can I suggest moving the template to something like Template:Artwork (new concept) or some such, and using Template:Artwork to show just how close a like-for-like replacement can appear to what currently exists.

In particular, note that there is often a lot of information in current instances of the Commons template that may not be on Wikidate, or may not be so easily migrated -- eg all manner of individualised source templates; or various amounts of free text from different fields on the original sites, concatenated in different ways, sometimes by original uploaders who may no longer be around.

So while it's an excellent thing to explore new concepts of how one might present the information, there is also a basic need to be able to replicate something very close to what we already have, and Commons users are familiar with, that allows granular mixing and matching at a field level between fields drawn automatically from Wikidata and unmigrated fields carried forward from the existing information. Jheald (talk) 13:25, 7 September 2014 (UTC)[reply]

+1 on that. Multichill (talk) 15:50, 7 September 2014 (UTC)[reply]

@Jheald: what is missing here compared to the Commons template is information about the file itself (that is essentially the source and permission parameters, and sometimes the description parameter). But I think it will be all round clearer if we separate information about the artwork from information about the file in the description.

If there is a need to make this template more like Common's it can be done pretty easily, as both really show the same kind of information. I have not yet included accession numbers and inscriptions, but it will be done. After that, we just need to wrap them in a blue table.

As for mixing local information from Commons with Wikidata-retrieved data, it seems that it will indeed be needed. I guess that if this template is exported to Commons, we should give the ability to override Wikidata through free text parameters. But I am not clear yet on how the Wikidata/Commons interaction will work in practice. --Zolo (talk) 15:59, 7 September 2014 (UTC)[reply]

Nobody knows yet how the Wikidata/Commons interaction will work in practice -- which is one reason why something concrete and realised like this is so very very helpful and useful!

But there are a couple of reasons why I think it's absolutely right that, as you say, we're going to need the ability to override Wikidata through free text parameters, and probably need that override ability separately for each separate field.

My take is maybe coming from a slightly different place, because the uploads that I have been typically using the Commons Artwork template for have not been old master paintings, but rather scanned single images from books -- either from manuscripts, like eg File:St. Matthew - Lindisfarne Gospels (710-721), f.25v - BL Cotton MS Nero D IV.jpg, or from books with engravings and/or illustrations, like eg File:Neale(1818) p1.052 - Luton Hoo, Bedfordshire.jpg.

I think there are at least two issues here:

First, (which I've now cut to a separate talk-page section below), can we necessarily assume that the 'underlying work' of such a scan will necessarily have an item on Wikidata at all? Will some of the information that you're pulling into your template from Wikidata (eg original artist name, creation date, etc) sometimes instead have to be provided from CommonsData, or from free wikitext fields, simply because there will not be any appropriate entry on Wikidata to store it?
Secondly, I do think you're right that it's nice to separate (at least conceptually) information about the original from information about the scan. (And in practice there may often be more levels than this, because the 'original' may have its own original -- see second new section below).

But for the present some of that can be quite scrambled up in artwork templates (at least as I have been using (or misusing) them). So for instance both the Lindisfarne image and the engraving have quite catch-all "Source" fields, pulled from the original data which might not be so easily accessible again. Both contain, in particular, institutional credit/linkback templates (often quite appreciated by GLAMs), containing a variety of different linkbacks, which might relate variously to the work, the edition, the copy or the original scan, all pulled together into one place. (The main BL template I think now in fact supports eight or nine different types of linkback, to various different catalogues and sources, sometimes up to 4 or 5 per image, with still more it could be extended to cover). So -- particularly with pages using such source templates -- it may not be quite so simple to make such a clean separation between work and scan.

Also, I suspect that some description content may remain in legacy free-wikitext templates for good -- for example the kind of per-image detail and specificity often loaded into {{:c:Infobox aircraft image}}, as at eg File:AT-6C Harvard IIA NZ1056.jpg, which may never be migrated into a structured format.

These are the sort of issues that it seems to me that any new super Artwork/Information template for Commons that can draw on Wikidata (of which you've just created a fantastic prototype) is going to have to grapple with. But it may not be too hard to achieve if whatever is created is sufficiently modular, with it possible to over-ride as many or as few fields as desired with information supplied not drawn from WD but supplied locally. (Though if not overridden all fields should certainly draw everything they can from WD).

I suspect, from what you've written above, that these are already the lines you are thinking along. I presume that means using something very close to the existing Artwork template as a top-level shell, in such a way that if fields are explicitly present, they will be displayed; but if not they can default to being drawn from Wikidata. (It would also be nice to have a button on each field to be able to toggle between the two; but perhaps that's for another day. Another thing that needs consideration is vandal-fighting, and how (or when) to expose information drawn from Wikidata so that vandal-fighters' tools can see it. But that again is perhaps for another day.)

Sorry, rather a long post. But I guess that's the curse, @Zolo:, of your having done such a beautiful concrete and discussable prototype piece of work! Jheald (talk) 22:57, 7 September 2014 (UTC); re-worked 10:22, 8 September 2014 (UTC)[reply]

I have made a new version at Template:Commons artwork, curretnly tested at user:Zolo/test. The file-related parts of the template is shown at the beginning of the page in a concise, MediaViewer style (of course the layout can change.- I am not sure this one would work very well for long, template-intensive pages). Apart from that, it really works like template:Artwork with a fallback on Wikidata. All Wikidata-fields can be overriden by local data. I will probably add the possibility to mute a field like "|date = ~", if we want neither local data nor those of Wikidata. The fields are similar to those of Commons:Template:Art photo, that is like template:Artwork, but with added parameters for photo description and photo date. There are just two fields missing: "dimensions" (the necessary datatype is still missing), and "other versions" (not too convenient to develop outside Commons). You can add |description = to add a description of the artwork, but it does not retrieve the description stored in the Wikidata item (most Wikidata description are things like "painting by Rubens", which are essentially useless). --Zolo (talk) 13:56, 8 September 2014 (UTC)[reply]

Wikidata:Notability and artwork[edit]

(Refactored out of previously very long comment immediately above)

What are the criteria for works to pass Wikidata:Notability and have their own entry?
Which artworks -- individual paintings, engravings, illustrations, manuscript illuminations, maps, photographs, old postcards etc etc -- should each have a separate Wikidata item of their own?

It's a key thing that I think the community needs to come up with a sharper answer on, particularly as Commons starts to think its way towards c:Commons:Structured data.

Looking at some of the initial thoughts from the structured data team, there seems to be a key assumption:

that, for any image that contains information relating to something beyond the immediate photograph or scan, there will be some kind of 'original work' item that the page will be able to reference on main Wikidata, that will be able to act as a place to locate that information.

Sometimes this information may be spread over more than one item. So for example, the books project has an item for a particular edition, as well as an item for the title work as a whole. One of the clearest presentations about what information might be stored on different items at different levels is from the historical maps project [3], running to four levels in all, with only information relating to the particular scanning of the map and its upload living on CommonsData, and information at all other levels living on Wikidata, including an separate item for each map sheet (containing amongst other things the coordinates of its bounding box).

But how realistic is that assumption of there necessarily being an 'original work' item for each sheet / design / individual portion of the work?

For maps I actually raised this a couple of days ago on the Commons historical maps mailing list [4], but the same goes for much more general images:

The Lindisfarne gospels are notable, of course. But should the specific illumination of St Matthew have its own item? Is every manuscript illumination from every manuscript separately notable for a main Wikidata item in its own right?
What about every map, or every engraving? Is the Luton Hoo engraving, from a series of 400 engravings, notable for a Wikidata item in its own right? What about different states of engravings, where they have been re-issued with subtle changes? What about each map in eg c:Category:England_Delineated_(1800)_by_John_Aikin - a set of fairly simple sketch maps of English counties, published in a schoolbook in 1790. Do they each get a separate Wikidata item? What about different sheets, when a map has been split over several sheets, that have been individually scanned, eg https://www.flickr.com/photos/britishlibrary/tags/sysnum000307469 ; or the map of London over pages 8 to 26 of c:Category:District_Railway_Guide_to_London_(1888). At the moment the maps schema is assuming that each map's geographical bounding box, being a property of the original work, is attached to an item on Wikidata. But does that mean each page needs its own separate Wikidata item?

We can go on. Engravings and maps may be individually collectable. But what about even simpler line illustrations in books? Do they also have properties that need to be individually held each on yet another item on Wikidata? Or old photographs, or old postcards? Does everything with a creator and a creation date and the possibility of multiple scanned copies get an item on Wikidata?

Now I'm not saying they necessarily shouldn't; but with a million CC0 old scanned images from the British Library already on Flickr; 14 million promised from the Internet Archive; a full hard drive from the Welcome Foundation on its way to the servers even as we spear; the Smithsonian and the Library of Congress proposing to release everything, etc, etc, we need to start thinking where lines are going to be drawn. Will everything have its 'work' details stored on Wikidata? Will some items have their work details stored on CommonsData instead?

I meant to ask this question on the wikidata-l list in a couple of days, but I think it would be useful to have people's initial thoughts here first -- this is the kind of thing that this project should be shaping the discussion about. Jheald (talk) 22:57, 7 September 2014 (UTC); reworked 11:38, 8 September 2014 (UTC)[reply]

I would tend to have a rather "inclusionist" view on what is item-worthy. Especially, I would say that anything with a separate accession number or museum-database entry is acceptable, even if it's just the nth copy of some obscure engraving. That makes data exchange easier. That said there may be cases where we do not want to create too specific items. If so, we can still provide information directly in the file description.--Zolo (talk) 10:06, 9 September 2014 (UTC)[reply]

And I would go even further and claim that works in private collections that are mentioned in catalog raisonnés of notable artists are equally notable because they were mentioned in notable art history books. There are many more notable artworks in private hands than in public collections. Jane023 (talk) 16:22, 18 September 2014 (UTC)[reply]

Yes, that sounds wise. Though, we should probably set a limit to ensure the usefulness of the data. I think that it can be useful to have items for all physical instances of all woodcut and engraving sheets of Dürer and also less important artists. However, these data if not very deliberately added are surely not useful at the current state at least. In 2024 it might be useful to have items for all these physical representations. But I think that it is attached to some conditions:

The data has to be detailed: E.g. an item for this single woodcut sheet instance of The Four Horsemen of the Apocalypse, a "brilliant Meder b proof impression" is not useful without precise data for the provenance which might even not be available anywhere.
Some level of completeness should be required: I do not think that it is useful to create items for single physical sheets before having set up items for the bulk of the print work groups.

Proposing these rules I have in mind the preservation of an expressive data retrieval. There a yet other databases simply collect everything they get like Europeana which often leads to query results of low interest. --Marsupium (talk) 02:45, 21 September 2014 (UTC)[reply]

Engravings: how to record artists, engravers, publishers etc ?[edit]

BTW: what is the recommended approach for recording the artist, engraver and publisher of an engraving? Jheald (talk) 11:55, 8 September 2014 (UTC)[reply]

I think that when an work is intimately linked to another, we should have an item for both, an show information about both items. For manuscript folios, that could be something like 'if part of (P361) then show information about item + information about the item in p361". For engravings after a work, that could be based on (P144), or maybe that property is a bit too vague and we should create a new one.

For engravings, I think we can have only show the engraver on the item about the engraving, as the original artist should be provided in another item. But too make things more explicit, we can add applies to part (P518) engraving process (Q139106). --Zolo (talk) 10:11, 9 September 2014 (UTC)[reply]

@Zolo: Probably better not to assume that a WD item for the original sketch / drawing / watercolour necessarily exists. In many cases all that may be known about any original is the words "<Artist> pinxit (or del[ineat]), <Engraver> sculpsit" printed at the bottom of the engraving -- ie the Artist who painted or drew the original, and the Engraver who engraved it. (There will very usually also be the publisher and place of publication; or very occasionally a credit for someone who 'directed' the work, but didn't either draw it or engrave it.) Any original drawing or watercolour might have survived; but more often probably won't have.

So it's probably an idea to have an 'artist' property, for such an engraving, but that can be over-ridden if the work itself has survived. Occasionally the lost work might be worth an item in its own right (like the lost Holbein?); but more often probably not, unless there is further information that we would like to independently record about it in its own right. Jheald (talk) 11:34, 9 September 2014 (UTC)[reply]

If we do not have an item for the original work, we can still use applies to part (P518) engraving process (Q139106) for the engraver, and do something similar for the artist of the original work, diretly in the engraving item. I am not sure which item it should use but that would be something like:

Artist:
- WW (drawing)
- XX (engraving)

--Zolo (talk) 12:58, 9 September 2014 (UTC)[reply]

That's along the right lines I think, but I'm not sure that applies to part (P518) is the right qualifier to use -- IMO we should reserve that for where one physical part of the image (eg the modelling of a head; part of a collage; etc) is by a particular artist. Where all of the work is an engraving derived from another work or another artist, a different qualification is desirable I think. (One might want to apply both -- part of the engraving is by X after W; another part is after Z).

But I do think we need to establish our preferred modelling, to publish a reference data model for engravings/etchings/lithographs/aquatints etc. Jheald (talk) 23:50, 12 September 2014 (UTC)[reply]

I consent to the reservation of applies to part (P518) to physical parts of objects. Categories for the Description of Works of Art (Q5051819) proposes a role property with entities of the AAT Agents facet in the range of the property ("populated with terminology from the Agents facet of the AAT"). We could realise this as a property for qualifiers to creator (P170)-statements here at WD … --Marsupium (talk) 03:38, 21 September 2014 (UTC)[reply]

More examples of multi-levels of creators and dates[edit]

Additional to the examples from the maps project and the books project above, some further examples where a chain of derivative works makes it hard to define a single definitive 'original work' or 'underlying date' for a file,

An 1807 aquatint by Reeve after a 1793 Turner watercolour (one could also imagine a subsequent engraving of the aquatint).
1892 book engraving after 1255 manuscript folio
1869 book re-engraving of an 1824 engraving of a lost 16th century portrait by Holbein (or perhaps his school), destroyed in a fire in 1845.

More no doubt could be added. (And it would be useful to do so). How do we propose to reflect these in any renewed Artwork template? And/or in what we store to let end-users search by? Jheald (talk) 11:53, 8 September 2014 (UTC)[reply]

These cases can be simply modelled through two items (three for the Holbein example) of which the later is (are) connected to the former using based on (P144). Or is there a problem with that? --Marsupium (talk) 03:38, 21 September 2014 (UTC)[reply]

@Marsupium: Thanks. I guess the issues that arise are (i) making sure that the items do exist; (ii) making sure that the search software that gets created for c:Commons:Structured data knows how to follow (and cache) such a chain -- so that a search for Holbein includes either an option or grouped results for works after Holbein. But yes, it's really a question of making sure that they know that based on (P144) exists, and to be confident that it can be dealt with it appropriately. Jheald (talk) 07:11, 21 September 2014 (UTC)[reply]

OK. I guess that shouldn't be a difficult problem. I think it should yet be possible to create the necessary items and to write and test a based on (P144) following code with {{Artwork}} (thx a lot, Zolo!) … --Marsupium (talk) 11:03, 21 September 2014 (UTC)[reply]

Engravings reproduced more than once (should CommonsData property "Underlying work" accept multiple targets?)[edit]

A related, separate problem: if a scan on Commons is to have to relate to a work on Wikidata, one might want to identify a scan of an engraving both with a particular edition of a book (that might contain many engravings); and as an image of a particular engraving (which might have appeared in many books). Whatever structure is adopted will have to be flexible enough to cope with this. Jheald (talk) 23:53, 20 September 2014 (UTC)[reply]

I'm not sure if I really got your point. Could you provide a concrete example or is the following fitting?: Of some illustrated printed bible exist still some dozen exemplars. One of these exemplars is in the collection of the British Library. And Commons has a scan of the illustration of Noah and the animals boarding the ark in the exemplar of the British Library. I'm not sure you considered such a case. But if so we could have two items like this:

⟨ printed bible XYZ ⟩ creator (P170) ⟨ John Doe ⟩
,
⟨ subject ⟩ image (P18) ⟨ File:British_Library_codex_8987_p.65_Noah_and_the_animals_boarding_the_ark.jpg ⟩
page(s) (P304) ⟨ "65" ⟩
⟨ British Library codex 8987 ⟩ instance of (P31) ⟨ printed bible XYZ ⟩
,
⟨ subject ⟩ collection (P195) ⟨ British Library (Q23308)    ⟩
,
⟨ subject ⟩ image (P18) ⟨ File:British_Library_codex_8987_p.65_Noah_and_the_animals_boarding_the_ark.jpg ⟩
page(s) (P304) ⟨ "65" ⟩

In this case I think those two could be enough, but depending on what you want to express an additional item for the special illustration could become necessary. Did you think about such a case? --Marsupium (talk) 03:38, 21 September 2014 (UTC)[reply]

@Marsupium: Thanks. image (P18) is not what we're looking for here, because that is really for a single key image to be associated with a work, rather than for all images associated with it. (That is my understanding of image (P18), anyway).

To be clearer about what I'm asking about: maybe I'm getting ahead of things here, but really I am trying to think forward to how things are going to be set up with the c:Commons:Structured data project.

As I understand it, what is envisaged is that the new "CommonsData" wikibase will not directly hold information about a work that a picture or scan is of, but in such cases will have a property "Underlying work" that will point to an item on WikiData that the work is of. The Wikidata item will be used to hold information such as the date and authorship of the underlying work. (Which in certain circumstances may be relevant as the copyright date; particularly if different rights associate to different aspects of the work -- eg the copyright of a sculpture, the copyright of the photograph of it, etc)

So eg for the two images c:File:Neale(1818) p6.190 - Fleurs, Roxburghshire.jpg and its reprinting in another book File:MA(1829) p.340 - Fleurs - John Preston Neale.jpg, to move information as much as possible off the file page and into a structured system, I guess such images will each need two "underlying work" items, with appropriate qualifiers; so for the second image the structure could look like:

(File) -> Underlying work: Wikidata item for Book edition; qualifier volume (P478): vv; qualifier page(s) (P304): nnn; qualifier - relationship: published in
- Book edition (schema) -> edition or translation of (P629): Shepherd's Modern Athens; publication date (P577) 1829
  - Book work: Shepherd's Modern Athens (schema)
(File) -> Underlying work: Wikidata item for Engraving of Floors Castle from Neale's Country Seats
- Engraving of Floors Castle from Neale's Country Seats (schema) -> part of (P361) Neale's Country Seats; creator (P170) J.C.Varrall (qualifier - role: engraver); creator (P170) John Preston Neale (qualifier - role: original drawing); inception (P571) 1818
  - Book work: Neale's Country Seats

The challenge will then be how to adapt the {{Artwork}} template to present such a chain sanely (and then how it should be summarised into one line for MediaViewer (!), or presented in a way for an uploader to fill in at UploadWizard) -- what to show, and what to suppress (or to draw on only as a fallback, if other information hasn't already been presented). Jheald (talk) 08:18, 21 September 2014 (UTC)[reply]

OK, thanks, that's the problem! I think here too the best way will be to create the items first and to tinker about an algorithm within {{Artwork}} providing the information needed? For now I could imagine that it will be a cleaner solution not to give more than one value for the "underlying work" property, but to retrieve the information from Wikidata. --Marsupium (talk) 11:03, 21 September 2014 (UTC)[reply]

@Marsupium: I suspect the Multimedia team may only be considering the case where "underlying work" would have one value (note that the plan very much is that "underlying work" will just point to a Q-number on Wikidata); but in the example above, it seems to me that there may sometimes need to be two targets -- one to contain the 'creation date', the other the 'published date', both of which are appropriate to show the reader. (Are there cases where it might need to have any more?)

That's assuming, of course, that one does make a separate Wikidata item Engraving of Floors Castle from Neale's Country Seats just for the engraving, which feeds in to the sort of questions I was wondering about further up the page. But it's really only this schema that has somewhere to identify the individual engraver. (Different pictures in such a book will often have different engravers, and sometimes different artists, so one can't really rely on the Book Edition item to place this information. And even when one can, one would need to find a way to securely indicate the creation date of an illustration, which might not be the same as the original creation date of the book -- the illustration might not have been created for the first edition. But it would be nice to avoid unnecessary multiplication of items, if reasonably possible). Jheald (talk) 11:15, 21 September 2014 (UTC)[reply]

Though I support your aim to swing Occam's razor (Q131012), I think it will be the cleanest and best (perhaps only?) solution to create an item for each engraving for which the Wikimedia projects shall provide as much information as you mentioned – engraver, publisher, engraving date, publishing date, then possibly depicts (P180) and so on. This is anyway the best solution to provide all works for a query "all items with John Doe as creator (P170)" (CLAIM[170:John Doe] in WDQ style). Do you have in mind something else? --Marsupium (talk) 12:38, 21 September 2014 (UTC)[reply]

Pages and scan numbers. Separate items for scan-sets ?[edit]

Note that page(s) (P304) is defined as a string, which may need special treatment for sorting.

A separate property may be needed for scan number, which is probably not the same as the printed page number.

Also, what if two separate copies of the same edition have been scanned by different libraries? It should be possible to filter by which copy the scans are from; care may be needed in ordering such scans if the scan numbers for the same page don't match.

Do we need therefore need a separate layer of items for scan-sets?

Or could we get away with representing membership of a scan-set using something not an item (eg a link url or a string), together with a qualifier for Numeric position in sequence (which, curiously, doesn't currently seem to exist as a qualifier).

However, an item may be probably better for enforcing consistency and for filtering by.

Perhaps the item doesn't need to be on WikiData, but should be on CommonsData? It may be a natural match for a Commons category, which may currently have a category header template like c:Template:BL1million bookcat, c:Category:Modern Athens; or, Edinburgh in the nineteenth century (1829) Thomas Hosmer Shepherd, to identify the source of the set.

Or is that over-complicating things; do we simply assume that if CommonsCats have items, they will be on WikiData. (Because the items for many CommonsCats are on Wikidata, because they correspond to wiki-cats.)

Needs more thought. Jheald (talk) 09:49, 21 September 2014 (UTC)[reply]

Discussions noted at WikiProject Books Jheald (talk) 11:24, 21 September 2014 (UTC) [reply]

Discussions noted at WikiProject Structured Data for Commons Jheald (talk) 11:30, 21 September 2014 (UTC) [reply]

inventory number - accession number - shelfmark[edit]

On a related note to the discussions above: Do we have or do we need a separate property for shelfmarks (accession number (Q1417099))? Working on illuminated manuscript items I have recently (ab)used inventory number (P217) for noting shelfmarks, but they are, in my understanding at least, not quite the same thing. On Commons some artwork related templates seem to have a field accession number (which seems close to inventory number, but maybe are a slightly different thing). Afaik manuscripts in libraries (and books in general there) tend to have an accession numbers too, but they are usually neither identical with their shelfmark (and only could be identical if the library in question used some sort of numerus currens system for its shelfmarks) nor do average users get to know it. The shelfmark is the information you need to give the (manuscript) librarian so he can find and retrieve the requested object from the magazine. Thus the shelfmark is among the information required for scholarly citations of manuscripts, not the accession number (unless you are citing a manuscript, which is held in a museum, where a different system might be used). And sometimes the shelfmark will be changed by the library (e. g. because the magazine is reordered), a custom that is quite unpopular among reseachers, so old signatures formerly valid in the same library will have to be noted as well. --HHill (talk) 09:27, 23 September 2014 (UTC)[reply]

I don't see a big problem in using inventory number (P217). But, do you have a concrete case where an accession number and a shelfmark should be attached to an item? BTW: Be aware that a inventory number (P217) statement should always be qualified with collection (P195). --Marsupium (talk) 21:58, 23 September 2014 (UTC)[reply]

There is also the possibility of using catalog code (P528) for this. Jane023 (talk) 07:53, 24 September 2014 (UTC)[reply]

Thank you for the important reminder, Marsupium, as shelfmarks rarely stay the same after a change of ownership, and parts or fragments of one manuscript can be kept in several libraries. No, I do not have an example where shelfmark and accession number should be attached to an item. I just happen to know that (at least sometimes) both exist and I probably could look them up for some manuscripts with items here.

@Jane023, yes, that is another option, as many manuscript catalogues just follow the order of shelfmarks. Not the catalogues for illuminated manuscripts financed by the German Research Foundation (Q707283) though, afaik they are roughly ordered by region of creation and thus have catalogue codes which differ from the shelfmarks. And there are manuscripts which currently have no (other) published catalogue, Stuttgart Psalter (Q2359574) for example. Is it possible here to cite unpublished material which only can be consulted in one library? --HHill (talk) 07:27, 28 September 2014 (UTC)[reply]

For the record, the catalog code can be any catalog, not just published catalogs. Just as "shelf" implies a distinct shelf in a distinct library, I would assume the catalog code to be of the institution you indicate in the qualifier. So maybe for catalog code we need a new qualifier for institution? Jane023 (talk) 09:00, 28 September 2014 (UTC)[reply]

That institution might have several overlapping catalogues (published or unpublished, easily accessible or not) for its holdings though. See e. g. http://data.onb.ac.at/rec/AL00163766 especially the links to scanned catalogue pages in the right column. --HHill (talk) 11:53, 28 September 2014 (UTC)[reply]

The catalogs that an institution has is not a problem, each title of catalog can go in the catalog code qualifier. I highly doubt that the institution will reuse the same shelfmark however, so for shelfmark, the institution can be the catalog code qualifier. Jane023 (talk) 15:11, 29 September 2014 (UTC)[reply]

Painting vs. Art of painting[edit]

After discussing this at length here, I would like some more input from more people, as I strongly disagree that these items should have the same name, and find it needlessly confusing. The item for painting (Q3305213) will be manually selected many times, as it is the correct item to select when defining items of oil paintings in museum collections. The problem is that it always appears second in any drop-down selection list to art of painting (Q11629), which really refers to the "art of painting", which is why I renamed it such. User Danrok renamed it back but in other languages the labels have already been translated in the same way, for example in Dutch one is for "schilderkunst" and the other for "schilderij". Please weigh in with your thoughts, thanks. Jane023 (talk) 19:39, 23 September 2014 (UTC)[reply]

I don't have strong feelings about it. But indeed the bare "painting" causes problems. Right now, the false instance of (P31) <art of painting (Q11629)> is used four times. The problem is even slightly bigger. It also concerns the subclasses of art of painting (Q11629). Just yesterday I caused confusion by removing the very strange made from material (P186) <oil painting (Q174705)> (also the process/action). In fact it would be nice to avoid all that. --Marsupium (talk) 21:53, 23 September 2014 (UTC)[reply]

Thanks, I didn't even think about that aspect of it. I was thinking more along the lines of all the other 2-D arts, such as engraving, etching, mezzotints and woodcuts. This problem does need to be addressed somehow, at least through defaults in the drop-down selection method, but preferably with the labels, as this will be most commonly used in searches. In this case it should be "art of painting" vs "painting", but I can see the renaming going the other way around, such as "engraving" for the art vs "plate(engraving)" for the piece of paper. Jane023 (talk) 07:51, 24 September 2014 (UTC)[reply]

After staring at the items for engraving for days, I think we need to agree on some basic rules of play. For any artwork covered in oil paint, we have a painter who uses a painting process to produce a painting. For an engraved roemer, we have an artist who uses an engraving process on a roemer to produced an engraved glass roemer. For an old master print, we have an engraver who uses an engraving process on a copperplate and who flips this onto a piece of paper to produce a print. That gets hairy fast with a dizzying number of engravers who use a dizzying number of engraving processes (woodcutter - woodcutting - woodcut?) etc. I think the first is a subclass of occupation, the second is a subclass of art technique, and the third is a subclass of artwork. There seem to be many overlapping doubles out there. The painting group is also still unresolved - what about gouaches and watercolors? Anyone have ideas how to organize this? Jane023 (talk) 15:08, 29 September 2014 (UTC)[reply]

Date issues[edit]

Have we got a consensus on how to enter date of birth "circa 1527" and date of death "before 24 November 1581"? I've been looking for an answer but I cant seem to find one. - PKM (talk) 01:15, 5 November 2014 (UTC)[reply]

See Wikidata:Project chat/Archive/2014/09#How to model dates without known precision? with links to older discussions (the property proposed by Vlsergey is sourcing circumstances (P1480), if I remember correctly). --HHill (talk) 18:59, 5 November 2014 (UTC)[reply]

thank you! - PKM (talk) 19:50, 5 November 2014 (UTC)[reply]

Grove Art Online[edit]

Following English Wikipedia, I have change the label for Oxford Art Online (Q1547776) from Grove Art Online to Oxford Art Online, but I am not sure whether Grove shouldn't be a part of Oxford Art Online rather than an alias. Thoughts? - PKM (talk) 02:04, 5 November 2014 (UTC)[reply]

Ummmm. I think you need @Charles Matthews: to answer that one. In any case someone with full access based in the UK. Jane023 (talk) 10:48, 7 November 2017 (UTC)[reply]

I've put it back. "Oxford Art Online" looks more like a portal. Charles Matthews (talk) 10:52, 7 November 2017 (UTC)[reply]

Thanks! I may move slowly, but it's nice to know my gut feeling when I saw this today (3 years later) was correct! We still need to find a way to put wikipedia titles into the alias part and keep our labels somehow "clean". The tricky part is when the WP title includes some sort of disambiguation in parentheses. Jane023 (talk) 11:09, 7 November 2017 (UTC)[reply]

What enwiki says: "The site was expanded and renamed as Oxford Art Online, including other works: The Oxford Companion to Western Art, Encyclopedia of Aesthetics, The Concise Oxford Dictionary of Art Terms. In 2011, the Benezit Dictionary of Artists was added to the database." seems to be correct, so Grove Art Online is a part of Oxford Art Online. Also if anybody wants to have access, write me an email! Cheers, --Marsupium (talk) 16:09, 7 November 2017 (UTC)[reply]

Anonymous works[edit]

We have anonymous (Q4233718) to be used with creator (P170). Usually we have a bit of information about this unknown author we want to include as a qualifier. The Rijksmuseum (Q190804) was so kind to share their collection manual. It's a 100+ document touching onto a lot of problems we face too, including anonymous works. I would propose to create the missing properties so we can properly qualify anonymous works. I'll list them here, between () is the Dutch original:

Attributed to (toegeschreven aan): object is not signed and there is a certain amount of uncertainty who the author is.
Workshop of (atelier van): to be used if the object was probably created by students or employees of the artist in the same workshop, possibly with help of the named artist.
Follower of (navolger van): unknown artists who works in the manner of the named artist.
~~Surroundings of~~ Circle of (omgeving van): objects by an unknown author who lived in the same time as the named author in a similar style, possibly a follower or someone who had contact with the named artist.
Manner of (manier van): objects in similar style as the named author, but not necessary from the same period.
Forgery after (vervalsing naar): Forgeries trying to appear to be the work of the named author.
Possibly (mogelijk): To be used with objects with a bigger uncertainty about the author.
School of (School van): Unknown author with a style influenced by the known author or ~~surroundings~~ circle, active in the same period, but a student or follower

Opinions please! Jane & Sandra, you both have the original document. Any input/corrections? Multichill (talk) 20:23, 24 November 2014 (UTC)[reply]

Do you mean 1 new property to be used as a qualifier for creator (P170), like we have an "option" parameter in Commons:Template:Creator ? That would seem like the simplest solution to me in any case.
I would rather use the special value "somevalue". "Anonymous" may sound better, but that is a bit messy. How do we define "anonymous" ? Curenly anonymous (Q4233718) is a subclass of "author" itslef a subclass of profession, which means that some paintings were created by a subclass of progession. Making it a subclass of humans would not really solve the issue. By contrast, "somevalue" is well defined Wikidata-wide, so that we do not have to wonder "what is the item for unkonwn place, for unknown creator, etc."? --Zolo (talk) 21:27, 24 November 2014 (UTC)[reply]

I think all Multichill's suggestions are fine for new properties except for "Attributed to" , which is just the same as creator. All the others can conceivably used in addition to the creator property. So for example, a painting by Govert Flink will could have him a creator and also be school of Northern Netherlands and workshop of Rembrandt. Jane023 (talk) 23:17, 24 November 2014 (UTC)[reply]

Just a clarification. anonymous (Q4233718) would also be the right value to use for any artwork where the author is "unknown"? In addition to the qualifiers above I've also encountered "Circle of" and unknown but with some geographical information such as "unknown italian" (painter). /Lokal Profil (talk) 11:42, 25 November 2014 (UTC)[reply]

Yes, I think that is what we have now, except we want to split those out into more informative anonymous creators. I would also like to have "unknown Italian" and "unknown French" as valid creators, with sub-items for "Quattrocento painter" or "Caravaggist". Rethinking my earlier post, I also think that "attributed to" could be valid in addition to the creator property, especially for attributions that knocked around alot, like Rembrandt and others. You could add a qualifier for a catalog name or start date (for an auction sale as Rembrandt, though the painting is attributed today to Govert Flink, etc). Jane023 (talk) 14:10, 25 November 2014 (UTC)[reply]

Do we need to record who attributed the work, and when? - PKM (talk) 06:06, 26 November 2014 (UTC)[reply]

We don't have to do anything, but it would be nice if we could add this information. Back when I started work on the catalog of Frans Hals paintings, it took me a while to track down all of the paintings mentioned in his wikipedia page, because that page had been copied in pretty much verbatim from the old 1911 Encyclopedia Britannica entry. There are several paintings mentioned in that document that are no longer attributed to Frans Hals, and it was pretty difficult to track them down. What with all the work being done now on Commons in the provenance fields of the artwork template, it would be nice if we could enter this information into the Wikidata item as well. Jane023 (talk) 15:11, 26 November 2014 (UTC)[reply]

i'm afraid that EB1911 is all there is for many non-english artists. but yes, who attributed and when, would be good qualifiers. this probably will not be at commons metadata (no fields except "notes"), requiring going to the institution metadata page. another rabbit hole would be provinance. Slowking4 (talk) 17:31, 30 December 2014 (UTC)[reply]

Hi all - just a quick note - in the USA we generally say "unknown artist" or "anonymous" so I have been using "unknown artist" anonymous (Q7896952) since that is generally how I've done things in the galleries and museums I have worked at. I like the idea of attributed and workshop, for sure, as these are more common for me than forgery, school of, possibly, etc. Missvain (talk) 17:04, 30 December 2014 (UTC)[reply]

anonymous (Q7896952) works well for me. I'd like to be able to qualify that with "Anglo-Netherlandish School", "Venetian School" - pretty specific, as given in the sources I work with. We should be able to build a logical hierarchy for those as subclasses of ... something? We might also want "Unknown Workshop" where more than one Gand is detected. - PKM (talk) 18:57, 30 December 2014 (UTC)[reply]

Also, in my mind "anonymous" implies intention on the creator's part, whereas "unknown" simply indicates the limits of current knowledge. - PKM (talk) 19:00, 30 December 2014 (UTC)[reply]

What Sarah says is also how I know it from Rijksmuseum, RKD, ULAN, etc. These collections generally record anonymous (Q4233718) and than add on of the qualifiers I suggested above.

We could create items for each intersection like "Anonymous follower of Rembrandt" or do "Anonymous" with qualifier "follower of" -> "Rembrandt". I'm not a big fan of intersections.

PKM, I don't get your last remark about "anonymous" and "unknown". Can you elaborate? Multichill (talk) 21:03, 30 December 2014 (UTC)[reply]

It seems like "anonymous" is used for " unknown" by museums, so it would probably work here. But I think of " anonymous" as implying the intent to disguise authorship, rather than formerly known but now lost authorship. - PKM (talk) 21:13, 30 December 2014 (UTC)[reply]

Checked both the Dutch and the English dictionary. No mention of the intent. So it's not just the museusm, it's everyone (except maybe you). Multichill (talk) 21:38, 30 December 2014 (UTC)[reply]

Not the first time it was just me. :-) - - PKM (talk) 03:19, 31 December 2014 (UTC)[reply]

I want to suggest more qualifiers like

copy (of) or after

and

formerly attributed to Oursana (talk) 12:58, 10 June 2015 (UTC)[reply]

Launch of WikiProject Wikidata for research[edit]

Hi, this is to let you know that we've launched WikiProject Wikidata for research in order to stimulate a closer interaction between Wikidata and research, both on a technical and a community level. As a first activity, we are drafting a research proposal on the matter (cf. blog post). It would be great if you would see room for interaction! Thanks, --Daniel Mietchen (talk) 01:45, 9 December 2014 (UTC)[reply]

Open Issues[edit]

I just found Physical Object Class Identification Problems which is on a subpage that isn't discoverable through the project's navigation. Can we make sure that subpages like this are linked in some central place so they don't get lost?

Maybe a bulleted list of "related discussions"? - PKM (talk) 17:09, 9 December 2014 (UTC)[reply]

.

BBC "Your paintings" painters[edit]

Just to let people know, I have updated the en-wiki pages at

en:Wikipedia:GLAM/Your_paintings#Artists_by_birth_period

that break down the list of "Your Paintings" painters by date, to bring it up to speed with the data now on Wikidata.

There is more to do -- ~~to check for new potential matching categories on Commons~~, check through the potential matches on en-wiki and Commons to see whether or not they are true matches, look up VIAF references where they are not yet on Wikidata. But it's getting there.

I now have scripts to regenerate the pages from Wikidata (plus a file of legacy lookups). So if anyone does some work on Wikidata on YP entries, and would like these pages updated, please drop me a note. Cheers, Jheald (talk) 00:35, 11 December 2014 (UTC)[reply]

Wow that is very impressive. Thanks for your work on this - so glad to see it! Jane023 (talk) 10:25, 11 December 2014 (UTC)[reply]

Just to add, I've now added a column giving the number of paintings by the painter on the PCF site -- which can give an interesting vignette into British collection (and/or attribution) enthusiasms.

See here for a links bar.

*** in the count column indicates an Error 404 from the PCF -- usually a sign that they have merged or changed the identifier.

It's quite a slow business, but working down the 'english' column before Christmas, with '?' sorted to the top, I had got to the 1600s and the end of first names starting with 'D', if anyone wants to take this up -- trying to see if the suggested en-wiki did indeed correspond to the artist; and if so adding a Art UK artist ID (P1367) to the corresponding item here. Edits need to be made to the relevant wikidata item; they will then be echoed to the report wikipage when I next run the script. A '?' in the Commonscat column is worth looking out for -- if there is no '?' in the Wikidata column, this may be a sign that the Wikidata item currently has no Commons category (P373) (but should have); or that the P373 is on a duplicate Wikidata item for the same person).

I'll try to write up the process in greater length in due course, in a subproject page for the new UK and Ireland wikiproject. All best, Jheald (talk) 18:07, 21 January 2015 (UTC)[reply]

Great work! Thanks for adding the Q numbers and updating the commons categories, VIAF numbers and RKD numbers. I find it helpful to see how many files are in there, because everybody with more than 20 files at the PCF should have a Wikipedia page I think. Jane023 (talk) 18:45, 21 January 2015 (UTC)[reply]

Updated again. I've now added links to Mix'n'match search, to make it easy to look for matches in RKD, ULAN, Br Museum, ODNB, etc, as well as YP all at the same time as one goes down the page. Jheald (talk) 16:32, 11 March 2015 (UTC)[reply]

Some feedback on data structure from Wikipedia infoboxes[edit]

I have activated some Wikidata-retrieving functions in fr:Modèle:Infobox Art. Here are two issues I have found:

owned by (P127): it is not always possible to know which is the current owner using Wikidata data. Start and end dates are often, but now always provided (and we do not always know them). This produce some weird outputs in Wikipedia, like "owner: Claude Monet and French State". For a paiting that belonged to Monet but was then donated to the French State. To solve this we have a simple solution: always add "rank : preferred" to current owner. Also, sometimes, the current owner is not provided, so that the field only contains past values, which is weird.
made from material (P186) fr:Module:Material analyses the applies to part (P518) qualifiers. When it is set to painting support (Q861259), it formts it so that it shows "oil on canvas", not "oil and canvas". Sadly the applies to part (P518) qualifier is not always provided. For canvas, I suppose it could always assume it is always the support, but that gets messy when you condiser wood... I think adding as many applies to part (P518): painting support (Q861259) as possible would be a valuable task for a bot.

Other than that, things appear to work allright. --Zolo (talk) 10:51, 31 March 2015 (UTC)[reply]

Interesting! Thanks for doing this Zolo. To answer your first question (without looking at the artworks) I assume the case of old owners is known when important things come up for auction, such as top pieces from the Yves Saint Laurent and Elizabeth Taylor collections. We don't know who bought them, but we do have provenance provided by the auction houses. As far as the applies to part I agree and it would be great if a bot could read these on Commons and update Wikidata as needed. Jane023 (talk) 13:11, 31 March 2015 (UTC)[reply]

fr:Modèle:Infobox Artiste now also supports artists (example). It turns out that one of the tricky points is to supplement data provided locally in the infobox parameers with Wikidata, without creating redundancies. --Zolo (talk) 20:26, 31 May 2015 (UTC)[reply]

Contemporary artists and their galleries?[edit]

I'd like to work on contemporary art galleries and the artists that are represented by them (interesting topic). Example: Michaël Borremans (Q284808) and his gallery Zeno X (Q4473899). I'm not sure which property to use to model the relation between an artist and his/her gallery. member of (P463) just doesn't feel right. affiliation (P1416) comes close, but seems not 100% appropriate. Use affiliation (P1416) with a qualifier (which one?)? Or shall I propose a new property (e.g. 'represented by')? Any ideas? Thanks, Spinster (talk) 18:22, 15 April 2015 (UTC)[reply]

Good idea! How do we map the relationship of music artists and their labels? Maybe we can use that property? Jane023 (talk) 12:07, 16 April 2015 (UTC)[reply]

Hmm - actors don't have any mapping to their agencies either. Odd. Jane023 (talk) 13:10, 16 April 2015 (UTC)[reply]

Nor do fashion models and their modeling agencies. I gave it some thought, and decided to propose a new property for this. Spinster (talk) 12:22, 20 April 2015 (UTC)[reply]

Item structure for art movements (and then genres, cultural movements and much more)[edit]

Notified participants of WikiProject Visual arts. Hello participants of this project! I have been working on item structure suggestions and a to do list for art movements here: Wikidata:WikiProject Visual arts/Item structure/Art movements. Does anyone object to it if I 'officially' include this page in the tasks of this WikiProject and link it under Item Structure?

If you are all OK with it, I would then like to create similar pages about cultural movements, art genres... and would like to take the freedom to re-organize the general overview pages of this WikiProject a bit, in order to structure all possible task lists and to make everything a bit more findable for newbies and advanced participants alike. Of course, feel free to edit / improve / leave feedback on the talk page! Thanks, Spinster (talk) 21:01, 26 July 2015 (UTC)[reply]

Thanks a lot Spinster for those great improvements ! OK for all. As pointed wikidata is maybe still difficult for new users and the lack of information especially dedicated to visual artworks is maybe an issue. Therefore I made a test of a tutorial video (in French) about creating and editing an item of visual artworks. And for advanced participants, it's very usefull to have information, because we always miss something and so we could make better edits, more edited and more homogeneous. Thanks again. Best regards --Shonagon (talk) 01:05, 27 July 2015 (UTC)[reply]

Notified participants of WikiProject Visual arts Nice! I like both the suggestions and the video. I made a presentation for Europeana Food and Drink (Q19723898) content providers: http://www.slideshare.net/valexiev1/glams-working-with-wikidata: how GLAMs can use Wikipedia/Wikidata to make their collections globally accessible across languages. It also shows how easy it is to work with Wikidata. --Vladimir Alexiev (talk) 09:48, 31 July 2015 (UTC)[reply]

Thanks for linking! I had already discovered it and it has a lot of really useful information for discussing with GLAMs in our forthcoming Mobilizing Open Cultural Data project in Wikimedia Finland. --Susannaanas (talk) 10:26, 31 July 2015 (UTC)[reply]

I love this idea and the video! Interesting presentation Vladimir, and coincidentally I just added a standing cup to Wikidata - the nautilus cup (Q20731983). Oddly we still need a class "standing cup". Great work and definitely needs doing. Go for it, Sandra! Jane023 (talk) 10:37, 31 July 2015 (UTC)[reply]

@Jane023: thanks! I've been adding lots of categories and redirects and small pages to Wikipedia as part of EFD, as we go through the Horniman collection (it's an ethnographic museum). And I've added lots of Horniman references to curious things like en:Lovespoons and en:Scotch hands. Sad thing, I can't illustrate them with Horniman images since they have not yet seen the Open light. Eg see pleas on twitter --Vladimir Alexiev (talk) 17:23, 31 July 2015 (UTC)[reply]

Well thanks for your work on that. If you do come across weird images like that, you can also create categories for them on Commons and then create items for them on Wikidata. So a corncob holder should probably be something we would use at some point on Wikidata, if only in the depicts field of some painting or print. I made c:Category:Corncob holders on Commons, but you said you didn't have the image itself. Jane023 (talk) 11:48, 1 August 2015 (UTC)[reply]

Mix'n'match synchronization[edit]

@Charles Matthews, Jane023, HCShannon, Spinster: I recently created about 1,500 items for entries in Union List of Artist Names ID (P245) that were marked as "not in Wikidata". However, many of these people are also marked as "not in Wikidata" in other databases like RKD or yourPaintings. So now, we have a lot of "no Wikidata" entries for RKD and yourPaintings that actually have a Wikidata item and it is rather hard to disentangle. I think the best way to prevent such a thing is to work one database at a time and create regularly the missing items. --Zolo (talk) 10:16, 2 November 2015 (UTC)[reply]

Hello, and thank you for your efforts. It is not really practical to restrict to one database out of over 100! The problem comes with deciding how to create items.

For example, the decision on YourPaintings, where a "first pass" has been completed, was not to create the missing items. That is because the notability isn't clear, for that dataset.

ULAN is more seriously curated than YourPaintings (which was compiled from over 2000 institutions), so perhaps notability should not be a concern there. Any creation of items may cause potential merges to be set up, i.e. duplication. Well, the only way to avoid it would be to check the set against what exists today.

For the issue you identify, it would be useful to run each item that now exists against the mix'n'match overall search function. This would find numerous RKD and YP matches. That would help develop the new items, as an authority control search would also. Charles Matthews (talk) 10:53, 2 November 2015 (UTC)[reply]

OK, you didn't say which account you were using, but checking a query for ULAN and no VIAF, it seems that User:Widar of zolo is the account. The recent creations make up most of the last 1500 on that search. So you presumably are using the mix'n'match search to add identifiers. Anything in ULAN should also be in VIAF, meaning that VIAF should be quit e easy to add using the sidebar tool (which not everyone knows about, indeed). Then having VIAF should make it easier to identify potential merges.

Is there really more of a solution to the issues you raise? Charles Matthews (talk) 11:08, 2 November 2015 (UTC)[reply]

When you create items for people, you should try to propagate the names to labels in other languages than English, and least do the main european languages or the original language of the creator (seen in the birthplace property?). This will increase findability so the mess will be easier to clean up through Mix-n-Match. Too bad there is no way to cross-reference these with the other databases - ask Magnus if he can run his auto-matcher again? --Jane023 (talk) 11:48, 2 November 2015 (UTC)[reply]

Maybe we should start with single-museum databases, as they are usually smaller, well curated and every entry should be notable enough. Actually quite a few of them are needed to complete creator (P170) in artwork items. In any case, if we create the items quickly after marking them with "no wikidata", it will minimize the risk them being created through another channel and left with an erroneous "no wikidata" marking.

Most of my ULAN-related creations were based on the quickstatements form that was provided in the "create missing items" menu of mix'n'match (and followed by an "update mix'n'match").

I think that at some point bots added VIAF IDs based on ULAN, but I do not know if it is still done.

A bot can probably copy most English labels to other Latin-script languages, ideally with excluding those with keywords like "the younger" etc. However, I do not think it would help much with the issue at hand, as the search options appear to take all languages into consideration. I try to add Chinese and Japanese names when possible.

A re-run of the auto-matcher may indeed be useful but it should not discard all the manual removals of wrong automatches, I do not know if there is a way to do that. --Zolo (talk) 13:11, 2 November 2015 (UTC)[reply]

Actually the "creation candidates" tab in mix'n'match allows one to "level up" particular items. Overall I don't see that the situation is badly wrong. The idea of complete creation for certain datasets can introduce the need to merge. Apart from that, the mix'n'match way of adding statements across all the catalogs is basically helpful. Charles Matthews (talk) 17:48, 2 November 2015 (UTC)[reply]

Yes, perhaps there is no mess at all, and there should just be more links added. I will take a look. --Jane023 (talk) 18:17, 2 November 2015 (UTC)[reply]

I am using the "create missing items" option that does only one catalogue at a time (here). Above a certain number of items, I think it is faster than using "creation candidates", but when the catalogue overlaps with others, wrong "no wikidata" can become a real issue. --Zolo (talk) 18:38, 2 November 2015 (UTC)[reply]

I've been creating loads of missing painters the last couple of week. For this I made this tool (just one artist). I create people who show up in multiple databases and already have some works here. Another approach is to do this per collection:

I would like to see items created where people show up in multiple databases and/or when we already have works that still need to be connected. Multichill (talk) 20:42, 2 November 2015 (UTC)[reply]

I will be creating some more items to complete User:Multichill/KMSKA creators. Most of the items seem to have RKD and VIAF. Through viaf quite a few ULAN links can be found. Didn't we have some sort of bot that could import these ULAN links from viaf? Multichill (talk) 22:22, 4 November 2015 (UTC)[reply]

Wikimania 2016[edit]

Only this week left for comments: Wikidata:Wikimania 2016 (Thank you for translating this message). --Tobias1984 (talk) 11:50, 25 November 2015 (UTC)[reply]

Please join the discussion[edit]

Hey All, I started a conversation about adaptation vs "based on" on P144's talk page please join the discussion, Sadads (talk)

Sculptures by Canova[edit]

Could you answer these questions, please? Thank you, --Epìdosis 12:27, 17 October 2016 (UTC)[reply]

Many Jean Saives[edit]

Perhaps anybody can help out to fix the mixture between Jean Baptiste de Saive I (Q985100) and Jan Baptiste le Saive II (Q1226250). Wikidata, the Wikipedias and other sources say they are two persons:

Jean Baptiste de Saive I (Q985100), father (c. 1540 – 1611)
Jan Baptiste le Saive II (Q1226250), son (1571 – 1624).

Commons has only c:Category:Jan Baptist Saive (I),
ULAN has only 500079941 (ca. 1540 - 1624),
RKD has only 69323 (1530/1550/ca. 1540 – 1624-04-06),
AKL (paywall) has two entries: 40069309 (LeSaive, Jean (1540)) (1540 – 1611 / 1624); 00121931 (LeSaive, Jean (1571)) ((um) 1540? / 1571 – 1624.04.06)

There is still Jan Baptist Saive the Younger (Q1668930) who definit though AKL: 00236537 (LeSaive, Jean-Baptiste) (1597 / 1604 – (nach) 1641 / (nach) 1665).

We could write to RKD and to Getty for ULAN and ask and hope for clarification. Anyway, how shall we handle the identifiers for now? --Marsupium (talk) 19:01, 22 May 2017 (UTC)[reply]

I've asked Getty. But GVP may not have the resources to research things like this.

What to do: I think there is warrant to keep 3 items (based on AKL). Interlink them with "different from". --Vladimir Alexiev (talk) 10:00, 23 May 2017 (UTC)[reply]

… and put the ULAN and RKD IDs on both Jean Baptiste de Saive I (Q985100) and Jan Baptiste le Saive II (Q1226250) and add them to the constraint violation exceptions? --Marsupium (talk) 11:22, 23 May 2017 (UTC)[reply]

@RKDdata: Perhaps you can help with https://rkd.nl/en/explore/artists/69323 if it should actually be split. --Marsupium (talk) 11:30, 23 May 2017 (UTC)[reply]

@Marsupium: Getty replied: "Yes, the oeuvres and biographies of father and son have long been confused, including by ULAN contributors, Provenance, Witt, Courtauld, Benezit, etc. ULAN 500079941 remains the record for the father, and ULAN 500404125 is the new record for the son. Thanks!" --Vladimir Alexiev (talk) 09:31, 26 May 2017 (UTC)[reply]

Great, thanks! (You wrote with Robin Johnson?) So we will only have to wait for some days probably for the new record to appear online! --Marsupium (talk) 09:44, 26 May 2017 (UTC)[reply]

@Marsupium:Talked to Patricia Hapring. 500404125 is not yet online --Vladimir Alexiev (talk) 10:24, 7 June 2017 (UTC)[reply]

For the record: The problem has already been discussed more thoroughly two years ago at User talk:Gymel#Jean de Saive. --Marsupium (talk) 20:07, 28 May 2017 (UTC)[reply]

@RKDdata: ? Thank you! --Marsupium (talk) 10:49, 26 September 2017 (UTC)[reply]

Gillis Egidius Claeissens and Monogrammist G. E. C.[edit]

Notified participants of WikiProject Visual arts

This 2015 monograph by Alexandra Zvereva of the Sorbonne identifies the Southern Netherlandish painter Gillis (Egidius) Claeissens with the artist known as the Monogrammist G. E. C. (Q15632469).

I have added Gillis Claeissens to WD as Gillis Claeissens (Q30015849), using the RKD artist data with additional info from Zereva's paper and from the Weiss Gallery. I have marked both artists as <said to be the same as> the other.

I am reluctant to merge the items with just the sources I have (though Zereva is a reputable authority, the paper was published for an art dealer and isn't peer reviewed). What does the project think? (And should the paintings attributed to Claeissens by Zereva in her paper have a second "attributed to" creator template in Commons for Claessins, in addition to Monogrammist G.E.C.?) - PKM (talk) 00:41, 23 May 2017 (UTC)[reply]

It's fine how you left it. I made a creator template and commons gallery and added the commons category you created to that category. You could add a line to the monogrammist template referring to this. Since not all institutions will change over right away, it's probably more accurate for us to have items for both, referring to each other as you have done. Jane023 (talk) 05:34, 23 May 2017 (UTC)[reply]

Thanks for validating my instincts. I'll add the note to the monogrammist template. - PKM (talk) 19:32, 23 May 2017 (UTC)[reply]

Solely structural Iconclass items[edit]

How can we prevent the creation of items like Joseph of Arimathea (Q21557749)? --Marsupium (talk) 20:14, 28 May 2017 (UTC)[reply]

I agree that the item was fairly useless as it was, but I added some statements and would vote to keep this, as a specific art theme is not the same as its main subject. You may want to read the English article about en:iconclass before jumping to any further conclusions. I have found iconclass very useful when looking for specific paintings of the crucifixion with the Magdalene kneeling with her arms wrapped around the cross, and a few others. This one is admittedly unknown to me. Basically there are two properties: Iconclass notation (P1256) and depicts Iconclass notation (P1257). My guess, though this 2015 edit is probably quite hard to trace, is that this artistic theme occurs frequently. I know there is a way to use the iconclass browser to view works with a specific iconclass code and my rough assumption is that Magnus's bot created items for the popular themes. I just tried to find a few paintings to link to this theme, but we still don't have many (and I know from attending an iconclass meeting last year that most art using these codes are engravings, not paintings). I agree we need to talk more about how to use iconclass, since it would be great if clicking on the iconclass code didn't bring you to the browser, but to the linked open data for the art (maybe via Europeana?). Now we have no choice but to hunt around on Commons and I think I am the only one who ever created a few iconclass codes there. I see now that the link doesn't seem to work, but if you cut and paste the text into the iconclass browser it will take you to the correct spot in the "artistic them ontology". Jane023 (talk) 08:32, 7 November 2017 (UTC)[reply]

The "68" is not specific, there is such a suffix for each of the 182 male saints (other example) and the 60 female saints (at least I presume, I haven't tested 242). Though for some saints the "68" is indeed specific (example), I support to create items for those only. I don't think some other dozens of items just for unspecific codes for each of the 242 (will easily be 10.000), for Joseph of Arimathaea like 11H(JOSEPH OF ARIMATHAEA)37 personal devotion of St. Joseph of Arimathaea - male saint meditating, in ecstasy etc. are useful. Using those codes as values of depicts Iconclass notation (P1257) is useful of course. We shouldn't uncritically transfer the structure of Iconclass designed for a paper era (I collected some points about that here) to Wikidata I think. --Marsupium (talk) 16:33, 7 November 2017 (UTC)[reply]

@Jane023:, are you suggesting that (for example) we should have an item “King Arthur” <instance of> artistic theme separate from King Arthur (Q45792)? - PKM (talk) 19:29, 7 November 2017 (UTC)[reply]

No, but probably yes for "King Arthur as a youth, pulling a sword out of a stone", if that turns out to be widely popular in art. I guess these art themes are more or less haphazard choices based on their popularity, for whatever reason. In the original example I assume it's the holy grail that makes it more notable than other themes, not St. Joseph himself. Jane023 (talk) 22:30, 7 November 2017 (UTC)[reply]

Got it. Thanks! - PKM (talk) 07:29, 11 November 2017 (UTC)[reply]

No, the Holy Grail is already in 11H(JOSEPH OF ARIMATHAEA, its title is: (11H(JOSEPH OF ARIMATHAEA) the Jewish councillor Joseph of Arimathaea; possible attributes: Holy Grail, instruments of the Passion (e.g. three nails, crown of thorns)). --Marsupium (talk) 19:46, 11 November 2017 (UTC)[reply]

More on iconclass notations[edit]

Notified participants of WikiProject Visual arts@Magnus Manske:

I've been working with Iconclass notations lately and I have a number of questions. I think we need to talk more about how we propose to use this information.

In the case of Joseph of Arimathea (Q21557749), I believe the correct process is to merge it with Joseph of Arimathea (Q271474). The list of attributes should not be included in an alias. Instead, I think we need a (?new) property for attributes or symbols of saints and mythological or legendary figures.
I like what Marsupium has done at Holy Trinity in which God the Father and Christ are represented as persons, the Holy Ghost as dove (Q22247337). Is this how we want to deal with episodes in the lives of saints, mythological stories, etc.?
Iconclasses like iconclass.org/rkd/81E/ seem to be like redirects - should we mark them "not aplicable" in Mix'n'Match and remove them where added?
Per Property talk:P1256, all of the finegrain subclasses (see for example 11H(SEVERUS)82 "the weaver Severus ... miracles occurring during the handling of relics" (one of 15 such at [5]) should not apply to Wikidata - should we bulk mark these "not applicable" in Mix'n'Match? Can that be automated?
Iconclass notations often include concepts which are separate classes of items in Wikidata. (Examples: 47I85 'woodgathering, woodgatherer'.) I am not sure the "distinct value" constraint on this property is helpful.

- PKM (talk) 20:37, 6 November 2017 (UTC)[reply]

Also - can we agree that items including the notation "(with NAME)" are purely structural and should be "not applicable" in Mix'n'Match (and any old existing WD items for these notations should be deleted or purged (example gods, demi-gods, heroes etc. of Babylonian-Assyrian religions and antique religions of the Near East and Northern Africa (Q21557763), created by bot back in 2015. - PKM (talk) 22:12, 6 November 2017 (UTC)[reply]
Thank you for all the points! (' hope it's ok, I've numbered them.)

To 1.: The "68" of "11H(JOSEPH+OF+ARIMATHAEA)68" has only the unspecific meaning "miracles occurring during handling of relics of male saint". Even if the plus signs were corrected to spaces Joseph of Arimathea (Q21557749) should be deleted in my eyes and the ID marked as not applicable in Mix'n'match. We already have Joseph of Arimathea (Q271474)Iconclass notation (P1256)11H(JOSEPH OF ARIMATHAEA). I always wonder how Reinheitsgebot got the idea to create items like this one, would have been nice if it had stated this somewhere ….

To 3.: Agree!

To 4.: I think there are some IDs hidden in the tree that are applicable because they are specific, for example 11H(JOSEPH OF ARIMATHAEA)41 St. Joseph of Arimathaea catching the blood of Christ hanging on the cross in a cup (the Holy Grail). If you agree that these are applicable, automation will need some investigation at least. (Oh, I also still have to fix the format regex!)

Good point (also probably applies to some items about Mary and Jesus). Manual it is for now? - PKM (talk) 02:03, 7 November 2017 (UTC)[reply]

To 5.: Can't this be handled with constraint exceptions?

Best regards, --Marsupium (talk) 22:21, 6 November 2017 (UTC)[reply]

Agree 5 can be handled with constraint exceptions as long as we all promise to work on adding them. :-) Maybe after we get most of the list assigned we can go back and do some constraint reporting as a separate pass. - PKM (talk) 02:03, 7 November 2017 (UTC)[reply]

Fine! --Marsupium (talk) 16:33, 7 November 2017 (UTC)[reply]

Are we sure about this? See list so far at Iconclass notation (P1256). :-) - PKM (talk) 00:58, 21 November 2017 (UTC)[reply]

Hm, I see. It's 43 exceptions out of 2.806 statements, not a low quote. Perhaps it's good to track them anyway, but of course it's more work and stresses Iconclass notation (P1256). So, if you want to get rid of it, I won't oppose a deletion. --Marsupium (talk) 21:33, 22 November 2017 (UTC)[reply]

Christie's creator id[edit]

Christie's creator ID (P4200) now exists, in case anyone feels like adding it to mix'n'match... --Zolo (talk) 08:03, 19 September 2017 (UTC)[reply]

Good to see! Hannolans (talk) 20:40, 6 November 2017 (UTC)[reply]

Magnus kindly added the set to Mix'n'Match. Happy matching! It'll be nice to be able to do more with artworks that pass via auction houses like Christie's. Pity that Sotheby's has no artist database that is scrapeable... Spinster 💬 11:34, 13 November 2017 (UTC)[reply]

Note that artist names with more than three “parts” are almost invariably garbled in Christie's database. For example, for ‘Adrien Victor Joseph de Gerlache de Gomery' Christie's has 'Adrien Victor Gerlache De Joseph De Gomery'. Such fun! - PKM (talk) 04:09, 23 November 2017 (UTC)[reply]

Nine Worthies - iconclass notations[edit]

Could folks please look at what I have done with Nine Worthies (Q32498) and its nine parts and see if this seems right to you? Please feel free to add or change things. - PKM (talk) 21:54, 12 November 2017 (UTC)[reply]

It looks very good to me! --Marsupium (talk) 23:54, 13 November 2017 (UTC)[reply]

Pictures from photographer-artist Militão Augusto de Azevedo[edit]

Hello all! In the context of a GLAM initiative we are running with Museu Paulista (Q371803) --which has already led to the creation of Wikidata:WikiProject sum of all paintings/Collection/Museu Paulista--, we will upload pictures from Militão Augusto de Azevedo (Q10330043), a very important Brazilian photographer-artist, who in the 19th century was responsible for capturing how modernity was being developed in São Paulo (Q174). Each picture of his --a small collection that is extensively reproduced on post cards and led to the publishing of the famous "Picture Album of São Paulo" [6] portrays artistically aspects of the city. Should each picture has a Wikidata identifier? Thanks for providing some guidance, as we expect to do the upload asap. --Joalpe (talk) 04:21, 13 November 2017 (UTC)[reply]

Hm, I can't remember a precedent of this. But if those photographs are famous in some way and if it is possible to document them thoroughly, I think it would be fine to have them here with an item for each photo. How many photos are concerned? There is still to consider how to describe them best in items. How many reproductions do exist for each photo? If there are those in museums do they have inventory numbers each? --Marsupium (talk) 16:50, 13 November 2017 (UTC)[reply]

@Marsupium: Thanks for your reply. I have presented your questions to the museum director, Solange Ferraz de Lima (Q28515059), who is doing an amazing effort to understand the projects and who believes --based on what you said, with which I agree-- it doesn't make sense to create individual Wikidata itens for the photographs as they were conceived as a collection. They don't have individual inventory numbers, for instance. Thanks a lot! --Joalpe (talk) 23:41, 13 November 2017 (UTC)[reply]

I really did not want to discourage the creation of single items! Even if I don't have an overview of the photos you have items could be useful to put depicts (P180) statements etc. on them, for example and these data can be reused then on Commons and elsewhere! --Marsupium (talk) 23:48, 13 November 2017 (UTC)[reply]

@Marsupium: Oh! I think I misunderstood your comment, sorry. You can take a look at pictures on the website I linked above (bottom of the page): [7]. Let me know what you think! --Joalpe (talk) 23:57, 13 November 2017 (UTC)[reply]

@Joalpe: Yes, I can totally imagine that it would be nice to have an item for this photo with depicts (P180)San Francisco Convent and Church (Q18482735), for example. --Marsupium (talk) 12:10, 14 November 2017 (UTC)[reply]

@Marsupium: OK. I think I understood your rationale. As I am a relatively new to this project, I don't want to mess up :) BTW, your way of understanding why it makes sense to create itens for these pictures is also granted as, since the photographs were considered at the time to be "too small to see", they were reproduced as large paintings. So, for instance, this picture became Alegre Street, 1862 (Brigadeiro Tobias Street) (Q41564256). I am pretty sure there might a property for this kind of relationship. Thanks for paying attention to this, Marsupium! --Joalpe (talk) 12:18, 14 November 2017 (UTC)[reply]

@Joalpe: Oh, yes, one more cause to create an item for the Rua Alegre photo, I think based on (P144) is the way to go here. --Marsupium (talk) 12:25, 14 November 2017 (UTC)[reply]

More fun with Iconclass notations[edit]

Can we (should we?) say that an artistic theme (Q2160811) <depicts> something? See for example studying a map (Q43156374).

It seems rather circular. - PKM (talk) 23:39, 14 November 2017 (UTC)[reply]

Personifications[edit]

Here's a first cut at modelling personifications from Iconclass: Geometria (Q43236161). It's a lot of work. - PKM (talk) 01:09, 17 November 2017 (UTC)[reply]

Thank you for this! I'd like to suggest to merge personification (Q43231609) into personification (Q207174) and adapt personification (Q207174). There are already some of them, see this query. There are still a few personifications left to be created with Sandrart.net person ID (P1422). Often it is hard to decide if to create a separate item for a instance of (P31)Greek deity (Q22989102) or similar deity and the personification. If you have a good idea to find a common handling for this, let me know! Thanks again, --Marsupium (talk) 14:27, 17 November 2017 (UTC)[reply]

Thanks for the feedback. I went round and round in my head about whether we need one “personification” or two. The word is slippery - it can mean (at least in English) both the process of ascribing human traits to abstract concepts and the human figure who embodies abstract traits. Looked at this way, they are quite separate things in my view. I’m not surprised there are many 'art' instances at personification (Q207174) since I just created personification (Q43231609). However ...

Re: your question about deities, I think it's preferable to have one item that is both <instance of> "deity" and <instance of> "personification" where that applies. If for some reason we need to have two items - for instance, if Iconclass or some other source has separate IDs for the deity and that same deity-as-personification - we can always add <said to be the same as>.

And having thought through that puzzle, I now agree that we should merge-and-fix the two "personification" items. Clearly the literary trope of "Apollo driving his bright chariot" is in some sense the same things as a pictorial representation of the that idea.

Also, do you have a thought on whether "personification" is the opposite of "anthropomorphism" as wikidata says now? I rather think "personification" is an <instance of> or at least a <facet of> "anthropomorphism" but I haven’t found a reference that says so (Getty AAT has them in completely separate domains). At minimum I'd prefer "different from" rather than "opposite of".

Thanks for pointing out the unmatched Sandrart.net person ID (P1422) records. And thanks again for your response - having dialogue on these things really helps me get my thinking clear. - PKM (talk) 20:14, 17 November 2017 (UTC)

And an example of putting these bits all together: Arno (Q43268368). - PKM (talk) 21:36, 17 November 2017 (UTC)[reply]

personification (Q207174) merge completed and EN description updated. - PKM (talk) 02:09, 18 November 2017 (UTC)[reply]

I'd have said that "the process of ascribing human traits to abstract concepts" is an anthropomorphism. en:Anthropomorphism says "Anthropomorphism is the attribution of human traits, emotions, or intentions to non-human entities. It is considered to be an innate tendency of human psychology. Personification is the related attribution of human form and characteristics to abstract concepts such as nations, emotions and natural forces like seasons and the weather." I'd say so, too. Thus neither I do understand why they should be opposite of (P461) each other. I wanted o ping D1gggg to explain why they have created the statements, but they seem to be blocked, so I have replaced them with different from (P1889) statements and also removed the misleading "personification" as alias on anthropomorphism (Q132987).

I agree to the rationale for deities and personifications. --Marsupium (talk) 12:10, 24 November 2017 (UTC)[reply]

Iconclass links[edit]

@Marsupium: - Were you going to fix the formatter for Iconclass notation so that multipart links weork properly (needs - not + between words). If not, I'll ask at Project chat. Thanks! - PKM (talk) 21:00, 3 January 2018 (UTC)[reply]

@PKM:

The pattern has to be improved, but its handling of "+" is correct in my eyes. Could you give an example and tell what exactly doesn't work as it should?
Or do you mean the character encoding of the space " ", that from Mary Magdalene (Q63070)Iconclass notation (P1256)11HH(MARY MAGDALENE) the link is encoded as the not working http://iconclass.org/11HH(MARY+MAGDALENE) instead of the working http://iconclass.org/rkd/11HH(MARY%20MAGDALENE)/ ? That seems to be an issue with the software rather than the formatter pattern, kind of the opposite of phab:T142972.
Besides, Mix'n'match has "+" signs in the IDs, they get imported that way, but seem to be wrong.

I hope we can solve some of the problems with Iconclass on Wikidata soon! Let me know what you have meant exactly! --Marsupium (talk) 13:31, 4 January 2018 (UTC)[reply]

The link provided from Mix-n-match is incorrect. For Empire silhouette (Q30100628) is gives http://iconclass.org/rkd/41D211(CHEMISE-%C3%80+LA+REINE)/. I change the + to - and it works: http://iconclass.org/rkd/41D211(CHEMISE-%C3%80-LA-REINE)/. I assumed this was based on an error in the regex format on the property page, but if that's not the case I'll let Magnus know. I've been fixing bad items from MnM as I find them, but it would be nice to script this. - PKM (talk) 00:40, 5 January 2018 (UTC)[reply]

Hm, the IDs just get tested against the regex. The software creates the links with the value of formatter URL (P1630), but here the URL encoding of the spaces does not work. It is the same problem as here. Changing the IDs here (and via Mix'n'match) would more be a workaround, but perhaps better than dead links. --Marsupium (talk) 07:58, 5 January 2018 (UTC)[reply]

I asked for help on Magnus's talk page. - PKM (talk) 01:32, 7 January 2018 (UTC)[reply]

Tagging 17th century portraits[edit]

Here are some costume items to look for when adding <shown with features> to 17th-century portraits:

PKM (talk) 20:01, 8 February 2018 (UTC)[reply]

Also:

knotted tassel (Q2058626) (= NL 'aker')

PKM (talk) 21:56, 13 March 2018 (UTC)[reply]

Thank you for this list! I think we should replace shown with features (P1354) qualifiers to depicts (P180) with wears (P3828) qualifiers for cloths? --Marsupium (talk) 08:12, 31 March 2018 (UTC)[reply]

Armor[edit]

I've been cleaning up the class tree for armor/armour so we can separate the armor on a warship from armor worn by a knight. If you're tagging artwork as extant armor or using <shown with feature> on a painting, you can now use armour (Q50414774): protective clothing; armor worn on the body or one of its subclasses (as specific as your source allows). - PKM (talk) 21:54, 13 March 2018 (UTC)[reply]

Date when a monument is retired[edit]

What should be the correct property to show the date when a street monument has been moved (retired) from its place to a warehouse ?. Thanks Amadalvarez (talk) 19:37, 30 March 2018 (UTC)[reply]

@Amadalvarez: end time (P582)? I think we don't have anything more specific than that. Its subproperty dissolved, abolished or demolished date (P576) is for organizations. You can also add significant event (P793) with point in time (P585) qualifier, I can't find a good value yet existing for that now. --Marsupium (talk) 08:08, 31 March 2018 (UTC)[reply]

Thanks, @Marsupium:, I'll use significant event (P793) because in fact it has not dissapeared. It has been moved to a municipal storage, so, it's similar to be moved from one museum to another. Thanks, again. Amadalvarez (talk) 06:17, 1 April 2018 (UTC)[reply]

@Amadalvarez: Seems to be reasonable! Cheers, --Marsupium (talk) 08:02, 1 April 2018 (UTC)[reply]

New property proposal "has pattern"[edit]

Notified participants of WikiProject Visual arts

I've proposed a new property has pattern to record "Pattern, design, or motif intrinsic to, incorporated into, or applied to the surface of the subject". Comments welcome on the property proposal page. - PKM (talk) 21:22, 24 June 2018 (UTC)[reply]

Structured Data on Commons - community consultation on basic properties for media files[edit]

Notified participants of WikiProject Visual arts. Hello everyone! This month (July 2018), we are hosting a quite crucial community consultation on Wikimedia Commons: we are listing the Wikidata properties that media files on Commons will need (including ones that might not exist yet, and might need to be created for this purpose). The consultation runs at least till the end of July, maybe longer.

Please consider to take a look and give input. I'm sure that there are many more media files about visual arts items that need attention there. Thanks! SandraF (WMF) (talk) 12:39, 4 July 2018 (UTC)[reply]

Creator issues[edit]

Hi, I have found some issues with the Creator property while checking photographs:

We need the possibility to have a creator without an item.
attribution-debated macaque photos (Q17596101) is one such case, or do we create an item for the animal? This creates an error.
Family Portrait (Q1370491) and Pale Blue Dot (Q474472) This seems OK now, after I added these.

Comments and suggestions? Yann (talk) 11:22, 9 July 2018 (UTC)[reply]

@Yann: One mechanism to record a creator name without an item is to specify:

creator (P170) <some value>, qualifier object named as (P1932) "creator name".

One disadvantage is that QuickStatements isn't brilliant with <some value>, eg once one wants to replace it with an actual Q-number. But that may become more possible in time. Jheald (talk) 11:57, 9 July 2018 (UTC)[reply]

@Jheald: Thanks for your message, but I don't understand how to do that. Can you please give an example? Thanks, Yann (talk) 12:10, 9 July 2018 (UTC)[reply]

@Yann: Compare, for example, the statement for 'Publisher' at Q51423679#P213. Jheald (talk) 13:00, 9 July 2018 (UTC)[reply]

@Jheald: OK, I managed to add this, but it still gives an error. Actually, personalized value would be better than unknown value, but I can't add that. On the same page, copyright license (P275) with public domain (Q19652) gives an error. Regards, Yann (talk) 13:40, 9 July 2018 (UTC)[reply]

This is not satisfactory. On c:Category:Slave laborers in the Buchenwald concentration camp, the author is mentioned as "Unknown". It is quite known, but not notable enough to have his own WD entry. Regards, Yann (talk) 16:36, 9 July 2018 (UTC)[reply]

Changing the way we handle attributed artworks[edit]

A couple of years ago we created a bunch of properties to handle anonymous works, see #Anonymous works and the item structure documentation. All the properties except one indicate we're not sure who made it, but we have an idea in what area to look. The one property that is different is P1773 (P1773): We think someone made a work, but we're just not entirely sure. This property was created before we had widespread use of sourcing circumstances (P1480). I think we should change the way we handle attributed works.

Currently: creator (P170) -> anonymous (Q4233718) with qualifier P1773 (P1773) -> <some creator>
New situation: creator (P170) -> <some creator> with qualifier sourcing circumstances (P1480) -> attribution (Q50137645)

This is a relatively small change that improves the way we handle these cases, I'm not proposing a full overhaul of properties. Based on this query, this would affect about 750 items of which 650 are paintings.

Notified participants of WikiProject Visual arts WikiProject sum of all paintings has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. Multichill (talk) 11:34, 13 July 2018 (UTC)[reply]

Yes this looks like a reasonable change. I would prefer also to be able to link to the art historian directly somehow for the attribution, especially for cases where the attribution is distributed over 2 or three painters by 2 or three art historians/institutions. Jane023 (talk) 11:43, 13 July 2018 (UTC)[reply]

statement supported by (P3680) ? Also statement disputed by (P1310). Jheald (talk) 09:16, 15 July 2018 (UTC)[reply]

Excellent idea. - PKM (talk) 03:16, 15 July 2018 (UTC)[reply]

Good idea, adopted. I will switch my before use of the second option with sourcing circumstances (P1480) -> presumably (Q18122778) for P1520 (P1520) -> attribution (Q50137645), indeed better. Finally! Thanks --Shonagon (talk) 01:18, 18 March 2020 (UTC)[reply]

I never quite know the difference these days between sourcing circumstances (P1480) and nature of statement (P5102). Which would be more appropriate for this, and why? Jheald (talk) 09:20, 15 July 2018 (UTC)[reply]
Support Good idea! This lets us query the creators directly by creator (P170) mainsnak value which has advantages and disadvantages. But I think the advantages are predominating, in most situations you will also want to have attributed works I guess. It also enables us to express "attributed to the workshop/school/… of John Doe" So after move of the statements send P1773 (P1773) to Wikidata:Properties for deletion? (I've left a link here on the property talk page.) --Marsupium (talk) 22:03, 15 July 2018 (UTC)[reply]

I updated the item structure page. That might attract some more people here. Let's wait a bit and go to the next step: Conversion. Let's see if the property is still needed after that and if it's not the case, nominate it for deletion. Multichill (talk) 10:05, 28 July 2018 (UTC)[reply]

@Multichill: I see there is also a property possible creator (P1779). Does that property still have a purpose? When should it be used, rather than giving multiple attributions together with qualifiers statement supported by (P3680) etc.

Second question: how to indicate: "attributed to Titian AND Giorgione" (jointly), as opposed to "attributed to Titian" AND "attributed to Giorgione" (where there is disagreement) ?

Also: I have changed sourcing circumstances (P1480)="attribution" to nature of statement (P5102) as qualifier in the item structure, as I believe this is now the preferred qualifier to indicate an issue with the nature of a statement. Jheald (talk) 23:12, 31 July 2018 (UTC)[reply]

Jheald, (better late than never) I think we should say bye to possible creator (P1779) as well. --Marsupium (talk) 22:29, 29 November 2019 (UTC)[reply]

Pietro Stefanoni - help?[edit]

There seem to be two people named Pietro Stefanoni - a publisher born 1557 and an engraver born 1589, though their dates overlap. I have split the items Pietro Stefanoni (Q16590538) and Pietro Stefanoni (Q56334603), but I am not certain these aren't the same person after all with confusion on the dates. Can someone else take a look? - PKM (talk) 02:31, 30 August 2018 (UTC)[reply]

Belated reply: No articles or information for differentiation from my favorite source Allgemeines Künstlerlexikon (Q15791802), Thieme-Becker-Vollmer (Q1361256) seems to have something, but not online for some unfortunate, strange reason; I try to remember to look into it when I'm in the library. --Marsupium (talk) 02:49, 20 October 2018 (UTC)[reply]

Item Structure for Printed Works[edit]

Hello,

I wanted to know if the creation of a page Wikidata:WikiProject_Visual_arts/Item_structure/Prints, in the manner of the already existing Sculptures, would be pertinent. The nature of printed works of art is a sensitive matter, that has already been discussed in prior discussions such as Notability and artwork, how to record artists, engravers, publishers or more importantly Questions Artwork with Multiple Executions just within the Visual Arts Project. I believe it needs its own thinking process, with a dedicated page to gather wikidata items and properties around prints, define a clearer standard, automation strategies and tools for the completion and addition of items, and to present more specific projects, like Print Room of the University of Antwerp (Q47885560).

I would like to work on that page with you, to better rationalize the expression of prints on wikidata, taking inspiration in the Wikiproject Books, CIDOC and FRBRoo, how to organize the pages, with a division similar to that between Work, the Edition and Individual Exemplar.

Taking the example of The Great Wave off Kanagawa (Q252485), there are three linked exemplars: Met's impression, British Museum's and LACMA's mentioned with the property has part(s) (P527). This parent element however, based on the Wikipedia page, also presents descriptive elements specific to the Tokyo National Museum's exemplary. But maybe the property exemplar of (P1574) and its (not yet existing) opposite, or new properties inspired by it could be used instead of has part(s) (P527) and part of (P361). A strict difference must be made with artworks like paintings who know copies and series but who do not originate from the same plate or ensemble of plates (or casts in sculptures), even though there can be different editions in time, alterations of the plates, treatments in the printing process etc that have to be mentioned if need be (in the parent item, the exemplar, or an intermediary?).

I know many things have already been thought, discussed and applied before I got here, but I would really much like to help, and prints being one of my main areas of study, I wish I could start there. Thanks for your replies and suggestions!

Rhesusnegatif (talk) 17:54, 19 October 2018 (UTC)[reply]

I only see this now. The structure, if agreed and implemented, should be like the one for books and Wikisource. In fact, for individual engravings with lots of metadata, it woud probably be a good idea to publish these on Wikisource first and take it from there (along the lines of individual encyclopedic entries of people, but this time for prints). Jane023 (talk) 11:26, 24 November 2020 (UTC)[reply]

Relationships between artworks[edit]

We need more properties to connect interrelated artworks. As Vladimir Alexiev pointed out, some external ontologies already exist, like CCO and CONA that both have a set of properties for that. Actually, the two sets have much in common. They have relatiosnhips like "depicts" and "pendant of" that also exist in Wikidata. But there are also others that we currently do not have.

So what should we do ? I think we should just propose properties one by one, and see how it fits in Wikidata. The alternative would be to discuss the whole problem to get the "big picture" first. But by experience, this approach does not seem to be really productive in Wikidata.

A while ago, I proposed a Wikidata:Property proposal/Study for. The property is present in both CCO and CONA, but the property was not created, and imo is still very much needed. I think we should reopen this property and create new proposals for other relations that seems useful. Zolo (talk) 11:07, 3 November 2018 (UTC)[reply]

@Zolo: - I missed your proposal and proposed the same thing, which was created as study or design for (P6606). I think we should propose new properties for these relationships. I'll support this effort. - PKM (talk) 22:24, 4 April 2019 (UTC)[reply]

Preferred rank for differing dimensions[edit]

For Lady Margaret Beaufort (Q62761459), I have two sets of dimensions, one from the current issue of The Burlington Magazine and one from Art UK (presumably from the holding institution). Which one should be preferred or deprecated? - PKM (talk) 22:27, 4 April 2019 (UTC)[reply]

@PKM: I think neither should be preferred or deprecated as long as we don't have a reason to consider one more correct than the other. --Marsupium (talk) 19:24, 7 April 2019 (UTC)[reply]

@Marsupium: thanks, that's easy. - PKM (talk) 20:05, 7 April 2019 (UTC)[reply]

Property proposal "motif represents"[edit]

Members of this project may wish to weigh in on this property proposal for linking a motif to its source. - PKM (talk) 20:27, 27 May 2019 (UTC)[reply]

Motifs & artistic themes[edit]

I'm doing a lot of work on cleaning up decorative motifs. (Worklist here.) We have a few items like The Triumph of Bacchus and Ariadne (Q123907) that are tagged as "motif" but I think should be "artistic theme" instead. My general thinking is that:

A motif (Q1229071) is a simple element that can be replicated as part of a recurring pattern, though it need not be in all instances.
An artistic theme (Q1406161) is a person or event in a context, usually not repeated to make patterns, see Virgin and Child with Saint Anne (Q563707).
A very few items are both, see Rose and nightingale (motif) (Q64462170).

Does anyone have thoughts on this distinction? Is motif generally used more broadly in some languages? - PKM (talk) 19:51, 8 June 2019 (UTC)[reply]

Property for art style?[edit]

We have properties to indicate an item's art movement (Q968159) (movement (P135), art genre (Q1792379) (genre (P136)), and architectural style (Q32880)(architectural style (P149)), but we don't have a property to indicate art style (Q1792644). I've proposed adding "art style" as a valid value for genre (P136) on its Talk page - it already accepts "art movement" and "music style". Can you weigh in there? - PKM (talk) 21:16, 9 July 2019 (UTC)[reply]

Instance of "canvas"[edit]

There are a number of items, mostly in a Chinese context, that are oil paintings marked as <instance of> canvas (Q12321255). These should probably be batch-changed to <instance of> "painting", with "canvas" added to <material used>. Does anyone want to take these on? - PKM (talk) 21:13, 17 July 2019 (UTC)[reply]

Wikidata:Property proposal: askArt person ID[edit]

Please see Wikidata:Property proposal/askArt person ID. Cheers, -Animalparty (talk) 01:26, 4 November 2019 (UTC)[reply]

Changing the way we use anonymous (Q4233718)[edit]

Notified participants of WikiProject Visual arts

On the village pump a conversation is happening about how we should handle anonymous (Q4233718). Please have a look. Multichill (talk) 19:31, 17 March 2020 (UTC)[reply]

Based on Wikidata:Requests for comment/Cleaning up the ontology of anonymous I've updated Wikidata:WikiProject_Visual_arts/Item_structure#Use_of_creator_(P170)_in_uncertain_cases and created Wikidata:WikiProject sum of all paintings/Anonymous creator. I will start updating paintings to the new model. Multichill (talk) 11:15, 30 May 2021 (UTC)[reply]

Sculpture: best practices for groups of casts[edit]

I realize there may not be any best practices yet, but how should multiple casts be structured, dated, and linked? For example The Thinker (Q18003128) and The Broncho Buster (Q95984336). Often the initial sculpture goes through multiple castings, each of which ends up in different museums with their own histories. In the examples above, the "parent" item is a group of casts (Q28890616), which can then defer to individual castings (e.g. The Thinker (Q60759083) and The Thinker (Q154571)). Should we use has part(s) (P527) and part of (P361) to connect the individuals to the group, or something better? And for the individual castings, what value(s) should be their instance of (P31), and how can we best portray the different dates of design and casting? See for instance Q83559806#P571. -Animalparty (talk) 19:43, 1 June 2020 (UTC)[reply]

I have a similar question about if this project recommends one way or another. I'm work at a museum and have been working with our sculpture curator to ask what makes sense to her. I've shown different examples of how it's been done, and she felt the approach taken in The Broncho Buster (Q95984336) made the most sense. That's what we're doing for now, but would love to hear what the preferred way is given the pros and cons of different approaches.

We added respective has part(s) (P527) and part of (P361) relationships, and for instance of, use work with multiple executions (Q28886448) as well as group of casts (Q28890616) if they are casts. Some examples of this are here: Puck (Q113454530) and Gamin (Q113454572). In both cases, the curator confirmed that these were editions of the same work, and in both cases I did end up having to create a new item to serve as the item that represents the work on a more conceptual level, then attached some of the existing editions from other museums to it, including the new one I created for our museum.

I wasn't sure, but decided not to use group of sculptures (Q2293362) for instance of because the meaning was ambiguous to me. Was this the same as a sculpture group that consists of multiple sculptures that were intended to be arranged together? Or was this generic for any group of multiple sculptures that have any kind of relationship? Both?

Sonoet2 (talk) 15:41, 14 November 2022 (UTC)[reply]

Fragmentary Object: Best Practices[edit]

Hi all, new editor here. I'm looking for guidance on how best to model fragmentary archaeological objects in a museum's collection. In many of the cases I'm dealing with, the preserved object is fragmentary and is the only portion of the object preserved. So for example, we have a fragment of a neck of a bottle, but no other portions of the total object. We wouldn't want to model this as a "bottle" since it is incomplete, but "Part of" "bottle" doesn't preserve the descriptive information 'neck'. Can anyone point me to some fragmentary object parallels that are well-modeled that might serve as exempla? Ahc84 (talk) 19:39, 7 September 2020 (UTC)[reply]

@Ahc84: I'm sorry you never got an answer to your question. You can use instance of (P31) fragment (Q11086567) qualified with <of> "bottle"; see these examples: Kouros statue (Q1024327); Fresco Fragment, Yale University Art Gallery, inv. 1930.584 (Q49292637). For textile fragments, I usually use <instance of> (textile type) + <instance of> "fragment", as here: Oseberg tapestry fragments (Q25055791). - 21:14, 23 November 2020 (UTC)

Prints: subclasses vs attributes for genre/form, technique, materials[edit]

Notified participants of WikiProject Visual arts

Further to User:Rhesusnegatif's post above (#Item_Structure_for_Printed_Works), about establishing an item-style guide for prints, one question every Wikidata project faces sooner or later is where the line should be for individual objects between making them instance of (P31) some specific subclass, versus using a property to represent that information. For example, for some print, do we say it is instance of (P31) = aquatint print (Q18396864); or do we say that it has fabrication method (P2079) = aquatint (Q473236) ?

I was curious as to what we think best practice is for this, as I am currently working towards prepping an upload (work in progress). So I've put together a page of Listeria queries to get some idea of the balance of current practice:

Wikidata:WikiProject_Visual_arts/stats/prints

From the numbers from the queries, it looks like we very strongly prefer a generic P31, eg instance of (P31) = print (Q11060274) (or perhaps individual copy of a print (Q75837457)?), with properties fabrication method (P2079), genre (P136), made from material (P186), etc, rather than subclasses, to describe its genre, form, type, materials, etc.

So:

Are we happy that this is the right way to go? Are there any exceptions, that are special? (eg do we prefer instance of (P31) = woodblock print (Q28913685) for something like The Great Wave off Kanagawa (Q28912605)? Or is individual copy of a print (Q75837457) sufficient?)
Should we indeed start creating an item style-guide for prints, as User:Rhesusnegatif suggests?
To what extent should we start trying to conform existing items to the style (eg replacing specific instance of (P31) values with more generic ones, plus properties?)

At the very least, the stats pages show there are some clear errors we should presumably try to fix, eg

fabrication method (P2079) = engraving (Q11835431) ----> fabrication method (P2079) = engraving process (Q139106),
made from material (P186) = lithography (Q133036) ----> fabrication method (P2079) = lithography (Q133036),
made from material (P186) = burin (Q9239042) ----> ???

A couple of further things:

We should make sure that c:Template:Artwork can display fabrication method (P2079) (or perhaps fabrication method (P2079) -> product or material produced or service provided (P1056)). Do we have any more preferred label for how this should be displayed (ideally with a set of internationalisations?)
Does the more recently created property form of creative work (P7937) have any role for prints, beyond what is already covered by genre (P136), fabrication method (P2079), made from material (P186) ?

What are people's thoughts? Jheald (talk) 20:38, 23 November 2020 (UTC)[reply]

I've raised a very similar discussion – but with broader focus: artistic creations in general – about this topic a month ago on the talk page of WikiProject Cultural Heritage. That discussion didn't have many participants and I'm not sure if I can say we reached consensus there. But personally, after thinking about it a bit longer, I'm still in the 'let's use a generic P31 and refine through other properties' camp, also because I've recently noticed a few times again that a query for deep subclasses of a generic P31 tends to become very slow very quickly. Performance of the SPARQL service shouldn't be the major argument, but it does play a role I think. Spinster 💬 20:53, 23 November 2020 (UTC)[reply]

@Spinster: Thanks for that, Sandra, that's really useful. Specifically on the queries, one trick that can sometimes help is to flip round the P279 statement in the query, ie wd:Q11060274 ^wdt:P279*/^wdt:P31 ?print rather than the other way round. Not really sure why this tweak should work, but sometimes it does seem to make a difference. Jheald (talk) 21:18, 23 November 2020 (UTC)[reply]

Strongly support defining and documenting best practices in this area. I don't believe the Artwork template pays attention to "fabrication method" today - @Jarekt: can you confirm? (Jarekt has been extremely helpful in expanding the Artwork template mapping - so once we decide how we want this to work ...) - PKM (talk) 21:23, 23 November 2020 (UTC)[reply]

I also would support and be happy to collaborate on a style guide for prints. The problem I see is that we need to define relationship between print (Q11060274) or woodcut print (Q18219090) which is like a unique book printing and individual copy of a print (Q75837457), which would be a individual single copy of a book. About 90% of properties should be identical between print (Q11060274) and individual copy of a print (Q75837457).

I was lately working on en:List of woodcuts by Albrecht Dürer organizing over a thousand prints and creating items for them or matching them to existing items. I strongly prefer woodcut print (Q18219090) over just print (Q11060274) and I do like to use both instance of (P31) and fabrication method (P2079).

PKM, I just checked the source code of c:Module:Wikidata art and p.get_medium function uses both made from material (P186) and fabrication method (P2079) are used. made from material (P186) is translated into inputs of c:template:technique using c:Module:Artwork/Technique LUT, while fabrication method (P2079) is used directly. The fabrication method (P2079) is only used if output based on made from material (P186) returned nothing. --Jarekt (talk) 22:50, 23 November 2020 (UTC)[reply]

Jarekt, thank you for explaining that. - PKM (talk) 00:28, 24 November 2020 (UTC)[reply]

@Jarekt: What this is doing is really impressive.

I tried to write a query to find examples of this in action, but sadly as MWAPI can only retrieve 10,000 items from a category, it only found a handful out of the ones that are presumably there tinyurl.com/y4y23tpo Any input on how to write a better query very welcome!

I do wonder though, if only using fabrication method (P2079) when made from material (P186) returns nothing might be quite a limitation -- eg we might have a number of aquatints or copper engravings with a note of the kind of paper they were printed on. Also, we might have more than one value of fabrication method (P2079), eg both "aquatint" and "hand coloured". So there could be room to take this further.

Comparing c:template:artwork and c:template:map (eg middle columns here), there are a number of things relevant to prints that can be specified on the Map template (now running on Lua! As of yesterday!! Yea!!! though not drawing anything from wikidata), but not yet on the Artwork template -- eg, in particular, publisher (or printer) and place of publication, which will usually be given on a print. Also sometimes "published in", if the print originally appeared in a larger work.

Another thing for prints is that we will generally have both an artist and an engraver. Do we have a preference for how to indicate these (and what can the template cope with?) Because my data is coming from a library catalogue, I would quite like to use creator (P170) and contributor to the creative work or subject (P767), with object has role (P3831) to identify exactly the role of each. (That would exactly match the source info from the library). Would it be possible to make the template show a object has role (P3831) qualifier for creators? On the other hand, it looks as if people may also have been using after a work by (P1877), so that might also be something to consider.

Finally, would it be easy to make the template handle <somevalue> / object named as (P1932) combinations? I'm not sure it can quite do this at the moment, but it could be so helpful for workflow to be able to get the images up initially with strings for eg creator names, etc on wikidata, and then (later) to be able to come back and replace those strings with Q-numbers on wikidata, and for the image description to automatically update on Commons, without having to be edited.

Thank you so much for all you have done and are doing with these templates. It really is transformative, of what's possible and how we can go about things! Jheald (talk) 14:01, 24 November 2020 (UTC)[reply]

@Jheald: today, the Artwork template picks up “applies to part” but not “object has role” - see example at c:File:Wawel Arras The Confusion of Tongues.png. So you could theoretically capture this using <applies to part> “drawing”, “engraving”. - PKM (talk) 01:38, 25 November 2020 (UTC)[reply]

@Jheald: Congratulations for getting c:template:map of the ground. It is great to hear that it is Lua based now. Feel free to cannibalize c:Module:Artwork and use c:Module:Wikidata art as much as possible.

Also c:template:artwork and c:template:Book share 99% of the code now so any field one has is also available for the other, so publisher, printer and place / year of publication are supported by c:template:artwork. They are rarely used (for paintings etc.) but they should work.
About creator/engraver: If the source says that the print was made by Albrecht Durer than I would just use "creator". But if the description says that it was engraved by C based on drawing by Y than I would use object has role (P3831) to indicate it. Qualifiers object has role (P3831) are supported by c:Module:Artwork and you can reuse that code.
Qualifier after a work by (P1877) is also supported, as well as, P1773 (P1773), workshop of (P1774), workshop of (P1774), follower of (P1775), circle of (P1776), possible creator (P1779) and school of (P1780)
About object named as (P1932), I thought it was reference only property, so I would have to see how it is used as qualifier. In case of names I would use author name string (P2093), which is supported by Artwork (as property not qualifier)

--Jarekt (talk) 02:54, 25 November 2020 (UTC)[reply]

Jarekt, thanks for your input! I'm curious: when you say I strongly prefer woodcut print (Q18219090) over just print (Q11060274) – why is that? Cheers, Spinster 💬 09:41, 24 November 2020 (UTC)[reply]

I strongly prefer just print (Q11060274) for the same reasons we just use just painting (Q3305213) for WD:SOAP. Jane023 (talk) 11:30, 24 November 2020 (UTC)[reply]

@Spinster: I was working on List of woodcuts by Albrecht Dürer (Q6645536), both on Commons and on Wikipedia, and separating woodcut print (Q18219090) from drypoint print (Q23657281), copper engraving print (Q18887969) and etching print (Q18218093) was a big part of it. It was especially tricky if fabrication method (P2079) was not used. --Jarekt (talk) 02:04, 25 November 2020 (UTC)[reply]

Hey all, I'm working on making Commons display of fabrication method (P2079) and made from material (P186) together possible. Currently, the problem is modelling of the order of materials/methods which is especially important to ensure data moved here from Commons will look the same on Commons after move of the data's hope. I was about to ask you here for input how to do it before this post. My suggestion is to use series ordinal (P1545) qualifiers on fabrication method (P2079) and made from material (P186). Then Commons template code can sort them as indicated by that. Then c:Module:Wikidata art's function p.get_medium() can be adapted to let c:Module:Technique do the rest of the work. (Already working, still a bit of work needed to make that possible.) --Marsupium (talk) 12:01, 25 November 2020 (UTC)[reply]

@Marsupium: I am not sure about series ordinal (P1545), though it might make sense for the order of techniques applied (eg intaglio printing, then hand-colouring). For material used, perhaps object has role (P3831) might be better. Regarding information we should be thinking how to code, also of interest might be positions 4 and 5 of MARC code 007, used in library catalogues to indicate "primary support material" and "secondary support material". The first of these terms "primary support material" might be a good value for object has role (P3831) to indicate a match to/from the 'on' parameter of c:template:technique, while the second might be a good indication for the 'mounted' parameter.

Looking at MARC 007 one further question I've been wondering about is how best to code position 3 "color" for wikidata. fabrication method (P2079) = "hand-colouring" might be appropriate for handcoloured; but do we have a good way to represent that a work is in black-and-white / one colour / multicoloured ? Jheald (talk) 14:02, 30 November 2020 (UTC)[reply]

So far series ordinal (P1545) does appear to have been used with fabrication method (P2079), but only in connection with cooking: https://w.wiki/ooR . On the other hand, quite a few examples of artworks with multiple values of fabrication method (P2079) without the qualifier: https://w.wiki/ood Jheald (talk) 14:44, 30 November 2020 (UTC)[reply]

Collections modelling[edit]

There is an unclarity about collection (P195). This property is defined as "art, museum, archival, or bibliographic collection the subject is part of". However, most of the items link not to "museum collection" (defined as instance of art collection (Q7328910), but to the museum (instance of art museum (Q207694), museum (Q33506) or other). I have started to improve this imperfection for the area of the Czech Republic, where collections are registered by the Ministry of Culture. See collection of the National Gallery Prague (Q101034183), for example. Then, I have started to replace "museum" in collection (P195) by "museum collection" in accordance with collection (P195) definition. See example.

However, @Multichill: stopped me, although he was not able to bring some relevant argument against the collection (P195) definition. See User talk:Daniel Baránek#Mass removal of collections.

So, I would like to know Your opinion, how to model visual arts items. I propose this:

collection (P195): If it is possible (if the relevant entity exists), set this property to a entity, which is defined as instance of art collection (Q7328910). This corresponds to the collection (P195) definition.
owned by (P127): This property is clear: owner of the item. However, the owner is not always identical with administrator. For example, items in collection of the National Gallery Prague (Q101034183) are owned by state Czech Republic (Q213) but administrated by National Gallery Prague (Q1419555).

So there is problem, how to describe the administrator (i.e. museum/gallery) of the item:

In the current model, the property for administrator/operator is not set. In most cases, this is solved by collection (P195) = "museum/gallery", however as stated above, this doesn't match with collection (P195) definition.
Sometimes, the administrator is defined in location (P276). However, this property is rather of geographical, not institutional character. This property is not very clear. Should it link to city, museum or building/museum department? Because some museums (as institution) has many buildings (sometimes even in more towns). For example, Šumperk Museum of Natural History (Q21685652) has its branches: Q87982878 in Mohelnice (Q587388), other branch in Zábřeh (Q246634) and other towns. I think, this property is not suitable for "museum".
I think, the administrator of the item, should be defined by maintained by (P126) (defined as "person or organization in charge of keeping the subject (for instance an infrastructure) in functioning order"). Some items has operator (P137), but I think its not the right property as its definition is "person, profession, or organization that operates the equipment, facility, or service; use country for diplomatic missions" – visual arts items are not equipment, facility, nor service.

Thanks for Your opinions. --Daniel Baránek (talk) 09:23, 23 November 2020 (UTC)[reply]

Notified participants of WikiProject Visual arts

Moved here from Wikidata talk:WikiProject Visual arts/Item structure to get broader input. Multichill (talk) 12:03, 27 November 2020 (UTC)[reply]

Worth noting, in passing, that collection (P195) can be used hierarchically. Here's a query https://w.wiki/oLi that looks for Level-1 collections that contain Level-2 collections that contain Level-3 collections that contain items. Most of the returns are the results of errors that need fixing, but some are not, eg:
- British Library (Q23308) -> King George III Topographical Collection (Q56753539) -> ... -> ...
- National Library of Wales (Q666063) -> NLW General Manuscripts (Q21561323) -> ... -> ...

This kind of structure can be very useful to run queries within a particular identifiable part of an institution's full collections. Jheald (talk) 21:22, 27 November 2020 (UTC)[reply]

I don't particularly see much advantage in introducing "British Library collections" as a new item. In most cases this would just be extra complication and fragmentation. It would also break eg c:template:artwork's efforts to find the right Institution template. Jheald (talk) 21:32, 27 November 2020 (UTC)[reply]

On the location point, that is what location (P276) is for on an artwork item. A collection can be spread over multiple locations. Jheald (talk) 21:37, 27 November 2020 (UTC)[reply]

For private collections, I always make a new item for the collection itself: Roy Strong Collection (Q104782663). And I have made collection items for some institutions that are not museums or art galleries or the like: Mobilier National Collection (Q83569208), which is part of a government department. did not do this for the Cathedral of St John the Divine, which is similar to a museum in this context: Life of Christ (Q94998759). I think the combination collection and (some types of) institution is extremely useful even if not extremely precise ontology. - PKM (talk) 20:55, 22 March 2021 (UTC)[reply]

As a result, some paintings have collection (P195) National Gallery Prague (Q1419555), while some paintings collection (P195) collection of the National Gallery Prague (Q101034183). As a result, queries like Wikidata:WikiProject sum of all paintings/Collection/National Gallery in Prague, Wikidata:WikiProject sum of all paintings/Collections by number of paintings with image or Wikidata:WikiProject sum of all paintings/Top collections by number of paintings are "broken" (showing numbers separately for National Gallery Prague (Q1419555) and collection of the National Gallery Prague (Q101034183)). This is not an ideal result in my opinion.--Jklamo (talk) 11:38, 5 October 2021 (UTC)[reply]

New property "has graphical element"[edit]

A new property has graphical element (P9344): mark, motif, coat of arms, map, or other graphic element added to a creative work has been approved. There is some discussion of the fine points of modeling on the property Talk page. - PKM (talk) 20:59, 22 March 2021 (UTC)[reply]

Original location[edit]

On which property should the original location of a work be reported? I am not referring to the first owner or patron, but the place by which the work was created and from which it has been moved, to a museum, for example. The most common case is religious altarpieces, whether wooden or frescoes, which were created by a church and have since been dismantled and often sold in pieces. Usually, reference is always made to the original place to refer to the work. If it were a painting commissioned by a person who has subsequently been sold (one or more times) it would appear in the owners history. But in the case of the religious art of churches, they are not referring to the owner, but to the location. I would appreciate your suggestions. Thanks, --Amadalvarez (talk) 16:17, 26 April 2021 (UTC)[reply]

@Amadalvarez: location of creation (P1071) for the location where the work was created. For every location where the work has been since it's creation you can use location (P276) with qualifiers like start time (P580) and end time (P582) or point in time (P585). You can give the current location the preferred rank. If you do the same for collection (P195) and owned by (P127) than you end up with quite a nice provenance overview. Multichill (talk) 17:33, 26 April 2021 (UTC)[reply]

Thanks, @Multichill:. Mmmmm, the present use of P1071 is not too much close with my case. In case of items with P31=painting (Q3305213) they point to a country and probably will better apply country of origin (P495), instead. With P31=work (Q386724), we have only 23 and all of them point to a city, not to a building (church in my case). In addition, P1071 requires be accompanied with P495 which is redundant when the P1071 value is already a country. So, probably you're right but I'd like to reinforce the idea of "made to be installed in", not "where was created". Obviously, an altarpiece or a fresco is usually assembled / created "in situ", but looking the present values I understand P1071 closer to "the geographical place where piece was built" than the "place for which the piece was created". I use it in Panel of Sainte Eugene (Q106623072), but I wish to be sure before expand to other cases. --Amadalvarez (talk) 22:33, 26 April 2021 (UTC)[reply]

@Multichill: Looking for a classical and very know masterpieces, we can see that "original place" is sometimes included as:

part of (P361), in Parthenon Frieze (Q3087894) & Luxor Obelisk (Q1503331). Doesn't like to me, because "it's no longer"
location of discovery (P189), in Winged Victory of Samothrace (Q216402), Rosetta Stone (Q48584) & Parthenon Frieze (Q3087894). True in the two first, but not applicable when the source is known. And it sounds absolutely ironic, in last example.
location (P276), in Luxor Obelisk (Q1503331), both, original and present. Winged Victory of Samothrace (Q216402) already has P276, but only the present place, in Louvre.

Thanks, again. Amadalvarez (talk) 05:30, 27 April 2021 (UTC)[reply]

Canvasing about canvas[edit]

We currently have canvas (Q4259259) for the general concept of canvas (used for sails, roofs and painting among other things) and canvas (Q12321255) for the specific kind of canvas to paint on. All documentation, code and most items (200K vs 28K) currently use canvas (Q4259259). I propose we switch all usage on paintings of made from material (P186) to canvas (Q12321255). I would like to have some solid consensus before doing such a big change. Multichill (talk) 17:44, 26 April 2021 (UTC)[reply]

Notified participants of WikiProject Visual arts

Support --Marsupium (talk) 17:49, 26 April 2021 (UTC)[reply]

Support --Edelseider (talk) 17:55, 26 April 2021 (UTC)[reply]

Support Jane023 (talk) 18:16, 26 April 2021 (UTC)[reply]

Support Definitely concur. Fuzheado (talk) 18:31, 26 April 2021 (UTC)[reply]

Support Please! - PKM (talk) 19:10, 26 April 2021 (UTC)[reply]

Support Is the question whether of all instances of paintings made on ‘canvas’ should be differentiated from being painted on sailcloth - then yes! While we’re at it: what’s an example of something being used upon canvas (Q4259259) that is correct? Wittylama (talk) 19:52, 26 April 2021 (UTC)[reply]

Support At least, this known issue will have a solution. Thanks! French description of canvas (Q4259259) has been updated. --Shonagon (talk) 21:43, 26 April 2021 (UTC)[reply]

Support Amadalvarez (talk) 22:36, 26 April 2021 (UTC)[reply]

Support --Wuselig (talk) 10:05, 28 April 2021 (UTC)[reply]

Support I think you have "some solid consensus".--Jarekt (talk) 18:16, 15 May 2021 (UTC)[reply]

Thanks for your responses and support. I'll start updating some things. Multichill (talk) 09:47, 14 May 2021 (UTC)[reply]

Done bot replaced all usage. I do notice that quite a few statements (41055) miss the qualifier applies to part (P518) -> painting support (Q861259). I'll probably fix that too. Multichill (talk) 10:00, 16 May 2021 (UTC)[reply]

Added documentation at Wikidata:WikiProject sum of all paintings/Made from material. Multichill (talk) 20:05, 16 May 2021 (UTC)[reply]

Pondering about panels[edit]

Especially for older paintings panel (also called wood) is an often used painting support (Q861259). Looking at the query for most often used made from material (P186), you'll see that our current modeling is quite inconsistent; It's a mix of wood (Q287), panel (Q1348059), oakwood (Q2075708), poplar wood (Q291034), etc. Just like with canvas (see previous topic) panel (Q1348059) has multiple usage/meanings

Panel as a painting surface
Wall panels (that happen to be painted to make things more complicated)
Door panels

Sources often say just "panel" or "wood", but also quite a few cases where the type of tree used to make the panel is indicated. We don't want to loose that data! I propose we'll model it like this:

A new panel item for the panel used as a painting surface (like canvas (Q12321255)) where we know it's made of wood, just not what type
New items for panel by type of tree like "panel made of oak" or "panel made of poplar". These are all subclasses of the previous generic painting panel item

Instead of the subclasses we could also use qualifiers, but I think that will make things more messy and complicated.

Is this the right way to go forward? Would be great to have things cleaned up before I have my import bots also handle things like "oil on panel". Input appreciated! Multichill (talk) 15:38, 14 May 2021 (UTC)[reply]

Notified participants of WikiProject Visual arts

I think items for each common type of wood panel would be useful. We also need a "copper panel" item for paintings on copper, which now use the element copper. Jane023 (talk) 17:56, 14 May 2021 (UTC)[reply]

Sound good. From a purely logical point of view though, "panel" seems more like a type of object than a type of material. So, using "wood" or "poplar wood" rather than "panel" or "poplar panel" might be more consistent. -Zolo (talk) 13:33, 15 May 2021 (UTC)[reply]

Raw materials (wood, iron, etc.) and processed materials (plank, nail, etc.) are all materials. I don't think it's logical to refer to the raw material when in fact the processed material was used. Multichill (talk) 14:08, 15 May 2021 (UTC)[reply]

For me, a panel is not merely the materials; it's part of the work. Simon Cobb (User:Sic19 ; talk page) 19:17, 15 May 2021 (UTC)[reply]

I like "oak panel", "poplar panel", etc. 16th-century paintings sometimes specify "Baltic oak panel" and "French oak panel". I'd like to make these two specific subclasses of "oak panel". - PKM (talk) 20:42, 15 May 2021 (UTC)[reply]

Made the first new items:

panel (Q106857709): painting support made of a thin wooden plank to replace wood (Q287) (only when it has applies to part (P518) -> painting support (Q861259)) & panel (Q1348059))
oak panel (Q106857823): painting support made of a thin oak wood plank to replace oakwood (Q2075708) (only with qualifier)
poplar panel (Q106857865): painting support made of a thin poplar wood plank to replace poplar wood (Q291034) (only with qualifier)

The "Baltic oak panel" and "French oak panel" sound extremely specific so not really sure about that part. Let's just see how that evolves in the future? I looked at the counts at the RKD for paintings: Canvas: 67326, panel: 47903, copper: 4138, unknown: 3767, oak panel: 3664, canvas on panel: 812, cardboard: 468. So no big numbers for other types of wood. We probably need to give copper, canvas on panel and cardboard a bit of attention later.

We also have fiberboard (Q1397443) and plywood (Q219803) but I think these need a bit more digging because it looks like this sometimes refers to wood of the frame (like in this picture). Do we have a suitable qualifier for that?

I'll do some first replacements and imports. Let's see if we run into any other issues. Multichill (talk) 11:07, 16 May 2021 (UTC)[reply]

Added documentation at Wikidata:WikiProject sum of all paintings/Made from material. Multichill (talk) 20:05, 16 May 2021 (UTC)[reply]

In majority of cases I run into the source just says "Oil on panel" or "oil on wood", but sometimes I do see which type of wood. Also for modern works the panel might be plywood or even hardboard [8]. I like the changes proposed above. --Jarekt (talk) 01:38, 17 May 2021 (UTC)[reply]

@Multichill: Thanks for making the new panel types. The French oak panels were an important part of the attribution of Queen Elizabeth I (1533–1603) (Q106307469) and Sir Amias Paulet (c. 1533–1588) (Q106307522) to Nicolas Hilliard while he was working in France - I'll update the items. ThenI'll try to remember which ones were specific about Baltic oak (some of the Wewycks, I think...). - PKM (talk) 21:35, 1 June 2021 (UTC)[reply]

"Oak panel" with "country of origin = France" works nicely. Now I need to think of how to model a "region of origin" for Baltic oak. - PKM (talk) 21:47, 1 June 2021 (UTC)[reply]

@Multichill: I needed fruitwood panel (Q107157836), so I made it. - PKM (talk) 00:05, 9 June 2021 (UTC)[reply]

@PKM: I noticed we lime panel (Q107296639) is a duplicate so I merged it.

@Shonagon: could you have a look at your past Joconde imports? These show up in queries like https://w.wiki/3SDX and https://w.wiki/545o . Maybe it's possible to improve these? Multichill (talk) 11:52, 15 April 2022 (UTC)[reply]

Hello Multichill I undertsand the will to be now more precise on the wood pannels but, sorry, don't know how to mass those edit qualifiers. The specific wood pannel elements did not exist when the items were created. Best regards --Shonagon (talk) 05:35, 16 April 2022 (UTC)[reply]

I agree completely. The museums state e.g. poplar wood or in German "Pappelholz". They are not always panels, at least we have no references for this, we have wood or panel

https://www.nationalgallery.org.uk/paintings/workshop-of-andrea-del-verrocchio-tobias-and-the-angel: wood Oursana (talk) 14:26, 25 July 2022 (UTC)[reply]

https://www.wikidata.org/w/index.php?title=Q50322355&diff=next&oldid=1372528546&diffmode=source This edit affects my referenced statement. Technically there is a difference between wood and paneel which we have to considerOursana (talk) 13:24, 20 September 2022 (UTC)[reply]

Best board practices[edit]

Based on Wikidata:WikiProject sum of all paintings/Top materials a couple more types of wood can probably added. I'll have a look. Another part to sort out is the board types: cardboard (Q389782), cardboard (Q18668582), masonite (Q1808397), drawing board (Q1164918), paperboard (Q14934005), canvas board (Q18704961). Multichill (talk) 18:17, 4 June 2021 (UTC)[reply]

Also pasteboard (Q99888913) and card stock (Q6432723), which comes across as "pasteboard" in Commons templates (in EN wiki, "pasteboard" is a redirect to "card stock"). Most of the English language catalogs I am familiar with call this simply "card", so my preference would be a new item "card" (P31 art material). Frustratingly, Getty AAT has a nice hierarchy of types of board under "pasteboard" but plain "card" isn't in it. (I'd probably also be happy with "card" as an alias for pasteboard (Q99888913) and use that as the art material.) - PKM (talk) 21:09, 5 June 2021 (UTC)[reply]

I did a quick check of some museum sites. Here's what they use:

Museum label (lang)	Museum/Collection
board (en)	MOMA
card (en)	MET
card (en)	V&A
paperboard (en)	Museo Nacional Centro de Arte Reina Sofia (English page)
carton (fr)	Musée d'Orsay
cartón (es)	Museo Nacional Centro de Arte Reina Sofia
Pappe (de)	Yorck project

Perhaps cardboard (Q389782) with new alias "card" is the best choice after all. - PKM (talk) 20:58, 7 June 2021 (UTC)[reply]

@PKM: to pick up where we left. For canvas we created canvas (Q12321255) which is basically canvas (Q4259259) for paintings. For panel we created panel (Q106857709) which is basically panel (Q1348059) for paintings. Maybe we should do the same for (card)board (cardboard (Q389782))? We could use cardboard (Q18668582) for that. Multichill (talk) 12:03, 15 April 2022 (UTC)[reply]

@Multichill: that sounds good. PKM (talk) 18:40, 15 April 2022 (UTC)[reply]

Just a note that different types of painting had different terminology so we may need to split this out into pastel/watercolor, en-plein-air painting, and miniature painting. Jane023 (talk) 07:54, 16 April 2022 (UTC)[reply]

Change how we use private collection (Q768717)[edit]

Currently when a work of art is (or has been) in a private collection we set collection (P195) to private collection (Q768717). This is similar to how we used to set creator (P170) to anonymous (Q4233718). Here we mixed up specific instances and a subclass too. Following this rfc this was changed recently to settting creator (P170) to unknown value with qualifier object has role (P3831) set to anonymous (Q4233718) (example edit). More info at the item structure page. Currently it looks if we have one huge private collection (Q768717). I propose we update the model just like with did for anonymous so instead of using private collection (Q768717) directly in collection (P195) we change it to using unknown value with qualifier object has role (P3831) set to private collection (Q768717) so that the target of collection (P195) is always a specific instance or unknown value if we don't have (or don't know) the specific instance. Multichill (talk) 11:03, 5 June 2021 (UTC)[reply]

Agreed! How shall we handle the case when we know whose collection it was but we don't have an item for them? Make items for the collector and for the collection? - PKM (talk) 20:56, 5 June 2021 (UTC)[reply]

Same way as we do it now. Just use some qualifiers and we also have owned by (P127).

Not really any response so I'll just go ahead at some point and start converting it. Multichill (talk) 17:56, 29 June 2021 (UTC)[reply]

Agree to proposed model and agree to "Make items for the collector and for the collection"! --Marsupium (talk) 21:30, 30 June 2021 (UTC)[reply]

Done implemented and documented at Wikidata:WikiProject sum of all paintings/Private collection (some time ago). Multichill (talk) 12:05, 15 April 2022 (UTC)[reply]

Drawings and copies[edit]

We have several items like Reclining Male Nude, Draped (Q106357171) where the original drawing is in the Harvard Art Museums and a copy is in the National Museum. I would assume these should be two separate items, but I want to check with you before I proceed to split them up. - PKM (talk) 23:57, 10 December 2021 (UTC)[reply]

PKM, sure, agree, should be two items! --Marsupium (talk) 22:56, 16 January 2022 (UTC)[reply]

Reducing the number of used instance types[edit]

Hi folks, when you look at humans, we decided to always use instance of (P31) -> human (Q5) and put other things like gender and occupation in other properties. While working on art on Commons I noticed we have a lot of types of artworks used as instance of (P31). Are these really the identity of the work or should these be modeled in a different way? For paintings it's already fairly clean, the usage of items like oil painting (Q56676227) and panel painting (Q55439) is limited and regularly replaced with made from material (P186). We have some well defined subclasses like watercolor painting (Q18761202) that are also used so it's all quite workable.

For other domains it's a bit more mixed, for example photograph (Q125191), print (Q11060274), lithograph (Q15123870) & engraving (Q11835431). On what level should we do the instance of (P31) split? Take for example Politicians - Vanity Fair. 'Denbighshire'. Col. William Cornwallis West. 16 July 1892 (Q110153041). It's currently an instance of chromolithograph (Q89503149). We could add fabrication method (P2079) -> chromolithography (Q1121337) instead and replace the instance of (P31) with lithograph (Q15123870) or even print (Q11060274). This would preserve the data and make our ontology less complex. But where to cut off? Maybe work from the bottom of the tree in small steps and stop merging up when we have a decent amount of items from different sources? Any opinions on this? Multichill (talk) 14:10, 16 January 2022 (UTC)[reply]

Notified participants of WikiProject Visual arts

I have thought about this since 2014 an am still not sure. At first I thought we needed woodcuts and engravings separately from prints, but the issue is that you can't tell the difference on Commons betwwen a woodcut and a print of a woodcut, etc. I guess I ran into this already when I was trying to decide whether an old painting was based on an old print, or if the old print was made after the old painting. In any arbitrary collection of prints, this is never an issue, because the collection keeps records per artefact and doesn't link out to other artworks (in general). We will probably have to come up with some sort of agreement that enables findability as the top priority. Jane023 (talk) 14:45, 16 January 2022 (UTC)[reply]

The question of what information to represent by inheritance/hierarchy and what to represent by attributes probably doesn't have a hard right answer -- wikidata accommodates both models well, and in principle one can switch almost anything from one to the other. But IMO (i) attributes, ie the property = value approach, are maybe a bit more transparent and easier to write queries with, without having to assemble a whole subclass inheritance tree to include what one wants; and (ii) it may be useful to think to ourselves what might be most useful in the context of Commons search. IMO a drop-down there for 'type of image' (eg photograph, painting, print, map ... etc) would be useful, so long as it didn't contain too many options. Finer distinctions - eg steel engraving vs copper engraving vs woodcut vs linocut vs lithograph etc -- could then be offered to those who wanted it.

The final thing I would say is that, particularly for querying, consistency is important. Either distinguish eg all engravings of a particular type using inheritance, or using attributes. The most important thing is to have a policy for one way or the other, so people know (i) what is wanted, and (ii) how to query for it. Whether we choose one or choose the other, either is far better than a mish-mash undecided between both. So User:Multichill's bringing this question forward is very relevant and timely. Jheald (talk) 17:29, 17 January 2022 (UTC)[reply]

I'd also like clear direction on this. I've been using multiple P31s (example at Théâtrophone (Theater phone) (Q109818548)). I do like P31=individual copy of a print (Q75837457) for museum objects, but I don't care whether we use additional P31s or other properties like "fabrication method" and "genre" as long as we have a consistent model and documented guidelines. - PKM (talk) 23:13, 17 January 2022 (UTC)[reply]

Sorry for abandoning this conversation - it just breaks my brain every single time. I just returned here because I feel we should do something about Adam Bartsch and his 21 volumes of "Le Peintre Graveur". If we nail that monster down, we can settle this discussion for prints. Honestly I am afraid to even peek at what is actually in there. I won't touch it with a 12-foot pole until someone says they have metadata better than what's on archive.org. Jane023 (talk) 10:54, 26 January 2022 (UTC)[reply]

Shape of 2D works[edit]

While working on RKDimages ID (P350) I noticed they provide the shape of a work. For example rectangle (portrait format) for The Nativity (Q20274148). That might be useful data to add. We already have shape (P1419) and items like square (Q174782) & rectangle (Q209). We also have landscape orientation (Q109575129) & portrait orientation (Q109575132). I was thinking about either making two new subclasses of rectangle (Q209), one for portrait and one for landscape, or to use shape (P1419) with qualifier orientation (P7469). On Q20274148#P1419 I added the second option as an example. Do you think it's useful to add the shape? What do you think is the best approach of the two?

Notified participants of WikiProject Visual arts Multichill (talk) 13:50, 25 July 2022 (UTC)[reply]

Yes we need this! We already have depicted format (P7984) for the "painted oval" and "niche painting" but the physical format is something I indicated we also needed. The problem is how to propose it that people get what the difference is. The word format is very unsatisfactory, but does shape cover it? Some shapes can be pretty weird when it comes to decoration schemes or something like a perspective box. Jane023 (talk) 14:24, 25 July 2022 (UTC)[reply]

Replace part of with part of the series[edit]

We have individual paintings like Bedroom in Arles (Q18713070) that are part of a series (Bedroom in Arles (Q724377) in this example). We currently sometimes use part of (P361) and in other cases part of the series (P179). I propose we normalize this by replacing part of (P361) with part of the series (P179) when the target only has painting series (Q15727816) and no other instance of (P31) (query to get these). I'm not coming near the polyptych (Q1278452) (and it's subclasses) because here the painting is (or was) part of (P361) a bigger work. What do you think?

Notified participants of WikiProject Visual arts Multichill (talk) 16:24, 30 July 2022 (UTC)[reply]

I was unaware we had this property but it looks like a good idea to me. Jane023 (talk) 12:23, 4 August 2022 (UTC)[reply]

sgraffito used both as class of small monuments and as painting technique[edit]

I stumbled on it via Wikidata_talk:WikiProject_Ontology#Obsternte_(Q63149011)_is_an_art_genre,_according_to_Wikidata_ontology: While the issue at hand could be resolved, there seem to be more issues around this item: sgraffito (Q471835) is currently both a class of works (e.g. small monument (Q3370053)) and a kind of painting technique (painting technique (Q1231896)).

It is also used that way: some items use instance of (P31) (e.g. Sgraffito "St. Ruprecht", Ruprechtsstiege, Vienna (Q100892001)) and some use fabrication method (P2079) (e.g. the passing transitory (couple) (Q94279877)). Apart from this some items use also made from material (P186) (e.g. Q110475434). (see all claims about sgraffito)

I think it should be only one of small monument (Q3370053) or painting technique (Q1231896). The description suggest to me instance of (P31): painting technique (Q1231896) / fabrication method (P2079) sgraffito (Q471835), but I think you are in the better position to decide this. Kind regards, Valentina.Anitnelav (talk) 09:11, 2 December 2022 (UTC)[reply]

@Valentina.Anitnelav, Mateusz Konieczny: looking at Wikidata:WikiProject_Visual_arts/Item_structure#Other_two-dimensional_works_of_visual_art has never been split up in the discipline and the work of art. You should do that to resolve the conflicts. Multichill (talk) 16:47, 2 December 2022 (UTC)[reply]

I guess that bas relief and other in similar situation would also benefit from such creation? Mateusz Konieczny (talk) 17:46, 2 December 2022 (UTC)[reply]

Ok, I think this is resolved - I created sgraffito (Q115570126) and am replacing instance of (P31) sgraffito (Q471835) with this new value. - Valentina.Anitnelav (talk) 10:00, 3 December 2022 (UTC)[reply]

@Mateusz Konieczny: you can do this for multiple things, but if you don't do it completely, start using it and linking everything together, the new items might get merged again. See for example chiaroscuro woodcut (Q21648003) and relief sculpture (Q23662753) for items that didn't work out (copy my css to easily see redirects)

@Valentina.Anitnelav: thanks for fixing it. Multichill (talk) 14:45, 3 December 2022 (UTC)[reply]

Should "public art in Jerusalem" and "public art in Israel" be deleted?[edit]

Another one brought up at Wikidata_talk:WikiProject_Ontology: There were artworks classed as Q58184346.

Is this class even needed? It seems to me that, normally, this information is expressed using genre (P136)public art (Q557141) + country (P17)Israel (Q801) (and possibly located in the administrative territorial entity (P131)Jerusalem (Q1218)).

I would bring them up at Wikidata:Requests_for_deletions but I would like to know your opinion first.

@Talmoryair: as the creator of this item: did I maybe miss something why these items are needed? Kind regards, Valentina.Anitnelav (talk) 22:52, 4 December 2022 (UTC)[reply]

I created https://www.wikidata.org/wiki/Wikidata:Requests_for_deletions#Q58184346 while Valentina.Anitnelav was posting that Mateusz Konieczny (talk) 23:00, 4 December 2022 (UTC)[reply]

Hi. i think it was opend when we didint understood it complitly. it should be changen to public art / outdoor (or somthing like that), and the city in a difrent filed. Talmoryair (talk) 17:50, 30 December 2022 (UTC)[reply]

How to model order of values across made from material (P186) and fabrication method (P2079)?[edit]

I'd like to express that the technique values of Head of an Apostle with Beard and Cap (Q116787446)'s made from material (P186) and fabrication method (P2079) statements should have this order: "gray pen drawing, gray wash, white highlight, gray-green primer, pink primer, paper" like in the source. What do you think would be a good way to model that order? Thanks in advance, --Marsupium (talk) 03:23, 18 February 2023 (UTC)[reply]

equestrian statue: instance of (P31) or genre (P136)[edit]

Hi, there is a discussion on my talk page about whether to use P31 or P136 to indicate that a certain sculpture is an equestrian statue (User_talk:Valentina.Anitnelav#Reiterstandbild, first part in German). I don't really have a strong opinion which to use as long as it is consistent, even though P136 seems to me more in line with other approaches to modelling art works. Gerd Fahrenhorst, on the other hand, points out that P31 should always hold the most specific value. I will leave this question up to you to discuss and decide, but I won't participate much. If it should be decided that P31 should be used, I'm willing to move values from P136 to P31 (as the discussion appeared when I moved values from P31 to P136). Thanks for your input! (@Gerd Fahrenhorst, JBradyK: pinging the people who brought up this issue) - Valentina.Anitnelav (talk) 11:38, 26 February 2023 (UTC)[reply]

Thank you, Valentina, for pointing out the inconsistent usage. The merits of each approach depend partly on the academic discipline, I think. I have been struggling with the problem in two projects of mine, one on cataloguing modern public monuments/memorials in Greece, the other in turning the ancient travel description of Greece by Pausanias (a core source for ancient history/archaeology/religion) into linked open data using Wikidata identifiers. Key goals for me are clarity and findability, with the latter improved by making my P31 entities subclasses of the correct combination of more abstract entities.

I have mapped to Wikidata so far about 1380 (maybe half the total number?) portrait busts that were set up in public places in Greece to commemorate notable individuals. I created an entity, commemorative bust Q113650147, as a subclass both of memorial and of bust, because these portrait busts are distinctive physical objects occupying two crucial categories simultaneously, whereas bust is a purely artist genre. My objects both depict someone and commemorate someone, and apply to the sphere of local/national politics as well as art.

Because almost all equestrian statues I know of are both artworks and memorials, both depicting a specific person and commemorating them, I didn't see the need to create a separate entity, but simply made sure that Equestrian Statue Q659396 was a subclass of memorial as well as statue. However, now that I think about it, English country houses are full of little equestrian statues that are more decorative art than memorial. So it would be correct and useful, at least for people interested in the social history behind memorial art, to want a separate entity, equestrian memorial, clearly defined as near-life-size or larger public monument depicting a person on a horse and designed to commemorate the rider or an event in which they participated. Europe and the eastern USA are full of such statues, and it is better I think for them to have a single understandable P31 statement rather than multiple imprecise ones. In any case, "sculpture" is too vague to be useful. I have borrowed for P31 "memorial sculpture" (Q64850080) for memorials not otherwise specified where sculpture plays a key role.

I also use portrait statue Q12873675 with the same logic, for (so far about 300) free-standing statues of notable humans being commemorated in public in Greece.

Most Greek war memorials are fairly plain marble, embellished with carved laurel wreaths or eagles but highly derivative and not treated as works of art with a identifiable sculptor, For them, P31 war memorial (Q575759) works fine. I haven't tried to deal with the bronze plaques with relief sculpture on them, e.g. depictions of the triumphal entry of the King into Thessaloniki.

Pausanias uses some important terms that are routinely misunderstood by modern scholars. His άγαλμα agalma is a work of art offered to a god. By Pausanias' time it is generally a statue depicting the god, but it is not, at least originally, a "cult statue" in the sense of something created in order to be worshipped. So I use the entity agalma Q97584077 because it is a subclass of sculpture AND of votive offering. There is another technical term, xoanon Q693222, for a roughly carved wooden image of the god. Sometimes a xoanon is indeed a cult statue, treated as the god him/herself at certain points, but Greek has another term for that, ἑδος. Pausanias also describes hundreds of honorific statues Q23830017, put up in public places to honor a living person. They are a subclass of portrait statue, but subtly different from a memorial statue. That difference could be expressed via qualifiers, of course, or genre, but since most of ones I am collecting are long-vanished, it's nice not to clutter up query results with them.

I suspect a coherent solution is evolving, and I will do my best to respect it once it is explained to me carefully. Museum objects and public monuments occupy overlapping but not identical ontological spaces, and ancient historians categorize the world differently than museum curators. Thanks again... JBradyK (ToposText) (talk) 07:54, 27 February 2023 (UTC)[reply]

@JBradyK: [9]. I don't think you're using instance of (P31) correctly. Multichill (talk) 17:11, 27 February 2023 (UTC)[reply]

Happy to entertain alternative suggestions. Are you saying my objects are not instances of what I call them, or that we should not use P31 to characterize things as what they are? JBradyK (ToposText) (talk) 17:25, 27 February 2023 (UTC)[reply]

Nice work, JBradyK. To be more in line with the WikiProject Visual arts approach commemorative bust (Q113650147) should be rather used as a genre, I think. You could either use both memorial (Q5003624) and sculpture (Q860861) as P31 or just commemorative sculpture (Q64850080) (if nobody disagrees). If you use commemorative sculpture (Q64850080) as P31 you should probably add it to Wikidata:WikiProject_Visual_arts/Item_structure#Sculpted_works.

for example:

instance of (P31)memorial (Q5003624)	or	instance of (P31)commemorative sculpture (Q64850080) (if nobody disagrees with this use)
instance of (P31)sculpture (Q860861)
genre (P136)commemorative bust (Q113650147) (equestrian statue (Q659396) etc.)

I'm not sure what to do with agalma (Q97584077). Apart from P31 you could use has use (P366). When you decide to use P31 you should have a closer look at the super class religious art (Q2864737) (an indirect subclass of recreation, via art (Q735), and declared an art genre). I think I would just delete subclass of (P279)religious art (Q2864737) if agalma (Q97584077) should be used via P31. It is already an indirect subclass of religious object (Q21029893). - Valentina.Anitnelav (talk) 16:31, 6 March 2023 (UTC)[reply]

It seems to me that xoanon (Q693222) could be used as a genre.

honorific statue (Q23830017) should not be an instance of award (Q618779). I think I would use has use (P366) or genre (P136), again, to indicate that a statue is a honorific statue. (genre (P136) has the advantage of keeping things simple). Regards, - Valentina.Anitnelav (talk) 16:31, 6 March 2023 (UTC)[reply]

I just found commemorative statue (Q107194468). Do you think this can be merged with commemorative sculpture (Q64850080)? - Valentina.Anitnelav (talk) 16:33, 6 March 2023 (UTC)[reply]

Modelling a triptych[edit]

Triptychs (triptych (Q79218)) are currently the source of quite a few constraint violations (see for example Moreel Triptych (Q3539574)). I figured it's about time we make a model to cover this. The possible items we have:

Item for the triptych itself
- Item for the central panel
- Item for the left panel
  - Item for the inner left panel
  - Item for the outer left panel
- Item for the right panel
  - Item for the inner right panel
  - Item for the outer right panel
- Item for the wings (right and left panels) open
- Item for the wings (right and left panels) closed

We'll only create the items when we need them (usually because an external source covers that part) and we link together the different items with part of (P361)/has part(s) (P527) qualified with subject has role (P2868)/object has role (P3831). What do you think? Multichill (talk) 18:41, 2 March 2023 (UTC)[reply]

We'll only create the items when we need them (usually because an external source covers that part)

Support in general I agree. I am not sure about creating items with view to use depicts (P180).

It would be sufficient to use applies to part (P518).

Especially when triptychs consist of reliefs and paintings and different creator (P170) and made from material (P186), could be necessary to create items. Examples could be helpful for the discussion

dismantled triptychs/polyptychs have different location (P276), collection (P195), and owners

and we link together the different items with part of (P361)/has part(s) (P527)

Support

qualified with subject has role (P2868)/object has role (P3831)

I do not understand this point and what we need this for.

Wings are the panels, no extra items. This concerns winged altarpiece (Q11801536), not (triptych (Q79218)

--Oursana (talk) 21:35, 17 April 2023 (UTC) ---You need this when the center panel is missing. Sometimes you have two wings that are both painted on two sides. Jane023 (talk) 14:23, 15 January 2024 (UTC)[reply]

(long-term) loans[edit]

Notified participants of WikiProject Visual_arts this weekend I went to PLW 2024. Here we discussed the concept of long-term loan (Q94796160) and the wish of museums to express that. I would like to do that my adding the qualifier subject has role (P2868) set to long-term loan (Q94796160) to the collection (P195) statement (an example). Do you think this is the right way to do it? It's already used like this 5000+ times (break down per collection), but we can always improve. I hope we can reach consensus so we can update the item structure documentation and make this more widespread. Multichill (talk) 13:56, 15 January 2024 (UTC)[reply]

What's the item for short-term loan (e.g. less than a year or for exhibition of a few months) and what is the cut-off for a short-term/long-term? I have no problem with doing it this way, but it could be confusing if people use it for exhibitions. Jane023 (talk) 14:01, 15 January 2024 (UTC)[reply]

@Jane023: for me a work is in a collection if the collection included it and assigned an inventory number to it. I doubt collections will to that for every work in a temporary exhibition, but if so, another round of refinement can be done. Multichill (talk) 14:17, 15 January 2024 (UTC)[reply]

I see. That makes sense, but shouldn't the qualifier be used in the inventory number (P217) statement too? The example you gave has the prefix Lg for leihgabe so the institution needs some indication in the number as well. Jane023 (talk) 14:34, 15 January 2024 (UTC)[reply]

I am not yet sure to expand it, but I want to point out that also other institutions have a special inventory number system for artworks on long-term loan, e.g. SK-C- the Rijksmuseum in Amsterdam and SB.. the Amsterdam Museum

also we have to check long-term loan (Q94796160), Iam not sure if this has to be specified to the arts. I added Art & Architecture Thesaurus ID (P1014) and do not find its definition of acquiry method back in our item. So I do not see, that it is a status. The acquiry method loan/Long term loan and heritage, purchase on the other side lead to property or possession, a difference we unfortunatly still do not express, though it is an important difference to express "loan"

loan (Q3777645), loan (Q105334701), loan (Q3777645) Iam also not happy with these items.

example Interior with a Sick Woman by a Fireplace (Q40037979) 2 years loan

the use of long-term loan (Q94796160) as qualifier to location (P276) leads to contraint violation.

--Oursana (talk) 17:24, 15 January 2024 (UTC)[reply]

I'm not proposing to add it as qualifier to inventory number (P217). That seems a bit redundant.

Loan is a difficult concept. We also have commodate (Q1580844) to make it even more fun. long-term loan (Q94796160) is as far as I can see only used for this purpose. It's easy to change to some other item later.

Not sure about location (P276). Maybe has cause (P828)? Let's first see if we can focus on collection (P195) before making the problem larger? Multichill (talk) 21:36, 16 January 2024 (UTC)[reply]

I edited a large part of subject has role (P2868):long-term loan (Q94796160) statements. It concerns thousands of paintings of the Department of Paintings of the Louvre (Q3044768), where half of the works are on long-term loans. By the way I made an interactive map of them : https://zone47.com/crotos/gudea/callisto/?m=3&l=en .

The long-term loans concerns other museums, sometimes for significant portions of their collections For example the collections of the Prado, they made a special project to present them : Prado extendido

As reminder, we had already a discussion about long-term loans.

For the qualification I first edited legal form (P1454):long-term loan (Q94796160) but I think it's ok too for subject has role (P2868):long-term loan (Q94796160) and I switched.

There is an indeed often a "long-term loan number" which is different from an "inventory number" and is written in a specific registry. I'm not sure we could fill and maintain those "long-term loan number" statments. Official online databases are often confusing about this. The qualification of a inventory number (P217) claim with the collection, which is a constraint in Wikidata, is in practice a good way to edit a long-term loan number. Best regard --Shonagon (talk) 22:30, 17 January 2024 (UTC)[reply]

Before I used cause (Q2574811), commodate (Q1580844) with location (P276), see example Madonna of Humility (Q3065237), perhaps more clear and flexible, perhaps also possible with significant event (P793)

legal form (P1454) is different better consider legal relationship (Q1367590) Oursana (talk) 22:39, 17 January 2024 (UTC)[reply]

Indeed an artwork should have a location but it's not enough to qualify a long-term loan. An artefact on long-term loan is considered as part of of the collection of the borrower and should have a collection (P195) statement. That is the a big difference with loans. And that's why we found them in official online database of borrowers. I made a lot of long-term loans qualification edits on collection (P195) claims on wikidata items that have already the borrower as collection.

Moreover, strange as it may seem, the location does not always refer to the borrower. One example with this artwork Q115673286 on long-term to the collection of Musée des Ursulines (Q28843765) but located in musée Lamartine (Q3329237). Actually a long-term loan is both a practice and a specific legal form concerning cultural objects and the respective responsibilities of the lender and the borrower.

commodate (Q1580844) is not long-term loan (Q94796160) which is sometimes called "deposit" in English (example http://www.old.klm-mra.be/D7t/en/content/loan-out-and-deposit ) Commodat refers to the production world where the object is used, long-term loan refer to cultural artifacts which are not always on display and are often sleeping in a storage but are attached to an institution by a conservation contract. Best regards --Shonagon (talk) 02:50, 19 January 2024 (UTC)[reply]

A long term loan and loans are contracts. There is no further legal form.Oursana (talk) 01:10, 20 January 2024 (UTC)[reply]

I am missing to express the lender of the loan, we do not have an item for thisOursana (talk) 05:01, 29 January 2024 (UTC)[reply]

Wikidata for visual artists self-publishing updates?[edit]

Dear ALL (knowing this might be controversial in more then one way) I am curious to hear if you think encouraging artists and art organizations to publish own updates and corrections on their Wikidata items as possible option? (well aware that this is discouraged on Wikipedias) -- Zblace (talk) 09:10, 23 January 2024 (UTC)[reply]

It's discouraged on Wikipedias, not banned. As long as it's uncontroversial and/or well-referenced I don't see a problem. Sjoerd de Bruin (talk) 14:59, 30 January 2024 (UTC)[reply]