Wikidata talk:WikiProject sum of all paintings/Archive/2019

This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

author name string (P2093)

Hi!

For cases where we can't directly identify the creator, should we use author name string (P2093). to store it? Alternatively, should we propose an equivalent property "creator name string" so that it can be known that it should be replaced by creator (P170) instead of author (P50)? These seem like the only good options to store name strings (I read something about adding them to the English description, but not only that's clearly not the right place, but descriptions don't have sources, so it wouldn't be possible to store *where* the data came from).--Reosarevok (talk) 10:38, 14 January 2019 (UTC)

Yes that is a good use of author name string (P2093). --Jarekt (talk) 16:10, 14 January 2019 (UTC)
@Reosarevok: Thanks a lot for bringing this up! After years, I recently had the same thought, just didn't write it yet. Multichill whose merit the biggest part of the painting imports here are has used the description field for this for years now and somehow this seemed to be the only/best option, even build this tool (loading takes long) around descriptions. As a scheme "painting by creator name string" plus if necessary the differentiation "(collection abbreviation + inventory number)" was used. This is not query-friendly (not even for the tool) and caused problems, e.g. here. This would also give a clean solution for only relatedness of a known name and the actual creator. And, Jarekt, I think author name string (P2093) for this is messy and gets us into trouble for items where both do or may apply, illustrated texts stuff and the like, as a solution for that we could use object has role (P3831) as a qualifier, but my gut feeling is its better to have a separate property "creator name string" of which author name string (P2093) would be subproperty of (P1647). A new property might also be useful for other projects outside visual arts. Any more opinions? (I somehow saw this section only now, pings appreciated :) ) Thanks, --Marsupium (talk) 12:17, 29 January 2019 (UTC)
As discussed at Wikidata:Property proposal/creator name string, I think a better way to do this is to set creator (P170) to somevalue, with qualifier object named as (P1932) giving the unmatched string.
This is a general mechanism that can be used for any property, and is easy to pick up in queries -- for example the "No Q" column in the "Titles -- statements" section of this dashboard for a 19th-century books project, generated by Listeria based on this query: goo.gl/R2Veya. (See the 'OPTIONAL' block, about half-way down). Jheald (talk) 11:25, 15 March 2019 (UTC)

Reply to Magnus' post on museum collection imports

I think this blog post deserves a reply from us/you, especially the last paragraph. What do you think about it? @Multichill, Jarekt: FYI. Thanks, --Marsupium (talk) 12:21, 29 January 2019 (UTC)

If we have items for artworks that do not have collection and inventory number or a link to some museum page or some identifier than they net well defined and likely to get duplicates. I think we should definitely create items for all the artworks in that museum that have separate inventory number. --Jarekt (talk) 14:04, 29 January 2019 (UTC)
I answered the blog and it broke. I would definitely use such a tool if it existed. I do this with my own hack all the time. If it was easier I could be more productive. Basically for each artist on Commons, all well-documented artworks should be on Wikidata. Ideally the other way around would be nice, except we have problems with copyright for modern artists. Jane023 (talk) 15:35, 29 January 2019 (UTC)
Automation should be scoped to unique one-off artworks (sculptures/paintings/drawings). As far as I know we don't have a datamodel for furniture, fashion, prints photopgraphs etc in place in wikidata as that needs an item for the concept and an item for the unique version/reproduction of that concept in that museum. Wikidata will double in size if we implement adding photographs. The Dutch fotomuseum alone has 700.000 photographs. --Hannolans (talk) 10:40, 15 March 2019 (UTC)
I am very interested in having a data model for furniture and fashion that can handle the museum object and the (freely) licensed photo. - PKM (talk) 23:50, 17 March 2019 (UTC)

Thoughts on Distributed Game - Depicts

Folks have been busy playing the new Distributed Game - Depicts, which uses an AI/machine learning algorithm to analyze existing paintings in Wikidata, and then suggest depicts statements. Human volunteers then do the Yes/Skip/No determinations on whether to add depicts (P180) to the item. Here are links to:

It would be great to have feedback from SOAP participants on their experiences and new directions.

  1. Why paintings? I've focused on paintings as it's one of the most developed domains of art content in Wikidata. Two, it's easier to fit into the game dynamic versus 3D objects, sculpture, jewelry, etc.
  2. How have they been added? I originally loaded a bunch of different museums - The Met, Cleveland Museum of Art, Smithsonian, etc. Recently, I've been working through different collections so we might see some trends better - Rijksmuseum, and currently the Swedish Nationalmuseum. Is this a good approach? Is there something else we could be doing in adding collections either one at a time or in batches?
  3. What depiction labels should we examine? The proposed depiction labels come from areas where the AI did best - tree, mountain, horse, soldier, house, flower, boat and bird. These landscape painting-oriented features seem to do well because they appear with significant contextual clues. A boat is rarely just sitting on its own, but will have a sky above and water below. A horse will have a rider on it, or will be the main subject of the painting with well-defined features. For the same reason, dogs don't do as well with the AI, likely because of the many different ways they appear in art and the wide variety of breeds and sizes. We have stayed away from "gender determination" in people choosing man and woman, as this has been a general problem with state of the art in image classification and our results are not stellar either. What areas might you like to see tried? I can provide some investigation into how well our classification has done.
  4. What approaches for generating depiction candidates should we also try? Now that we have the framework for depiction games, we could try different ways to fill a queue of recommendations. One idea is to use the artwork title to suggest depiction statements. For exampe, in the process of checking the result of "horse" in the Depiction game, I was worried folks might misidentify donkeys as horses, so I made some queries to double check this. Instead, we could actually generate depiction candidates by looking for keywords in titles, and suggesting those. Example:
