Wikidata talk:WikiProject Visual arts

From Wikidata
Jump to: navigation, search

Contents

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:

  1. establish a structure for artwork/material artefact/object items (cf. #Determining yet existing items for the domain of the task force) – yet begun here
  2. 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
  3. harmonize the data at Wikidata with those of Commons and other Wikimedia projects
    – probably nothing controversial up to here –
  4. (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)

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)

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 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)
D'accord, dommage! Joconde 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)
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)

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)

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

Ping test[edit]

User:Zolo
Jane023 (talk) 08:50, 30 May 2013 (UTC)
User:Vincent Steenberg
User:Kippelboy
User:Shonagon
Marsupium (talk) 13:46, 18 October 2013 (UTC)
GautierPoupeau (talk) 16:55, 9 January 2014 (UTC)
Multichill (talk) 19:13, 8 July 2014 (UTC)
Susannaanas (talk) 11:32, 12 August 2014 (UTC) I want to synchronize the handling of maps with this initiative
Mushroom (talk) 00:10, 24 August 2014 (UTC)
Jheald (talk) 17:09, 9 September 2014 (UTC)
Spinster (talk) 15:16, 12 September 2014 (UTC)
PKM (talk) 21:16, 8 October 2014 (UTC)
Vladimir Alexiev (talk) 17:12, 7 January 2015‎ (UTC)
Ham II (talk) 09:24, 31 October 2015 (UTC)
Sic19 (talk) 21:12, 19 February 2016 (UTC)
Wittylama (talk) 13:13, 22 February 2017 (UTC)
Armineaghayan (talk) 08:40, 10 March 2017 (UTC)
Hannolans (talk) 18:36, 16 April 2017 (UTC)
Pictogram voting comment.svg 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)

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)
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)
YEs, I received one ping! :)--Kippelboy (talk) 06:25, 10 December 2013 (UTC)
I just got it now. Jane023 (talk) 08:43, 13 December 2013 (UTC)

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

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

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)

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:
--Zolo (talk) 19:09, 13 April 2014 (UTC)
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)
For the record: Zolo proposed the two properties addressed above: Iconclass ID, and depicts Iconclass. --Marsupium (talk) 11:55, 18 April 2014 (UTC)
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)

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)

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)

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)

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

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)

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)

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 edition(s) (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)

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)

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)

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)
Hmm I made Talk:Q17616737 but it doesn't list the items as numbered values. Jane023 (talk) 12:31, 3 September 2014 (UTC)
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)
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)
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)
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)
User talk:Jane023 look again please, the file doesn't link to Philip 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)

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)

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

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)
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)
@Multichill:
To get the title, the module uses no label (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)
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)
+1 on that. Multichill (talk) 15:50, 7 September 2014 (UTC)
@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)
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)
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)

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)

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)
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)
The Four Horsemen of the Apocalypse in the collection of the Staatliche Kunsthalle Karlsruhe (Q658725), sheet from Dürer's Apocalypse (Q618854) series
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:
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)

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)
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 (Q139106). --Zolo (talk) 10:11, 9 September 2014 (UTC)
@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)
If we do not have an item for the original work, we can still use applies to part (P518) engraving (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)
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)
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)

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,

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)

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

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

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)
Discussions noted at WikiProject Books Jheald (talk) 11:24, 21 September 2014 (UTC)
Discussions noted at WikiProject Structured Data for Commons Jheald (talk) 11:30, 21 September 2014 (UTC)

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)

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)
There is also the possibility of using catalog code (P528) for this. Jane023 (talk) 07:53, 24 September 2014 (UTC)
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)
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)
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)
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)

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)

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 material used (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)
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)

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)

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)

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)
thank you! - PKM (talk) 19:50, 5 November 2014 (UTC)

Grove Art Online[edit]