# Find paintings with "donkey" in the title but no depiction statement for it
SELECT ?item ?itemLabel ?title 
WHERE 
{
  ?item wdt:P31 wd:Q3305213 .
  ?item rdfs:label ?title .
  FILTER(LANG(?title) = "en").
  FILTER(CONTAINS(?title,"Donkey"))
  FILTER NOT EXISTS { ?item wdt:P180 wd:Q3537778 }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
Try it!

Thanks for any insights or ideas. @Jane023, PKM, Multichill, Wittylama, Magnus Manske, Spinster: -- Fuzheado (talk) 09:21, 9 March 2019 (UTC)

I think this is a very nice initiative and agree that you need to be careful that reducing the scope to yes/no questions leaves out difficult choices. I have set up lists of portraits of men by decade and portraits of women by decade as a first step to linking portraits of people to people items while allowing you to browse changing fashions. Now theye are in decade lists but these could be separated by year or by the country of the painter or sitter once we have a larger dataset. To show up in one of these lists the portrait must have genre + depicts woman/man. I suppose you could first do a pass of setting stuff to portrait for all titles with "(1" in them, since a lot of museums include the birth-death dates in their portrait titles. This would then allow you to upload the same set as possible depicts man/woman/child/boy/girl. Jane023 (talk) 12:01, 10 March 2019 (UTC)
Looks like an interesting approach. What software is being used? Anything open or is it all closed source? I've played around with computer vision to recognize images some time ago. Good to see it in action here.
Looking at top depicts and top genres I wonder if it would be possible to train it to find portraits while filtering out the religious art. Multichill (talk) 17:26, 10 March 2019 (UTC)
@Jane023: where can I find those portrait lists? :-) - PKM (talk) 23:47, 17 March 2019 (UTC)
I put the index pages here: Category:WikiProject sum of all paintings portraits and all pages are in Category:WikiProject Q5 since I created a Wikidata:WikiProject Women and a Wikidata:WikiProject Men. Now, revisiting them, I think I can create lists for boys and girls (we didn't have many children at all when I started). Jane023 (talk) 07:19, 18 March 2019 (UTC)

NPG (smithsonian) property

Just a quick mention here that I spotted that there is no property yet for the Smithsonian National Portrait Gallery object id. Instead these paintings, e.g. Carlton Fisk (Q47513245), only hold the id in inventory number (P217) and make use of described at URL (P973) to link out. Should be a fairly straight forward property proposal and migration for anyone with a little bit of time (which disqualifies me, hence the mention here). /Lokal Profil (talk) 20:08, 5 July 2018 (UTC)

Does anyone know how to get all the possible formats for the identifier? The Time magazine collection has examples like NPG.97.TC43, so I assume there may be many collections with slightly different formats. - PKM (talk) 19:59, 9 August 2018 (UTC)
@Lokal Profil, PKM: National Portrait Gallery (United States) object ID (P6152).
Based on the Query you can probably make a regex to match the different cases. Multichill (talk) 10:42, 2 December 2018 (UTC)
Much delayed thanks =) /Lokal_Profil 23:02, 31 March 2019 (UTC)

title (P1476) and paintings

Input appreciated at Property_talk:P1476#How_to_use_for_paintings?. Multichill (talk) 15:25, 31 March 2019 (UTC)

Property statistics dashboard

  WikiProject sum of all paintings has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.

We (Liam and I) made a dashboard at Wikidata:WikiProject sum of all paintings/Property statistics. Multichill (talk) 12:42, 3 April 2019 (UTC)

Cézanne's Catalogue raisonné online https://www.cezannecatalogue.com

Is this catalogue used as reference on the project ? is there a property for it ?

Thanks for your help, --Hsarrazin (talk) 17:01, 5 May 2019 (UTC)

@Hsarrazin: I added a note to Wikidata:WikiProject sum of all paintings/Creator/Paul Cézanne some time ago. I think I stopped when I noticed I had to register. Multichill (talk) 17:37, 5 May 2019 (UTC)
I registered. But, there is no password, for what I could see. --Hsarrazin (talk) 17:43, 5 May 2019 (UTC)

corporate art collections

I want to add artwork of two corporate art collection (Q64153060) (item just created). Are there guidelines how to model artworks in corporate art collections? Do we prefer to map them to a special item 'collection of..' or trust, or to the main organisation? Are there already examples? --Hannolans (talk) 12:02, 29 May 2019 (UTC)

Colour scheme

The colour scheme in the "Property statistics" table applies to Wikidata:WikiProject sum of all paintings/Property statistics/Sandbox, but doesn't fit with the colours used in Wikidata:WikiProject sum of all paintings/Property statistics. Pietro (talk) 08:27, 31 May 2019 (UTC)

separate copies of the same engraving

National Library of Wales (Q666063) has 2 copies of the same engraving:

All the properties of that item are almost identical except for inventory number (P217) and URLs. Two copies of the same painting or sculpture are kept as separate entities, but separate copies of prints like engravings, I think should be kept in a single item. Any objections in merging of this and similar items? Also @Sic19, Jason.nlw:, who worked on the upload. --Jarekt (talk) 13:58, 9 April 2019 (UTC)

Same with
--Jarekt (talk) 14:00, 9 April 2019 (UTC)
Actually the first one is not separate but similar versions, but they are the same version, just referenced from two sources. So yes, if the others are like this, then merge. Jane023 (talk) 14:16, 9 April 2019 (UTC)
Jane023, I don't understand what you mean. "similar versions, but they are the same version" seems contradictory to me? --Marsupium (talk) 15:57, 9 April 2019 (UTC)
"Separate, but similar" means "two different engravings of the same subject". If this were the case, then 2 items would be acceptable. This is not the case. Jane023 (talk) 18:03, 9 April 2019 (UTC)
Jarekt, yes, please don't merge them! If they are different physical exemplars it should be allowed to have separate items for them and we even need them for the photo or scan description on Commons because such a photo will be a photo of one physical exemplar. And Snowdon, North Wales (Q24176001) and Snowdon, north Wales (Q24176005) shouldn't have the same file in image (P18) because it's just of one of them (@Sic19). Or was File:Snowdon, north Wales.jpeg different from File:Snowdon, north Wales.jpeg? Then for evidence it should have been neither deleted nor redirected!
The inventory number should cases like Q24176001/Q24176005 be in the label I'd say or at least in the description.
Of course, we should also have an item for the edition/version of the two, but merging the exemplar items to a version item isn't a bad in my eyes. Perhaps the individual physical copies could be linked to the edition item with exemplar of (P1574). See Property talk:P1574#Widening for all works ?
For incunabula there are items like Biblia Latina [42 lines] (Q62052030) for individual physical edition exemplars and research projects like the Material Evidence in Incunabula database that collect such information. --Marsupium (talk) 15:57, 9 April 2019 (UTC)
Inventory numbers certainly do not belong in the label and I prefer not to see them in descriptions - we have an inventory number (P217) property for storing this information. Simon Cobb (User:Sic19 ; talk page) 17:37, 9 April 2019 (UTC)
Ok, maybe not in the label. The first sentence of Help:Description though reads: “The description on a Wikidata entry is a short phrase designed to disambiguate items with the same or similar labels.” So if the inventory number is the only difference between the two disambiguating them it should be in the description, that's what descriptions are for. --Marsupium (talk) 22:49, 9 April 2019 (UTC)

Please don't start merging items. This is an project that involves research into the relationship betweeen the versions and merging is potentially detrimental to this work. Aside from that, this collection/project is frequently used as an example of how GLAMs can use Wikidata to augment their existing metadata and I am concerned that merging would mean we no longer have the whole collection in Wikidata. There are definitely improvements that can be made but it would be preferable to let the people involved with the project work without interference. Of course, if there are actual problems you should talk to us and the community. Simon Cobb (User:Sic19 ; talk page) 17:37, 9 April 2019 (UTC)

Both items state quite clearly that they are part of the same book. Since they use the same image I assume they are of the same page. I suggest using the proper image and page numbers. As is, they should be merged. Jane023 (talk) 18:05, 9 April 2019 (UTC)
If the National Library of Wales (Q666063) has two physical copies of that book edition and that print is in both of them they are clearly two different physical things, no? Then you think in general we shouldn't have items for physical copies of prints, but just for their editions? --Marsupium (talk) 22:49, 9 April 2019 (UTC)
Hey if that were the case, then there would be two items for the books, but there is only one. Besides, this then becomes a wikisource issue, not a Wikidata issue. I am all for starting that conversation by the way, because I would like to see a new bibliographic project on top of Wikisource that gets rid of the language silos the works are locked into. I would also love to be able to directly reference all illustrations in Wikisource. But see Multichill's comments below - this has nothing to do with paintings. Shall we start a Wikiproject for engravings? Jane023 (talk) 06:03, 11 April 2019 (UTC)


@Jarekt: this is one of the reasons I started sum of all paintings and not sum of all art. You could call it the edition problem. We encounter it in multiple fields, most notably books, but of course also with prints and casts of sculptures. We generally have two things:
For paintings this is easy because the two are generally the same (exceptions like Bedroom in Arles (Q724377) of course exist). With prints with multiple notable copies you always end up with at least three items: One for the work, and at least two for the physical copies. Merging the copies becomes a nice mess of one work being in multiple collections, usually the use of applies to part (P518) is an indicator that it's time to split up the item. Currently I don't really spend a lot of time on fixing these kind of cases, because people keep importing statements to the concept item that should be on the physical instance item. Multichill (talk) 20:23, 9 April 2019 (UTC)
Sorry for starting discussions on topics not directly related to paintings. I work with files on Commons that use "Artwork" template, many are paintings and many are not. I have an issue with objects which only differ by institution inventory number. It is unusual with paintings, but I had quite a few paintings where I could not import titles into labels because there was another item with a different painting, but with the same title and description in some language I do not speak. If we allow an item for every inventoried copy of the same print or a book, than we might be running into the same problem more often. --Jarekt (talk) 03:26, 11 April 2019 (UTC)
@Jarekt, Jane023: no worries about starting the discussion here, it's just a quite hard problem with a solution where it's hard to distinguish between the different items.
I would tackle this problem in the order: painting series (Q15727816), sculpture series (Q19479037), prints. Not item to use for prints here because series of prints (Q19960510) doesn't seem to be the right one. It's the same print, with different copies. Multichill (talk) 15:33, 11 April 2019 (UTC)
Hi everyone, @Jarekt, Multichill, Marsupium, Sic19, Jane023: I have just seen this conversation. Taking the first example, I can confirm that these are two separate prints in the National Library of Wales collection. If you follow the links to our website at the beginning of the conversation you will see that there are different markings on each image. Most obviously, one has the name of the artist written in pencil in the bottom left corner. So we have two Wikidata items about 2 different (very similar) archival artifacts. A version of this print was published in a book as the data suggests but both now form part of the Welsh landscapes collection and the physical items are separate, loose pieces in this art archival collection - not bound in any volume. To add confusion, both wikidata items were using the same image from commons, but i have now corrected this. From a GLAM perspective its very important that we can share complete collections to Wikidata. Merging different items together breaks the link between catalogue entry and Wikidata item and reduces the accuracy and reuse value of the Wikidata. So please dont merge this or any other items which appear the same but have different identifiers/catalog numbers. Thanks! Jason.nlw (talk) 13:45, 12 April 2019 (UTC)
Thanks for the info but you are not out of the woods yet. If we (as a group of insiders) can't see what the difference is, then others will just come along and merge them for all the same reasons: Same book and same image, whether or not the piece of paper has different marks. I suggest slapping on the "Different from" property for all of these confusing image pairs until you have established why we need two each of them to begin with. You are treading n the edge of Wikidata notabily rules here I think, because "we need a complete collection representation in Wikidata" is not going to help you make friends around here. Jane023 (talk) 17:03, 12 April 2019 (UTC)
Hi Jane023 thanks for the feedback. I'm a little surprised that artworks which are part of a national collection in a national institution might be considered not notable. I know they are not always the most aesthetically pleasing images, but they are of significant historical value none the less. We have also put in a fair amount of effort to insuring that these items have good descriptive data, and supporting items such as Printers and Publishers. I think adding the "different from" property is a good suggestion, and i will talk to @Sic19: about how we could go about doing that. Thanks for your patience Jason.nlw (talk) 10:54, 13 April 2019 (UTC)
Yeah welcome to my world! If it's a painting, you have a better chance, but other artworks are much less popular. And among the paintings we also have notability issues. We tend to hang out in our little GLAM bubble, but we do not have any policies that say "everything inventoried in national collections is worthy of an item". I would be inclined to vote yes on that one though, if someone writes it up. Jane023 (talk) 11:10, 13 April 2019 (UTC)
Jane023, I am in broad agreement with the points you have made. While not directly relevant to the discussion about merging items, I think it is worth mentioning that these items were created over two years' ago and have been the topic of blogs and conference presentations. Generally, the response from the community has been positive. Obviously I am very bias, but, for me, the Welsh Landscape Collection remains a useful example of how Wikidata can be used to augment metadata and I would prefer that these items are not merged at the moment. The Wikidata items are now correcting the errors in the metadata on Commons (and thanks to MisterSynergy and Jarekt for their help) so there is some benefit to retaining separate items.
individual copy of a book (Q53731850) can apparently be used for a digitised copy from a specific library. For example, On the laws and practice of horse racing (Q51514189) and On the laws and practice of horse racing, etc., etc (Q51425849) appear to be the same 1866, 2nd edition with the difference being the library stamps and markings on the digitised image. We don't even have images from these particular copies on Commons - the only image of this edition is from the Tufts University copy on Biodiversity Heritage Library (Q172266). To the best of my knowledge, neither the work nor edition are especially rare, valuable or of other special importance. If importing different digitised copies from archive.org is acceptable practice it would be inconsistent if we tell GLAM partners not to do similar with material from their collections. Simon Cobb (User:Sic19 ; talk page) 12:26, 13 April 2019 (UTC)
This issue is in two parts: 1) notabilty and 2) avoiding merges. For the first see my points above - no presentations will help you. That two years have passed is no surprise (this is not super popular stuff). For the second, you need to make sure it is obvious from the items that they are not the same thing and what their "claim to uniqueness is". Jane023 (talk) 13:01, 13 April 2019 (UTC)
The items are notable per WD:N#2. I don't see any problem here. The question is about the best modelling. I'll look into FRBRoo (Q5427036), might help. --Marsupium (talk) 14:42, 13 April 2019 (UTC)
I think all those works are notable, however I was assuming that different copies of the same print are still the same print, even if the institutions might have different inventory numbers for them. It is kind of like with books, I imagine having items for individual editions but not for copies, even if a library has different bar code with unique ID for different copies of the same book. That way if a book or print has 100,000 copies we will not end up with 100,000 items for them. Items for individual copies would be OK for very valuable or rare items that might have unique provenance (object history) we want to keep track of, but if the only difference between 2 items is institution and inventory ID than I would vote for keeping them as one item. --Jarekt (talk) 18:43, 13 April 2019 (UTC)