Following English Wikipedia, I have change the label for Grove 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)

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)
I've put it back. "Oxford Art Online" looks more like a portal. Charles Matthews (talk) 10:52, 7 November 2017 (UTC)
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)
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)

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)

  • 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)
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)
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)
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)
Do we need to record who attributed the work, and when? - PKM (talk) 06:06, 26 November 2014 (UTC)
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)
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)
Hi all - just a quick note - in the USA we generally say "unknown artist" or "anonymous" so I have been using "unknown artist" no label (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)
no label (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)
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)
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)
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)
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)
Not the first time it was just me. :-) - - PKM (talk) 03:19, 31 December 2014 (UTC)

I want to suggest more qualifiers like

copy (of) or after

and

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

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)

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)

.

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)

Wow that is very impressive. Thanks for your work on this - so glad to see it! Jane023 (talk) 10:25, 11 December 2014 (UTC)
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)
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)
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)

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.
  • material used (P186) fr:Module:Material analyses the applies to part (P518) qualifiers. When it is set to painting surface (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 surface (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)

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)

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)

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)

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)

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

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)

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

User:Zolo
Jane023 (talk) 08:50, 30 May 2013 (UTC)
User:Vincent Steenberg
User:Kippelboy
User:Shonagon
Marsupium (talk) 13:46, 18 October 2013 (UTC)
GautierPoupeau (talk) 16:55, 9 January 2014 (UTC)
Multichill (talk) 19:13, 8 July 2014 (UTC)
Susannaanas (talk) 11:32, 12 August 2014 (UTC) I want to synchronize the handling of maps with this initiative
Mushroom (talk) 00:10, 24 August 2014 (UTC)
Jheald (talk) 17:09, 9 September 2014 (UTC)
Spinster (talk) 15:16, 12 September 2014 (UTC)
PKM (talk) 21:16, 8 October 2014 (UTC)
Vladimir Alexiev (talk) 17:12, 7 January 2015‎ (UTC)
Ham II (talk) 09:24, 31 October 2015 (UTC)
Sic19 (talk) 21:12, 19 February 2016 (UTC)
Wittylama (talk) 13:13, 22 February 2017 (UTC)
Armineaghayan (talk) 08:40, 10 March 2017 (UTC)
Hannolans (talk) 18:36, 16 April 2017 (UTC)
Pictogram voting comment.svg 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)

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)

User:Zolo
Jane023 (talk) 08:50, 30 May 2013 (UTC)
User:Vincent Steenberg
User:Kippelboy
User:Shonagon
Marsupium (talk) 13:46, 18 October 2013 (UTC)
GautierPoupeau (talk) 16:55, 9 January 2014 (UTC)
Multichill (talk) 19:13, 8 July 2014 (UTC)
Susannaanas (talk) 11:32, 12 August 2014 (UTC) I want to synchronize the handling of maps with this initiative
Mushroom (talk) 00:10, 24 August 2014 (UTC)
Jheald (talk) 17:09, 9 September 2014 (UTC)
Spinster (talk) 15:16, 12 September 2014 (UTC)
PKM (talk) 21:16, 8 October 2014 (UTC)
Vladimir Alexiev (talk) 17:12, 7 January 2015‎ (UTC)
Ham II (talk) 09:24, 31 October 2015 (UTC)
Sic19 (talk) 21:12, 19 February 2016 (UTC)
Wittylama (talk) 13:13, 22 February 2017 (UTC)
Armineaghayan (talk) 08:40, 10 March 2017 (UTC)
Hannolans (talk) 18:36, 16 April 2017 (UTC)
Pictogram voting comment.svg 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)

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

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)

Mix'n'match synchronization[edit]

@Charles Matthews, Jane023, HCShannon, Spinster: I recently created about 1,500 items for entries in ULAN 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)

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

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)

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

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)

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)

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:

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

  • 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)
… 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)
@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)
@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)
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)
@Marsupium:Talked to Patricia Hapring. 500404125 is not yet online --Vladimir Alexiev (talk) 10:24, 7 June 2017 (UTC)
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)
@RKDdata: ? Thank you! --Marsupium (talk) 10:49, 26 September 2017 (UTC)

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

User:Zolo
Jane023 (talk) 08:50, 30 May 2013 (UTC)
User:Vincent Steenberg
User:Kippelboy
User:Shonagon
Marsupium (talk) 13:46, 18 October 2013 (UTC)
GautierPoupeau (talk) 16:55, 9 January 2014 (UTC)
Multichill (talk) 19:13, 8 July 2014 (UTC)
Susannaanas (talk) 11:32, 12 August 2014 (UTC) I want to synchronize the handling of maps with this initiative
Mushroom (talk) 00:10, 24 August 2014 (UTC)
Jheald (talk) 17:09, 9 September 2014 (UTC)
Spinster (talk) 15:16, 12 September 2014 (UTC)
PKM (talk) 21:16, 8 October 2014 (UTC)
Vladimir Alexiev (talk) 17:12, 7 January 2015‎ (UTC)
Ham II (talk) 09:24, 31 October 2015 (UTC)
Sic19 (talk) 21:12, 19 February 2016 (UTC)
Wittylama (talk) 13:13, 22 February 2017 (UTC)
Armineaghayan (talk) 08:40, 10 March 2017 (UTC)
Hannolans (talk) 18:36, 16 April 2017 (UTC)
Pictogram voting comment.svg 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)

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)
Thanks for validating my instincts. I'll add the note to the monogrammist template. - PKM (talk) 19:32, 23 May 2017 (UTC)

Solely structural Iconclass items[edit]

How can we prevent the creation of items like the Jewish councillor Joseph of Arimathaea; possible attributes: Holy Grail, instruments of the Passion (e.g. three nails, crown of thorns) - death, deathbed of male saint (Q21557749)? --Marsupium (talk) 20:14, 28 May 2017 (UTC)

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)
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)
@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)
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)
Got it. Thanks! - PKM (talk) 07:29, 11 November 2017 (UTC)
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)

More on iconclass notations[edit]

User:Zolo
Jane023 (talk) 08:50, 30 May 2013 (UTC)
User:Vincent Steenberg
User:Kippelboy
User:Shonagon
Marsupium (talk) 13:46, 18 October 2013 (UTC)
GautierPoupeau (talk) 16:55, 9 January 2014 (UTC)
Multichill (talk) 19:13, 8 July 2014 (UTC)
Susannaanas (talk) 11:32, 12 August 2014 (UTC) I want to synchronize the handling of maps with this initiative
Mushroom (talk) 00:10, 24 August 2014 (UTC)
Jheald (talk) 17:09, 9 September 2014 (UTC)
Spinster (talk) 15:16, 12 September 2014 (UTC)
PKM (talk) 21:16, 8 October 2014 (UTC)
Vladimir Alexiev (talk) 17:12, 7 January 2015‎ (UTC)
Ham II (talk) 09:24, 31 October 2015 (UTC)
Sic19 (talk) 21:12, 19 February 2016 (UTC)
Wittylama (talk) 13:13, 22 February 2017 (UTC)
Armineaghayan (talk) 08:40, 10 March 2017 (UTC)
Hannolans (talk) 18:36, 16 April 2017 (UTC)
Pictogram voting comment.svg 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.

  1. In the case of the Jewish councillor Joseph of Arimathaea; possible attributes: Holy Grail, instruments of the Passion (e.g. three nails, crown of thorns) - death, deathbed of male saint (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.
  2. 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.?
  3. 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?
  4. 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?
  5. 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)

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 the Jewish councillor Joseph of Arimathaea; possible attributes: Holy Grail, instruments of the Passion (e.g. three nails, crown of thorns) - death, deathbed of male saint (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)
To 5.: Can't this be handled with constraint exceptions?
Best regards, --Marsupium (talk) 22:21, 6 November 2017 (UTC)
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)
Fine! --Marsupium (talk) 16:33, 7 November 2017 (UTC)
Are we sure about this? See list so far at Iconclass notation (P1256). :-) - PKM (talk) 00:58, 21 November 2017 (UTC)
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)

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)

Good to see! Hannolans (talk) 20:40, 6 November 2017 (UTC)
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)

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)

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

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)

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

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)

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)

Thank you for this! I'd like to suggest to merge no label (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)
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 no label (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)
personification (Q207174) merge completed and EN description updated. - PKM (talk) 02:09, 18 November 2017 (UTC)