My two cents: we should keep separate items for separate copies if external references say so. So I wouldn't merge. And yes, having a structure like FRBR (wich is already use for books) could be useful to avoid to much redundancy in statements. Cheers, VIGNERON (talk) 16:42, 14 April 2019 (UTC)

@Sic19, Jarekt, Marsupium, Jane023, Multichill, Jason.nlw: It would be useful to have an item other than print (Q11060274) for the items to be instance of (P31), when the item is intended to be for a single specific copy, rather than for a whole edition. For books we have individual copy of a book (Q53731850), though it's not much used yet, and the name may not be brilliant (eg because one might want it to include a physical copy of a work with multiple volumes). Would a new item for "individual copy of a print" be a good idea? (Name could be up for improvement). Jheald (talk) 18:04, 16 May 2019 (UTC)
@Jheald: Thanks for bringing this forward!   Strong support for an "individual copy of a print" item, another label possibility would be "print exemplary", but "individual copy of a print" is perhaps even more clear. Please go forward and create the item! We could then also create a common superclass of that item and individual copy of a book (Q53731850) which would be equivalent class (P1709)<http://erlangen-crm.org/efrbroo/F5_Item>, the FRBRoo class for "This class comprises physical objects (printed books, scores, CDs, DVDs, CD-ROMS, etc.) that carry a F24 Publication Expression and were produced by an industrial process involving a F3 Manifestation Product Type." --Marsupium (talk) 18:35, 16 May 2019 (UTC)
New item individual copy of a map (Q63872468) now exists. Jheald (talk) 10:19, 17 May 2019 (UTC)
Thank you. I've renamed individual copy of a book (Q53731850) to make it align the wording. --Marsupium (talk) 11:55, 17 May 2019 (UTC)
@Jheald: This seems like a good suggestion to me, and certainly fits in with the GLAM approach to cataloguing and describing items. I would support the creation of an "individual copy of a print" item, and would be happy to go back over past uploads and make use of it. Jason.nlw (talk) 12:56, 20 May 2019 (UTC)
Not sure what your metadata looks like, but ideally, things that are *instance of* an "individual copy of a <fill word in here>" would link to the original thing (or supposed original, or former original no longer in existence or no longer known location etc). I think having items for multiple copies of notable prints is desirable, but maybe not if they don't link to each other somehow. Normally I would say the link (star-like linking concept) to the original is key, but I also know from experience that scholars disagree on origins of such things. The general goal is to reduce confusion for those that come after you on an item-by-item basis. Jane023 (talk) 16:11, 20 May 2019 (UTC)

“individual …” items' details

Just catching up on the discussion above and this is related. It also applies to paintings before photography, in the time when "museums" were a new thing in many communities in the late 18th and early 19th centuries. Creating "individual copy" for things like old casts of artefacts like dinosaur bones or the Nefertiti bust seems like a good idea for more things than maps, not just for paintings and prints of them. Jane023 (talk) 12:16, 17 May 2019 (UTC)

Watercolors and lists of paintings...

@Multichill, Yann: and   WikiProject sum of all paintings has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.

Hi,

As was said here, I added watercolor painting (Q18761202) as P31 to many of Paul Cézanne (Q35548) works. As a consequence, those are not listed in Wikidata:WikiProject sum of all paintings/Creator/Paul Cézanne.

As watercolor painting (Q18761202) is a subclass of painting (Q3305213), shouldn't the query for the list be modified to include subclasses ? --Hsarrazin (talk) 19:29, 2 June 2019 (UTC)

Redesign this page

  WikiProject sum of all paintings has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. This page is outdated and in need of a redesign. Anyone willing to pick this up? I would probably focus on:

Within these focus areas we have several views of the data based on properties:

And more like genre (P136), inception (P571), etc. Do have a look in Category:WikiProject sum of all paintings. It contains a lot of pages not linked from the main page. Who wants to help? Wikidata:WikiProject sum of all paintings/Sandbox is probably a good starting point. Multichill (talk) 16:15, 8 June 2019 (UTC)

Does

  WikiProject sum of all paintings has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.

work now? Multichill (talk) 19:46, 8 June 2019 (UTC)
Yes I got this ping. I agree it would be nice to redesign the page, perhaps with as little text as possible (due to translation concerns). Not sure how to approach the problem, but ideally we could make a "list of lists", maybe split out per country for national collections? Jane023 (talk) 19:56, 8 June 2019 (UTC)
Makes sense to me.--Ymblanter (talk) 21:12, 9 June 2019 (UTC)

Pasquale Celommi

 
You might need to do a major metadata cleanup once you have matched the data to Wikidata properties, so be careful what you promise!

Hello everyone! Recently I've been in touch with an heir of Pasquale Celommi (Q3897025) (1851-1928), that wants to collect a big catalogue of its great-grandfather's paintings and build an official Web site for listing all the paintings' pictures and data. Since all the works are now in public domain, I suggested him to:

  1. publish all the data with an open license (CC-BY, since he would like to be cited), being very clear on the fact that all the data can be reused also for commercial purposes;
  2. associate a public identifier to every painting item;
  3. connect all the painting's items to Wikidata and, when it's possible, to the catalogue on the Ministry of Arts and Cultural Heritage's Web site (beniculturali.it).

Now, here's my question. I would like to:

  1. know if Pasquale Celommi (Q3897025) is a suitable painter for this project, and if I can import an item for all the paintings that will be uploaded to the official Website (celommi.it), that now is under construction;
  2. ask for the creation of a new property, such as "Celommi.it ID" for linking, in turn, to this Web site.

Do you have any remark or tip about this proposal? --Horcrux (talk) 16:57, 31 July 2019 (UTC)

As a painter the works and associated items are all welcome, but as you know, the files are hosted in the US officially and fall under US copyright. We cannot guarantee that anyone will respect the "-BY" part of your CC-BY recommendation, because for Commons the works are PD-Art and for Wikidata, the data is all CC0. You may want to explain that to them. Their licensing on their website may be relevant to parties within their juresdiction, however. Jane023 (talk) 18:38, 31 July 2019 (UTC)
Sure, thanks. --Horcrux (talk) 18:59, 31 July 2019 (UTC)

Cincinnati Art Museum

SELECT ?item ?itemLabel ?itemDescription
{
	?item wdt:P195 wd:Q2970522 . 
    MINUS { ?item wdt:P18 [] }
	SERVICE wikibase:label { bd:serviceParam wikibase:language "en" }
}

Try it! From my experiments on #Import_from_..._Commons above, I found that there are plenty of images at c:Special:Search/cincinnati incategory:"Paintings_without_Wikidata_item" (555 results) that could be added to some of items in the query above (currently ca. 2178 items). --- Jura 10:30, 1 August 2019 (UTC)

True! And that is only the group of images with artwork template. There are more with information template that should be linked and/or have QIDs added to them. Jane023 (talk) 12:40, 1 August 2019 (UTC)
Now that Commons has statements, maybe there is a way to add a statement to each painting identifying that the file is a reproduction of a painting. Or is there already a category? --- Jura 17:18, 2 August 2019 (UTC)

Detail of painting

Going through c:Category:Paintings without Wikidata item, I found a few that are details of paintings. It would be good if we had a structured way of stating that, e.g. Wikidata:Property proposal/detail of painting. --- Jura 18:55, 2 August 2019 (UTC)

One of .. or possibly another

For images like File:L'empereur Napoleon III de Franz-Xaver Winterhalter.jpg, it might be worth having a property at Commons that could be used to temporarily add some hypothesis about the one it is. Special:Search/Napoleon III Winterhalter finds 3 similar ones. --- Jura 19:57, 2 August 2019 (UTC)

Import from ... Commons

It seems there are plenty of paintings in Commons without items here. I just created Q65996002, Q65995829, Q65995393 for such. Once digital representation of (P6243) defined for existing ones, it might be worth doing an import. --- Jura 13:58, 30 July 2019 (UTC)

I did some in the past, but the data quality is generally not very good and the formatting differs quite a lot. Made it quite hard to ingest it with a robot. Instead I looked what collections had a lot of images and tried to find data at the source for these collections. Still might be worth trying to extract some data. Jarek did all sorts of quick statements magic. Maybe a quickstatements link can be added to files about paintings without an item that creates a new item with as much info as is available? Currently Category:Paintings without Wikidata item contains 88,319 files, but also 51 subcategories. Would be nice if these subcategories would be linked up with items here. Multichill (talk) 21:10, 30 July 2019 (UTC)
Thanks for creating those items! Yes please set up a bot, but your bot needs to do two things: 1) check that on the Commons side that the image includes the whole painting (there are lots of paintings with detail shots on Commons) and 2) on the Wikidata side, that no item exists yet for this specific painting. So for painters like Georg Janny (Q15734493) or Eugene von Guerard (Q507521) this seems safe and your addition is valuable, but for popular painters like Francesco Guardi (Q318769) this should probably be done as a separate "per painter" project. Auction records often include lots of detail (not sure if Dorotheum has persistent urls or not though) and that url should go into P973. Even a bot that just gathers possibilities per painter would be great to have. I occasionally scan specific painter category trees with Petscan for paintings without Wikidata items and link or create as needed, but this should be set up more structurally. Jane023 (talk) 08:10, 31 July 2019 (UTC)
I will not be around first half of August, but once I am back I can work on the item-creation setup I had for c:template:Creator. If you add parameter "wikidata=create" than an   arrow shows up that allows you to create a new item and upload a ton of properties. The arrow will display if you just preview the change, so there is no need to save it. After the item is created than the item number needs to be added to the c:template:Artwork template. I would also only use it on images with working source link which would have to be manually added to described at URL (P973). --Jarekt (talk) 14:24, 31 July 2019 (UTC)
Oh that is very interesting - yes we are still missing a bunch of creators and I forgot some of those old creator templates have had a lot of wikilove over the years. It would be nice to get them into Wikidata too. Jane023 (talk) 15:23, 31 July 2019 (UTC)
At some point I added Wikidata items for all the creator templates on Commons that were not personal templates for Commons Users and did have enough information to tell apart from other people (usually name and dates of death and birth or some Authority control ID), I got c:Category:Creator templates without Wikidata link down to couple hundred templates. Now that category has less than 50 so it seems like someone added more Wikidata items or deleted some Creator templates. --Jarekt (talk) 16:28, 31 July 2019 (UTC)
For subcategories in c:Category:Paintings without Wikidata item, I would suggest the following work flow:
  • use your favorite way of creating new wikidata items. I like using javascript activated by adding importScriptURI("//www.wikidata.org/w/index.php?title=User:Yair rand/WikidataInfo.js&action=raw&ctype=text/javascript"); to your common.js on any project. That way you will get Wikidata item ID on top of every page linked to wikidata and "Wikidata item not found." for pages which are not linked. Clicking on that text creates a new item and adds a sitelink.
  • Add the item ID to the c:template:Artwork template on the category page and to the Artwork templates in the files and press on   arrow to transfer properties using quickstatements.
  • Add URLs, accession numbers, etc. which were not added by quickstatements.
I used that approach on Q66023551, Q66023543, and Q66023532. It goes quite fast. --Jarekt (talk) 16:28, 31 July 2019 (UTC)
The second step seems to be done by Multichill's bot. Once that added, your QuickStatements batches add a lot of information. I'm wondering how much checking for prexisting items is needed.--- Jura 22:32, 31 July 2019 (UTC)

The painter and his workshop

Following this description about creator (P170), when he/she is unknown but known that the painter was the artist's workshop, we must use:

⟨ painting ⟩ creator (P170)   ⟨ anonymous (Q4233718)      ⟩
workshop of (P1774)   ⟨ artist ⟩

But, how it should be described when the creators are both, the artist & his workshop ?

Option A, as two creators
Option B, as a qualifier. It is, changing anonymous (Q4233718) by the artist name

However, I found this discussion. Is it the presents ontology for anonymous ?. If so, what are the present function of the collection of properties described in the original topic ?

Thanks, Amadalvarez (talk) 17:26, 13 August 2019 (UTC)

I prefer option A because option B just looks confusing. For paintings where more than one identifiable painter is attributed, you have two creator statements anyway. That said, I would approve an item (instance of "group" or "duo", so not Q5, where known members of said group can be added with start and end dates) for "Workshop of XYZ" and then add this as a line to the creator XYZ. For some painters with lots and lots of pupils (like Rembrandt) this is more information than just "anonymous", especially because we know pretty specifically who his pupils were at any given time. Jane023 (talk) 18:34, 13 August 2019 (UTC)
Is there some elegant way to use together with (P1706) to indicate "painter" <together with> "workshop of painter"? - PKM (talk) 19:52, 13 August 2019 (UTC)
@Jane023: I agree with you. The formula of "group" in this case doesn't aplly, because the painter of workshop are not really known.
@PKM:It's a good idea. When I found the collection of properties for every situation (workshop, follower of, circle of, possible creator, school of, etc.), I thought it was more efficient to use a generic property (sourcing circumstances (P1480), for example) and to have concepts like "XYZ school," etc. as a values. The reality is that with the present ontology, using together with (P1706) or sourcing circumstances (P1480) forces to create items that do not exist right now. But I will use your solution a soon as I have an opportunity. Thanks to both of yours, Amadalvarez (talk) 20:51, 13 August 2019 (UTC)

Dayton Art Institute

SELECT ?item ?itemLabel ?itemDescription
{
	?item wdt:P195 wd:Q2970522 . 
    MINUS { ?item wdt:P18 [] }
	SERVICE wikibase:label { bd:serviceParam wikibase:language "en" }
}

Try it!

c:Special:Search/Dayton Art Institute incategory:"Paintings without Wikidata item"

Might be the opposite of the Cincinatti museum: many files (ok 55) and few items (22): so suitable for item creation in bulk. --- Jura 17:48, 2 August 2019 (UTC)

So images remain in the maintenance category despite Wikidata items being available. --- Jura 10:21, 28 September 2019 (UTC)

Format

I know we discussed this before, but I don't recall whether a proposal was launched or not. I am looking for a property to say whether a painting is lanndscape, portrait, horizontal oval, vertical oval or round. I am also not sure if "round" = "tondo". While I am on the subject, I noticed lots of institutions include measurements for with & without frame and we generally use "without frame" because we generally have paintings without the frame. Is there a way to include both? Also, is there a "thickness" property? for some paintings with complicated sculpted framing this is an issue for installations and could be of interest. Jane023 (talk) 07:08, 25 September 2019 (UTC)

@Jane023: You can use applies to part (P518)picture frame (Q860792) as a qualifier to the dimensions with frame. And there is thickness (P2610). I don't know about the format. Probably shape (P1419) is too specific? If found we could add instructions to Wikidata:WikiProject Visual arts/Item structure#Dimensions. --Marsupium (talk) 08:44, 28 September 2019 (UTC)
Oh I do like those ideas, thanks! Yes I think since we have a lot of dimensions already imported, just adding extra dimensions with applies to part (P518)picture frame (Q860792) would work for "with frame". Also if we have thickness (P2610), then this would work for both the frame and the painting surface. Now all we need is format, and I am not sure if shape (P1419) was designed for this, but I think we could certainly use it for this. Jane023 (talk) 08:55, 28 September 2019 (UTC)
On a related point, I find it useful to have an image with the frame or even some of the surroundings, but I'm not entirely convinced that it's a good idea to add both with P18. An option could be to create a separate property for this. What do you think? --- Jura 07:43, 1 October 2019 (UTC)
Yes I am also a fan of situation settings including frame. I agree completely and have wondered the same thing. I also wonder if it should be a qualifier on the P18, so you could use it on all those bust detail shots on Qxxx people items. Jane023 (talk) 08:04, 1 October 2019 (UTC)
You mean like Q2421797#P18 from Q69384933 or Q1106692#P18 from File:Coenraad_van_Heemskerk.jpg? (first two I could dig up).
Somehow I think statement is subject of (P805) would work better for that.
I suppose we still have to make sure people don't overwrite one with the other: File:Bernhard_von_Liewen,_1651-1703_-_Nationalmuseum_-_14831.tif#filehistory --- Jura 09:18, 1 October 2019 (UTC)
Good points. I was thinking of cropped paintings that have items, such as the bust illustration for Jan Gildemeester (Q2663888), but of course there are crops all over the place in use where we either don't have the original, or where the original doesn't have an item (due to lack of notability or just not yet). Jane023 (talk) 14:19, 2 October 2019 (UTC)
I had thought about these (see #Detail_of_painting above) and proposed a new property to link them primarily on Commons. Prints are obviously another problem. --- Jura 11:40, 4 October 2019 (UTC)
Went ahead and proposed Wikidata:Property proposal/image with frame. --- Jura 08:14, 5 October 2019 (UTC)


I think c:Special:Diff/368818513 is a case for a revert (and upload of the new version under a different name)? I'd say it's against c:COM:CROP. --Marsupium (talk) 13:55, 2 October 2019 (UTC)
Yes. When the frame is included and accounted for (in this case, the uploader was the museum who granted rights to the "frame sculpture"), then that should definitely be preserved. Good luck trying to convince the overwriter though. Jane023 (talk) 14:13, 2 October 2019 (UTC)
@Jane023, Jura1: What about adding a second image (P18) with applies to part (P518)picture frame (Q860792) qualifier with normal rank and setting the image (P18) without frame to preferred rank? So on retrieval one gets the version without frame unless the queried specifically. --Marsupium (talk) 13:55, 2 October 2019 (UTC)
Interesting - I never really tried querying anything with ranks before. I like the idea if I can get comfortable building those queries. Jane023 (talk) 14:14, 2 October 2019 (UTC)
AAT has concepts for this (portrait format) but WD doesn't seem to have them, so I suppose they might be instances of page orientation (Q1282315). Then of course we'd need a property ... PKM (talk) 23:45, 1 October 2019 (UTC)
  • BTW, If several values are given (e.g. dimensions with or without frame), I'd add a qualifier to mark explicitly also "without frame". --- Jura 11:40, 4 October 2019 (UTC)


Question about a painting with conflicting descriptions

The painting Mrs Agneta Yorke (1740-1820) (Q52305651) has different and contradictory titles (and subjects) at different websites: artuk.org calls it Lady Elizabeth (Scot) Lindsay (1763–1858), Countess of Hardwicke, thus depicting Elizabeth Yorke, Countess of Hardwicke (Q68578542), while National Trust calls it Mrs Agneta Yorke (1740-1820), thus depicting Agneta Yorke (Q68975126), and notes that the sitter was formerly identified as the Countess of Hardwicke, but is now thought to be Agneta Yorke. There is an uploaded image of the painting on English Wikipedia, and I'd like to make sure it has the most authoritative title/file name before moving it to Commons. My questions are: 1: Can we assume that the National Trust data is more current and authoritative than Art UK? And 2: have I properly indicated the alternate titles and identities on Q52305651? Thanks, -Animalparty (talk) 02:40, 29 September 2019 (UTC)

This happens all the time. The best practise is to upload the file to Commons using the file description at the source (in this case either National trust or Art uk). Then in the description field make a note of the fact that one source says it depicts one lady and the other source makes the newer claim. The item does this for the depicts field. Since they were relatives, the likeness could be used for both (we have examples of this done for men on Wikipedia too, but I just can't remember who). Jane023 (talk) 08:09, 29 September 2019 (UTC)
Ah I found one I corrected because the guy's brother had a wiki page but he didn't. Here is Jean Charles Sapey (Q66490995) and his portrait by Vigée-Lebrunn is still in use for his brother in the French Wikipedia. Jane023 (talk) 08:17, 29 September 2019 (UTC)
Jane023 Thanks. I went ahead and uploaded the image under the name associated with the EXIF metadata: File:George Romney - Lady Elizabeth (Scot) Lindsay (1763-1858), Countess of Hardwicke.jpg. -Animalparty (talk) 15:08, 29 September 2019 (UTC)

Artist's signature on painting

Statements for inscriptions usually include the artist signature. Should we include a crop or a detailed view of these as image as well? It might make it easier to compare them between works.

I don't think the existing signature (P109) would be suitable as it's meant for items about people and its definition of "signature" somewhat differs. --- Jura 12:26, 5 October 2019 (UTC)

I noticed that for many signatures, the work isn't identified. While some images have some other source indicated, most don't. This makes the use on Wikipedia somewhat problematic.
Cropping might sometimes be possible, but resolutions of images on Commons aren't always up to it (as mentioned by @Calliopejen1:).
The many close-ups by @Sailko: are most helpful. --- Jura 08:50, 2 November 2019 (UTC)
@Jura1: I'm thinking of three possible ways to use this new property:
  1. In the creator's item
  2. In the work's item
  3. As qualifier, below the full image of the work
Which ones are correct? --Horcrux (talk) 08:58, 2 November 2019 (UTC)
As creator's signature (P7457) was defined, it's #2.
For #1, there is already another property. --- Jura 09:04, 2 November 2019 (UTC)

Property for city of origin?

Is there a way (or need) to indicate the place a painting was created at a finer scale than nation? Something like country of origin (P495) but for city or county? For example, an American artist may have been active in New York, San Francisco, and Chicago, detail not otherwise recorded for a work (and maybe their "Chicago period" is markedly different from their "New York period"). And works are sometimes separated by location in catalogs and comependiums, as Robert Lee MacCameron painted portraits in New York, England, and Paris according to this exhibition guide. -Animalparty (talk) 03:42, 2 November 2019 (UTC)

Note: Template:Artwork on Commons has a field for place of creation already, so inter-wiki compatibility would be enhanced. -Animalparty (talk) 04:39, 2 November 2019 (UTC)
@Animalparty: Use location of creation (P1071). You can see it in action at Wikidata:WikiProject sum of all paintings/Creator/Vincent van Gogh. Multichill (talk) 12:48, 2 November 2019 (UTC)

Help needed with problem images or items

c:Category:Artworks_with_mismatching_structured_data_P6243_property contains files with Structured data on Commons (SDC) digital representation of (P6243) properties which are different from what the file is linked through through wikidata property of c:template:Artwork. I was working for some time checking those and many are clear mistakes in either wikidata property of c:template:Artwork or with SDC's P6243, in some cases two items are correct and need to be merged, sometimes wrong image was added to one of the items for which we did not have correct image. For all those reasons it take a while to untangle some of those cases and I would appreciate if some experienced users help with some of them. Thanks --Jarekt (talk) 01:32, 12 November 2019 (UTC)

@Multichill: can you look at your Q21614463 and Q21614466 they seem the same to me but they are based on different "KMSKA work PIDs", which I can not access. --Jarekt (talk) 02:21, 12 November 2019 (UTC)
@Jarekt: late reply. Looks like every part of the triptych has an inventory number?
Looking at Wikidata:WikiProject sum of all paintings/Collection/Royal Museum of Fine Arts Antwerp I think I figured it out. The Adoration of the Magi Triptych (Q21614459) (208-210) is about the whole thing, we have three items for the three parts (208, 209, 210) and we have two items for the back (209bis and 210bis). Multichill (talk) 22:15, 4 December 2019 (UTC)

painting on a moveable support (Q20900710)

Should this subclass of painting (Q3305213) be used or replaced with its parent?

I don't really see an advantage of some items using this while most others just use "painting". Fresco are generally marked otherwise anyways. --- Jura 10:10, 22 November 2019 (UTC)

Agree - it might be useful to have some property to indicate the other way around, for paintings that seem to be moveable but are designated immovable due to donation restrictions, religious restrictions, or physical fragility, etc. Jane023 (talk) 10:37, 22 November 2019 (UTC)
@Jura1: To me painting (Q20900710) is closer to panel (Q1348059). I think the word "portable" in english label doesn't help to understand the meaning of the related articles. Agree with your proposal.
@Jane023: The property to inform movement restrictions you mentioned, I think is use restriction status (P7261).
Thanks to ping me. Amadalvarez (talk) 05:21, 25 November 2019 (UTC)
No I wouldn't merge it but just re-use it in the literal sense, such as here File:Moving Rembrandt's 'Nightwatch'.jpg. Jane023 (talk) 16:00, 3 December 2019 (UTC)
I didn't come near painting (Q20900710) because I think most works using it don't come close to the quality standards we use. Looks like it got merged, I hope some people will spend time on cleaning out the different reports. Multichill (talk) 22:10, 4 December 2019 (UTC)

Finding Asian Art

Quite a bit of art from Asian countries like China, India and Japan ended up in collections outside of Asia. I updated my bot to add location of creation (P1071) to works for which an Asian country is known. See for example Su Dongpo in a Borrowed Hat (Tōba tairyū zu) (Q78610117), Hanuman in His Tantric Five-Headed Pancha Mukha Form (Q78607253) and Worship of Lord Jagannatha in His Temple at Puri (Q78607334). I hope this increases the discoverability of these works. @Fuzheado, Wittylama: you brought this up, please spread the word. Multichill (talk) 13:44, 15 December 2019 (UTC)

Multichill Thanks for doing this. Is there a reason you used location of creation (P1071) for India (Q668), Japan (Q17), etc., instead of country of origin (P495)? While an item can have both properties,It's my understanding that P1071 is intended to be used more for cities or areas more specific than nations. -Animalparty (talk) 18:36, 17 December 2019 (UTC)
To have one consistent way to indicate where a work was made. Worst case: Earth (Q2), slightly worse: Asia (Q48), better: India (Q668), best: most specific location. Multichill (talk) 19:38, 17 December 2019 (UTC)

Europeana Entity

  1. Europeana entity (P7704) is created and > 100 000 artists(agents) has been matched with WIkidata see T240290
  2. Places and concepts has not been matched yet ( I am not convinced that the Europeana approach is the best using geonames)
  3. I can see that working with Things(entities) instead of strings need a new level of change management. Example metadatadebt:
    1. Europeana reference > 1200 deleted WD objects see T240738
    2. I see no version history at Europeana and change management tools for coordinate problems between platforms see T240809 were it looks like Europeana has matched objects created by "Gunnar Wennerberg" to Gunnar Wennerberg (Q1388588) that I guess is created by Gunnar Gunnarsson Wennerberg (Q6339160)
    3. Europeana also need a workflow of creating new Agents like Gunnar Gunnarsson Wennerberg (Q6339160) and Wikidata need a change stream from Europeana so we can update Wikidata
    4. People whos works are likely in the public domain 2020
      1. search for people who died in 1949 sorted by number of Wiki articles (linkcount) and if they have an Europeana Entity

My believe is that Wikidata <-> Europeana has a huge potential now when they get stable persistent entities.... If someone could help Europeana define change management and define how Europeana and Wikidata better can corporate that would be excellent... The most intresting part in this equation I feel is if Wikidata creates new properties for archives and museums and starts to match them using OpenRefine / Mix'n'match then Europeana could use this Wikidata information to match the Europeana objects to the right person easier so we avoid things like T240809. What I have seen in Sweden is that Linked data is not mature and archives still 2019 have no good change management and are moving around text strings which just will end in chaos... Hopefully Wikipedia with its visibility and Europeana with its resources could change this equation a little bit... I guess the key component is better understanding for data driven culture data.... - Salgo60 (talk) 03:44, 17 December 2019 (UTC)

sitter (P2634)

The use and purpose of model (P2634) is being discussed at Property talk:P2634#Purpose of this property. Feel free to contribute. -Animalparty (talk) 22:11, 23 December 2019 (UTC)

Return to the project page "WikiProject sum of all paintings/Archive/2019".