This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the
current talk page.
Hi all. At the request of @
Pharos, I've started a Wikidata version of this template at {{Infobox artwork/wikidata}}. The idea is that you just need to include that small bit of code in the article, and everything else will be fetched from Wikidata. If you don't want values fetching from Wikidata, then you can still define them locally and they will be displayed in preference to any values from Wikidata.
The long-term goal is that we can merge the Wikidata version into this template, so Wikidata information is available by default. However, some more development, documentation and testing work needs to happen before then to make sure that all parameters are supported and working well. In particular, the code for the dimensions is very complex at the moment, so I'm hoping we can simplify this in the new version.
Please test it, and let me know if you find any bugs! It is fine to include the Wikidata template in articles now, as we can easily migrate things over once this is more complete. Thanks.
Mike Peel (
talk)
13:52, 28 June 2017 (UTC)
Mike Peel - my initial feedback: I think it ought to indicate "collection" by default. Currently it ignores this parameter from Wikidata and only shows "owner" which is less useful in many circumstances. If we're showing a field called "Accession" (which actually should be "accession No." or equivalent) then we should be saying what institution that number comes from.
Wittylama21:03, 28 June 2017 (UTC)
@
Nikkimaria: is now edit-warring about this new template, without pointing out the problems so that they can be fixed. That's really not helpful. :-(
Mike Peel (
talk)
01:44, 29 June 2017 (UTC)
I've pointed out specific problems, and you've edit-warred them back in without fixing. It's really not helpful to do that. Further, |suppressfields= returns an unknown parameter error so can't be used to address issues on individual articles.
Nikkimaria (
talk)
01:47, 29 June 2017 (UTC)
To expand: in all cases but one (
The_Fall_of_Icarus_(Picasso)), location and collection are wholly or partially identical. Subject is also useless in the majority of cases, with the possible exceptions of
Saint_Cecilia_(Artemisia_Gentileschi) and
Au_Lapin_Agile - in most cases it's a long list of random descriptive keywords. Automatic import of both subject and one of location/collection should be removed. Thank you for fixing the edit link at least.
Nikkimaria (
talk)
02:11, 29 June 2017 (UTC)
@
Nikkimaria: This is new code, and unfortunately I can't guarantee that it will be bug-free right from the start, which is why test cases are needed to start with (and why sandboxes are needed once this is more widely used), and feedback on how the code is working in practice is really important. It also takes me a bit of time to debug errors and find solutions for them, which is much easier if I can see the issues live. Thank you for pointing out the errors, but please could you do so by posting them here rather than just reverting the edits?
I've now fixed the problem with the [edit on Wikidata] link - thank you for pointing out the problem. Unlike the other Wikidata templates, here I've been trying to support draft articles - which requires linking against a specific Wikidata ID rather than just reading the page's ID. I thought I'd implemented this in {{EditOnWikidata}}, but it wasn't correctly handling cases where no QID had been passed. It now does this correctly.
I was using
collection (P195) for the location rather than
location (P276). This was a mistake, and one I hadn't spotted when I implemented @
Wittylama:'s request above. I have now fixed this. However, it seems that the same information is present for both properties in the current examples. I think this is a specific issue with Met wikidata information that isn't present for other museums, so hopefully @
Pharos: can comment on this. I think that this is something that needs resolving on Wikidata - or if it can't be resolved there, then maybe we can check to see if the two properties are the same and only show one of them if that is the case.
Thank you for fixing the bug in the row numbers at
[1]!
I'll look into the suppressfields error.
In general, I'm happy to fix bugs as they arise, please just let me know about them here. I'm hoping that there are a lot less subjective constraints here than there were at {{Infobox person/Wikidata}}, and that this is closer to {{Infobox telescope}} in terms of presenting factual information without arguing so much about whether a parameter should be shown or not. Thanks.
Mike Peel (
talk)
02:12, 29 June 2017 (UTC)
@
Mike Peel: The location/collection issue is present in almost all cases, not simply on Met works. The subject problem is definitely a subjective constraint and per above should be removed.
Nikkimaria (
talk)
02:16, 29 June 2017 (UTC)
@
Nikkimaria: On the collection vs. location issue, the collection should only be displayed now if it is different from the location. Please let me know if you spot any cases where this isn't working right. Thanks.
Mike Peel (
talk)
02:40, 29 June 2017 (UTC)
@
Nikkimaria: The suppressfields parameter should now be working without errors. The error was in the parameter checking code (I hadn't added it as a named parameter yet), not in the functionality. Please let me know if it still shows errors. Thanks.
Mike Peel (
talk)
02:47, 29 June 2017 (UTC)
I struggled a bit to get the dimension working with
https://www.wikidata.org/wiki/Q23939644. Not sure if I'm missing something. Another thing I noticed is that Oil on canvas, listed as an example for medium redirects to Oil painting. That's a bit weird; oil paint is a material, but Oil painting is not. Lastly, I think it would be nice to also have the described at URL property (P973) listed as website.
Mduvekot (
talk)
01:56, 29 June 2017 (UTC)
@
Mduvekot: Thanks for the feedback! With the dimensions, I think the problem here is that I have only enabled support for metric units at the moment, I will add support for imperial units soon. With the material, in cases like
Au Lapin Agile it now links to
oil paint, although in
older versions (where the link was locally defined) it linked to
oil painting. I don't know which is the best solution here, but it's possible to link to either of these on Wikidata and hence link to them here. With the URL, it might be better to use
official website (P856) here, as there can be many URLs with descriptions but a more limited number of official URLs. Thanks.
Mike Peel (
talk)
02:33, 29 June 2017 (UTC)
@
Mduvekot: I've now implemented support for inches (but not feet/metres/other units yet). I've changed the Wikidata values for
My Shanty, Lake George to link to oil paint and canvas. I've changed the infobox there so it is mostly fetched from Wikidata, except for the subject (as per the discussion with Nikkimaria above about what this should contain) and the URL (as per my comment just above). Please have a look and see if it is working as expected, and please give feedback on the subject and URL issues! Thanks.
Mike Peel (
talk)
03:09, 29 June 2017 (UTC)
Wikidata version: location vs collection
First of all, thanks for this - I love it! Now addressing some of these concerns, starting with location vs collection: this is particularly sticky and gets interpreted differently (some people feel temporary exhibition locations belong under location, but I feel that is wrong and am on the fence about long-term loans). I would say stick to collection, since that is where the accession number comes from. For multi-site collections (National collections of Sweden, etc) then location might be some castle. Maybe you can try to check for whether location is a castle?
Jane (
talk)
06:21, 29 June 2017 (UTC)
@
Jane023: Thanks for the feedback! I've changed the logic so that collection is shown, and then we show location if it is different from collection (rather than the other way around). Identifying specific types of locations would be very tricky to do. Thanks.
Mike Peel (
talk)
17:32, 29 June 2017 (UTC)
@
Nikkimaria: Thanks, I'm looking into it. I think it's a bug in the dimensions code that I've just been working on that is causing the next line to not display its key. Thanks.
Mike Peel (
talk)
00:40, 30 June 2017 (UTC)
@
Nikkimaria: Assuming the issue was the 'Coordinates' label not showing, this is now fixed. The label is set to display=none in the main version of the infobox, apparently so that the coordinates look like part of the location field, which is now not always shown. Thanks.
Mike Peel (
talk)
13:25, 1 July 2017 (UTC)
I've changed the code today to use {{Wikidata location}}, which will also fetch the city/country of the artwork if appropriate (e.g. at
The Tree of Knowledge (mural)). I'm not sure what to do with the logic checking code here now, though - it is useful to display the rest of the location even if P276 is the same. So for now I've changed it so that the collection is hidden if it's the same as P276 (sorry @
Jane023). I'll have a think about whether there's a better way to do this, but suggestions would be welcome! Thanks.
Mike Peel (
talk)
21:11, 20 July 2017 (UTC)
Would love to see all authority control numbers linked and for large museums this would also negate the need for the collection problem above, since they often have their own property with their own link.
Jane (
talk)
06:21, 29 June 2017 (UTC)
@
Jane023: I've included two authority control properties at the moment, namely
The Met object ID (P3634) and
RKDimages ID (P350). I'm happy to add more - is there a list of applicable properties that I can use? I'm not sure how to get the URLs for the IDs at the moment (I've had to hard-code the URLs for the current two), but once that's figured out then it should be straightforward to scale this up to cover more properties. Thanks.
Mike Peel (
talk)
17:34, 29 June 2017 (UTC)
Hmm I am also not sure about the whole list, but once you get the properties, then you can grab the prefix url from P1630 which is the "formatter url". For paintings located in the UK, the Art UK artwork ID is helpful (P1679) and for paintings located in France, the joconde ID is helpful (P347) and for paintings located in Germany, the bildindex is helpful (P2092). Other countries with such IDs are Denmark, Finland, and Belgium. Certain large museums have their own ID codes but I don't have a list. Maybe Multichill knows. Thanks for the RKDimages! Works great.
Jane (
talk)
20:11, 29 June 2017 (UTC)
Thanks @
Jane023: After a bit of work, I've now created {{Wikidata ID}} that can fetch multiple IDs at once and return them as a line-separated list. It works, but it uses a number of expensive queries - hopefully someone can come along and Lua-ise it to make it more efficient. The code in the template is {{Wikidata ID|P347|P350|P1679|P2092|P3634|qid={{{qid|}}}}} - it should support all of the properties you've mentioned. If you come across others, then they're easy to add. Any suggestions that @
Multichill or anyone else has would be welcome! Thanks.
Mike Peel (
talk)
21:50, 29 June 2017 (UTC)
@
Jane023: It looks like displaying IDs can be a bit messy, e.g. see the Art UK ID at
Self-Portrait Wearing a White Feathered Bonnet. I've implemented an option to not show the ID (and another to comma-separate rather than line-separate), in this case the difference is:
We have some pretty largish problems with date fields for artworks still, so maybe including date can be an option (when you know the work is definitely dated)
Jane (
talk)
06:21, 29 June 2017 (UTC)
Mike has made dates and other fields optional now. Ideally, explicit date ranges (e.g. 1450-1500) should be possible also when they are included on Wikidata, as is the case for a number of Met artworks. Though they can already be represented by decade or century in a number of cases.--
Pharos (
talk)
15:02, 29 June 2017 (UTC)
Dates from Wikidata (specifically,
inception (P571)) are displayed unless you locally override them (e.g., {{Infobox artwork/wikidata|year=}} - unfortunately the suppressfields parameter doesn't work for this at the moment, see
User_talk:RexxS#WikidataIB_oddity). Ideally we would get them right on Wikidata! Thanks.
Mike Peel (
talk)
17:46, 29 June 2017 (UTC)
@
Mike Peel: Could you work on updating the documentation, particularly with regards to what the parameter names are, how to suppress, etc? I removed the template
here because I couldn't work out how to suppress one, as the labels from the code didn't seem to work.
Nikkimaria (
talk)
01:12, 30 June 2017 (UTC)
@
Nikkimaria: Will do (but not today as I'm going offline now). Which parameter couldn't you suppress? In general, it would be useful if you can comment here about parameters that you think need suppressing, explaining why, so I can see if there is a general solution that will avoid the same problems occurring in the future. Thanks.
Mike Peel (
talk)
01:17, 30 June 2017 (UTC)
@
Nikkimaria: It looks like the article name was added to Wikidata and merged into the entry for the painting. It's not quite a duplicate (since one has "An" at the start), so I'm not sure how to automatically check for this. I've removed the alias from Wikidata and added back the template. I'm updating the documentation in another tab at the moment - I'll save the edit later today. Thanks.
Mike Peel (
talk)
23:54, 30 June 2017 (UTC)
I've modified it so it can be suppressed by setting other_title_1= for now. I'm hoping to add it to suppressfields in the longer term, but that won't work yet. Thanks.
Mike Peel (
talk)
22:09, 1 July 2017 (UTC)
Though provenance data is really important, I think the stuff listed under ownership is not really infobox-ready. I think we still need to think about things like how to model art provenance on Wikidata. In general it would be nice to override or turn fields on/off. I feel the same way about "depicts" and even the accession number in some cases.
Jane (
talk)
07:09, 29 June 2017 (UTC)
Perhaps ownership could be like collection/location, only listed if it is different from the others. I think Mike has enabled suppressfields now, and replaced "depicts" too.--
Pharos (
talk)
14:27, 29 June 2017 (UTC)
Ownership is now only shown if it is not the same as collection. It can also be suppressed using suppressfields=owner (although there is a bug that the reference is still shown - I need to find a way to fix that.) Can you elaborate on the other issues with this parameter, please? Thanks.
Mike Peel (
talk)
17:49, 29 June 2017 (UTC)
Yeah as long as you can override or suppress then fine. Ownership problems are e.g. that start/end dates don't line up the way you would do this in chronological order if you were listing them by hand. The accession numbers may also pile up in weird order when there is more than one collection but you just want to show the one for the location.
Jane (
talk)
20:14, 29 June 2017 (UTC)
Please point out any good examples that you come across of the problems here, and we can see if there are ways to sort them out. Thanks.
Mike Peel (
talk)
21:56, 29 June 2017 (UTC)
For some well-known painters, there is a "definitive" catalog, or sometimes 2 or 3 of these. Some painters have their works completely catalogued on Wikidata. Rembrandt for example has a fairly recent "definitive" catalog that is complete on Wikidata.
Portrait of Catharina Hooghsaet has the catalog number in the artwork template, but if you look at Wikidata, the item is in several other catalogs too. We may need a property "preferred artist catalog" or something to handle this, but maybe a work around is to include "/catalog=Q nr." ?
Jane (
talk)
06:30, 1 July 2017 (UTC)
Difficult cases?
Can anyone suggest some difficult cases to test the wikidata version against? The more we can test this now, the fewer problems we'll have when we merge this in to the main version (which I'm hoping we can do reasonably soon). Thanks.
Mike Peel (
talk)
00:35, 30 June 2017 (UTC)
I'd think that one way would be to look at any of the
painting articles currently listed as Featured quality. Many of them have quite small infoboxes, so they may not be technically difficulty, but they are ones where the information has been most closely scrutinised for its appearance. So, if you're able to get feature-parity with the present look, that would be something. I would suggest not trying to add new infoboxes where there currently isn't any - since some art-article writers particularly don't like infoboxes at all.
Here's an interesting one:
The Storm on the Sea of Galilee. Do try it out in preview mode (collection: Unknown value doesn't show up well I think). Due to the major theft, which is mentioned in the current static infobox: does it make sense to do something with P793 (significant event)?
Spinster (
talk)
18:40, 1 July 2017 (UTC)
@
Mike Peel: good job Mike! For paintings we record things that change over time on Wikidata: Collection, location and owner (and other things). On Wikipedia we only want to show the current collection, location and owner. Sometimes these are the same, but sometimes a painting is in multiple collections (for example a long term loan) or even owned by multiple organizations, for example
Portrait of Oopjen Coppit. Location is either Rijksmuseum or Louvre, it's in both collections and it's owned by France and the Netherlands. The
list of loans in the Rijksmuseum contains more fun edge cases like these. If some fields are the same (for example location==collections==owner), it doesn't make sense to show it multiple times so you'll need a decision tree here.
Multichill (
talk)
10:54, 2 July 2017 (UTC)
@
Multichill: Thanks for the feedback. At the moment the only way the code can distinguish between an important value to show and one that shouldn't be shown is by the preferred/normal ranks on Wikidata - do you think that would work here, or would some sort of system that looks for the value with the latest date be needed? (Which would be something I'd ask @
RexxS if he can figure out. ;-) ) Thanks.
Mike Peel (
talk)
13:44, 2 July 2017 (UTC)
We are likely to get into conflicts with community members when replacing classic infoboxes with this template, so it may help to share some experiences. One I ran into recently was the argument that " it's never an improvement to use [Wikidata-generated infoboxes] to replace a manually written infobox".
[2] It may help to make an FAQ to explain to folks why this new infobox method has its benefits. --
Fuzheado |
Talk08:02, 1 July 2017 (UTC)
Well I would agree (see the examples I posted). I have been replacing my own work and the work done by others on "super stubs" of less than 700 bytes.
Jane (
talk)
13:41, 1 July 2017 (UTC)
@
Fuzheado: I've written a bit of a FAQ at
User:Mike Peel/Wikidata-driven infoboxes - it still needs work, but it might be helpful here. I don't expect that we'll convince everyone, but we're adding functionality here that can be turned on/off as needed, so if people insist on keeping manually written infoboxes/lines in some articles then we can support that while using Wikidata information elsewhere. Thanks.
Mike Peel (
talk)
13:50, 1 July 2017 (UTC)
Materials (medium): The wikidata infobox just lists materials like Oil paint, canvas, but the old infoboxes used sentance like Oil on canvas. Is it possible to have that in the Wikidata too.
Christian75 (
talk)
21:39, 2 July 2017 (UTC)
And about locations (or collection as it says now). I find it less informative that e.g.
My Shanty, Lake George says
The Phillips Collection and not "The Phillips Collection, Washington, D.C." as it did before. With the new way you have to click on the wikilink to find the artworks location.
Christian75 (
talk)
22:26, 2 July 2017 (UTC)
Dimensions: I find it more easy to read "20 in × 27 1/8 in (50.8 cm × 68.8975 cm)" than 20 in (51 cm) × 27.125 in (68.90 cm) because I'm only interested in one part of the line, so I skip quickly if I see "in", but the new way I have to read it all. If anybody agree, it should not be diffucult to change.
Christian75 (
talk)
22:26, 2 July 2017 (UTC)
@
Christian75: I agree it shouldn't be difficult to change, but the dimensions code is currently a mess (see lines 63 through 134 in the non-wikidata version!). I will implement a better version, but it will take me a short time. In general, I'm busy for the next few days, but I'll work through your points (and others) when I can. Thanks.
Mike Peel (
talk)
09:51, 3 July 2017 (UTC)
References
Citations don't seem to work properly when they're something other than reference URLs. See for example
this version - on Wikidata there is a link to the full bibliographic details of the source, but here you can't really tell what the source is.
Nikkimaria (
talk)
01:41, 7 July 2017 (UTC)
That's definitely an improvement, thanks Thayts. Could we also amend the formatting? Obviously we can't account for every citation style, but I don't think any italicize location, for example.
Nikkimaria (
talk)
21:26, 8 July 2017 (UTC)
A number of artwork articles are not about an individual artwork, but about a series or other group of artworks. A good example is
Sunflowers (Van Gogh series). A point of failure in this case is multiple images values, which breaks the infobox. Perhaps also if the article is about a series, one could use
series (P179) to list the constituent works, or if something is a constituent work, to list the "mother" series.--
Pharos (
talk)
19:45, 11 July 2017 (UTC)
@
Pharos:part of the series (P179) can be used to indicate that a work is part of a series, but not for the other way around - a different property should be used to list works that are part of the series in the entry about the series. For telescopes at observatories I've been using
has part(s) (P527) and
part of (P361), but I'm not sure if those would be appropriate here. Thoughts? Thanks.
Mike Peel (
talk)
00:41, 12 July 2017 (UTC)
Type
I"d suggest a field for the basic type of artwork, e.g. painting, sculpture, drawing, print, photograph, vase, etc, where applicable. This would be based on
instance of (P31), although I think it might be good to abstract to a higher level and check (for example) whether something is in a subclass of sculpture.--
Pharos (
talk)
19:53, 11 July 2017 (UTC)
Links to "Anonymous" disambiguation page
A number of articles that use the Wikidata version of the template appear in
Special:WhatLinksHere/Anonymous, even if (in some cases) the work in question is not anonymous and the word "anonymous" doesn't appear anywhere in the article or in the associated Wikidata entry (for example,
Time Suspended in Space (South Africa). There are also some anonymous works in the list, but these should not be linking to the
Anonymous disambiguation page. Can anyone identify the cause of this anomaly? --
R'n'B (
call me Russ)
14:45, 18 August 2017 (UTC)
R'n'B, it is definitely coming from wikidata. in the example you cited, the wikidata entry was changed
here. it's possible that it just took a couple days for the "what links here" to update. as for the others that are using anonymous in the wikidata, I would imagine this is a more general problem with pulling information from wikidata, so perhaps, either VPT or
Module talk:Wikidata can help?
Frietjes (
talk)
17:06, 18 August 2017 (UTC)
@
R'n'B and
Frietjes: I've added a check for anonymous artists with
this edit, I think that should avoid some of these links. Others may appear if other anonymous is used for other properties on Wikidata, though. Thanks.
Mike Peel (
talk)
23:09, 18 August 2017 (UTC)
I think that would work, but it probably needs input from others (the wikiproject & wikidata project chat perhaps). Thanks.
Mike Peel (
talk)
14:13, 19 August 2017 (UTC)
Mike Peel, I believe there were a total of about 5 articles? would it be possible to track them? after your change, we can't find them with the whatlinkshere.
Frietjes (
talk)
14:37, 19 August 2017 (UTC)
@
Frietjes: In principle there are around 20,000, based on looking for paintings with anonymous creators - try running this at
http://query.wikidata.org/
SELECT ?painting ?paintingLabel WHERE {
SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
?painting wdt:P31 wd:Q3305213.
?painting wdt:P170 wd:Q4233718.
}
Creator : "attributed to" etc. values stores in qualifiers P1773 to P1780 (and P1877 ?) should have precedence over the main value of the
creator (P170) statement.
Material : support using qualifier P518 eg "oil on canvas".
(not sure it is the proper way to do it, but I feel we need one easy-to-read list.)
Not directly importable, but in case parts of it can be reused
fr:Module:Matériau uses P518 qualifiers to render strings like "oil on canvas" or "timber frame, steel and glass cladding". --
Zolo (
talk)
12:15, 24 August 2017 (UTC)
Many articles have had their infoboxes supplanted by links to Wikidata. This is a very ill-considered move. They look terrible (with little symbols and and unfamiliar links), subject their content to the vagaries and preferences of the individual editors of another project with its own arcane purposes, and have not been approved or even discussed here, which should have been done before any such wholesale changes were started.
Discussion about this has been taking place at
Template talk:Infobox artwork (also see
the talk page archive). The formatting can be changed if needed, just post a suggestion for how to do so on the infobox talk page and we can see what the consensus is. Wikidata is another *Wikimedia* project, same as Wikimedia Commons but for data rather than media. Thanks.
Mike Peel (
talk)
10:49, 8 September 2017 (UTC)
Mike, that is useful background, but I believe that members and other editors interested in this project-- the arts-- should decide whether to implement this change. In general, the subject of infoboxes is controversial, with many editors opposing them-- particularly in the arts-- on grounds argued elsewhere. But if an infobox is used, can we really say that the one currently used on
The Hay Wain is superior to the one it replaced? (See the former infobox on the
prior version of the article.) Is it important to have those tiny pencils? Should the beginning of an article prominently feature the accession number? or identifiers? And the "Preceding by" field is particularly fraught, and an invitation to original research and factual disputes. (Would anyone care to do a succession field for
The Burghers of Calais or
The Gates of Hell?)
Kablammo (
talk)
15:40, 8 September 2017 (UTC)
@
Kablammo: Please do have a look at the discussions I linked to. The request to develop the wikidata version came from editors working on these types of articles, and I then worked on developing the infobox based on the code I've been using in other cases (e.g. {{Infobox telescope}}). The code is currently mostly working, but a few more things need doing with it (in particular, the dimensions code can be better), and I'm hoping it can then be merged in with the main version of the template (it is only separate at the moment to make sure it all works right first). I've been rolling it out across some articles to see how well it copes with different situations and different amounts of Wikidata information, to make sure it at least reproduces the local versions. It might be best to keep the discussion all in one place, so perhaps we could move this to
Template talk:Infobox artwork and the other people I've been working with can join in this discussion (or we can ping them here if you'd prefer). I always appreciate constructive feedback, though, so thanks for your comments about this so far. Thanks.
Mike Peel (
talk)
16:20, 8 September 2017 (UTC)
Cross-posting my reply, to pick up discussion here: (
The Hay Wain version with Wikidata infobox was under discussion) I agree that the pencil icons and repeated footnotes are excessive ("[edit on Wikidata]" is sufficient, as would be a separate section for group footnotes, as done
in other infoboxes) but that can easily be discussed on the infobox's talk page. As for letting Wikidata handle the infobox parameters, I say good riddance—a massive waste of time in my watchlist. czar17:37, 8 September 2017 (UTC)
Oil paint, canvas
Just to note that if "oil paint" and "canvas" are both used in the material values on Wikidata, they should now be automatically replaced with
Oil on canvas. Please let me know if you spot any issues with this. Thanks.
Mike Peel (
talk)
20:28, 8 September 2017 (UTC)
Doing it value by value seems like an andelss job (tempera on oak panel, ink and colors on paper...). I think the better solution is to make use qualifiers. Painting support like canvas or panel are usually marked with "applies to part: painting surface" (P518 Q861259). A more general use of P518 qualifiers might also be useful (like in the "Matériau" row of
fr:Statue de la Liberté. It might make it harder to have just one link like in
Watercolor on canvas but I have to admit I don't really see why clicking on "canvas" should lead us to a page on watercolor painting. --
Zolo (
talk)
11:17, 15 September 2017 (UTC)
I am looking at
medium: Material used by the artist or designer to create the work of art. Examples: "Oil on canvas", "Bronze sculpture", "Ceramic tile"
and am thinking, "in an article about a statue" the medium field should just say, "bronze" or "limestone" or terra cotta" and not include the word "sculpture" in the medium field. We don't recommend saying "Oil painting of canvas" so why with sculpture? Einar ask
Carptrash (
talk)
19:04, 15 September 2017 (UTC)
Looking at The Horse Fair (which is our
Metropolitan Museum of Art Weekly Challenge!), I notice that two identical infobox-generated citations are given, with the only difference being the "retrieved" date. Maybe we could find a way to combine these into one reference on Wikipedia, and just list the different dates separated by commas, after the reference url.--
Pharos (
talk)
18:17, 22 September 2017 (UTC)
@
Pharos: This isn't easy to do in the code (since the references are fetched in different parts of the code that don't know about each other). The best thing to do is to tidy up the references on Wikidata instead, which is
a bit laborous but gives the desired result. Thanks,
Mike Peel (
talk)
21:25, 22 September 2017 (UTC)
Suppressing the secondary title apparently also suppresses the title, as seen in
this is; can this be fixed? It should be possible to suppress one without affecting the other.
Nikkimaria (
talk)
18:53, 2 November 2017 (UTC)
@
Nikkimaria: This is odd. It looks like {{#invoke:WikidataIB|checkBlacklist|name=title|suppressfields=other_title_1}} triggers the blacklist when it shouldn't. @
RexxS: is there a way of fixing the blacklist code here, or should we change to using something other than "other_title_1" here? Thanks.
Mike Peel (
talk)
21:36, 3 November 2017 (UTC)
@
Mike Peel and
Nikkimaria:The code is working as expected
. If you have a blacklist with the characters "title" in it, then a field called title will be suppressed. I wrote it that way so that it could cope with all varieties of alternative spelling in field names. If it only works with an exact match, then you'd have to blacklist "this field", "this-field", "this_field", and "thisfield", etc. for every conceivable permutation, rather than just blacklisting "field" as you can now. The downside is that infobox designers have to be a bit more picky about the words they use to name different fields, sorry. In your case, you could use e.g. |name=fulltitle when invoking WikidataIB in the infobox design (without changing the actual parameter name of title in all other places); and then you could use |suppressfields=fulltitle in an article. You'd just have to include a note to that effect in the infobox documentation. If you can think of a better scheme, I'd be happy to consider how to implement it (although I won't be implementing any more changes to
Module:WikidataIB while it remains unsynchronised from the development work). --
RexxS (
talk)
22:03, 3 November 2017 (UTC)
Thanks RexxS. Either way works, I think, so I'd say this is up to @
Nikkimaria as the main user of the suppressfields feature. I don't think there's any significant technical/logistical barriers in either way: I'm happy to write a bit of pywikibot code that goes around and checks for current cases of |suppressfield=title that could be changed to |suppressfields=fulltitle if that would help. Thanks.
Mike Peel (
talk)
05:35, 4 November 2017 (UTC)
Well, if the hope is to eventually use this more widely, it shouldn't be designed for me personally! But the argument against exact matching makes sense. What about changing the name of the secondary title parameter to altname or similar?
Nikkimaria (
talk)
15:37, 4 November 2017 (UTC)
@
Papuass: I think the problem is caused by multiple URLs on Wikidata, which are all equally ranked. At the moment, there are two solutions: either set a preferred URL on Wikidata, or set "| website=example.com" that should locally override it (it seems to work for me?). There is a solution in the works to retrieve a max of 1 URL from Wikidata, and I'll have a think about whether there's a good way to properly format multiple URLS from Wikidata (suggestions welcome!). Dimensions are also tricky in this case, with two panels, so I'd suggest locally overriding that one too (just keep the dimensions= line). Thanks.
Mike Peel (
talk)
21:32, 3 November 2017 (UTC)
Yes, this is complex case (that is diptych) ar there are 2 viable websites to show — one link for Adam, one for Eve. Right now I just made override with empty website. --
Papuass (
talk)
21:37, 3 November 2017 (UTC)
Better markup would be:
| website=
{{Plainlist|
* [https://www.museodelprado.es/en/the-collection/online-gallery/on-line-gallery/obra/adam/ Adam
* [https://www.museodelprado.es/en/the-collection/online-gallery/on-line-gallery/obra/eve/ Eve
}}
Switching to onlysourced=yes by default in the Wikidata version
@
Nikkimaria has been changing inclusions of {{Infobox artwork/wikidata}} to only show information from Wikidata that has a reference. To be honest, I can't disagree with this - if we can't reference the information that we're showing, then we shouldn't be showing it. So I've changed the default here to onlysourced=yes. This will remove information from infoboxes - please add references to continue showing this information. Thanks.
Mike Peel (
talk)
23:09, 7 December 2017 (UTC)
Hi
Mike, thanks, but I think this has broken the image formatting? Also, not sure it is currently possible to cite aliases on Wikidata...
Nikkimaria (
talk)
23:28, 7 December 2017 (UTC)
I'm working on other things at the moment. I'll circle back to this infobox when I can (or if anything comes up that needs urgently fixing). Thanks.
Mike Peel (
talk)
19:35, 11 August 2018 (UTC)
Edit request
@
Frietjes,
Ahecht, and
Fram: (Relatively) recent editors of this template: The title of the template is italicized, and I'm afraid that I do not have the requisite permission to fix it, nor the knowledge of the markup code to do so if I did. Would someone please be so kind as to fix this? —
DocWatson42 (
talk)
03:38, 12 March 2019 (UTC)
DocWatson42, this is caused by the examples on the documentation page. the only way to fix it without changing the examples is to add a {{DISPLAYTITLE:{{FULLPAGENAME}}}} at the bottom of the page, which gives a warning since the displaytitle is being changed multiple times. I suppressed the warning by wrapping it in a parserfunction.
Frietjes (
talk)
13:35, 12 March 2019 (UTC)
If there are two images (P180) for an artwork, this template smashes the two image file names together and it appears as a non-working redlink in the infobox. If you set one image to "preferred" rank above the other(s) then it works out OK. Example is
The Oxbow and the diff at Wikidata that made it work
[3]. --
Fuzheado |
Talk20:34, 25 January 2020 (UTC)
Please add "mapframe-marker" to the "#invoke:Check for unknown parameters" section of the template, so that editors do not receive "Warning: Page using Template:Infobox artwork with unknown parameter "mapframe-marker" (this message is shown only in preview)." when editing with this template.
Phuzion (
talk)
00:05, 8 May 2020 (UTC)
This was
previously discussed in 2014 and although most editors agreed, nothing's been done about it. It is inappropriate to autolink to the artist. It isn't hard to enter a name in this field and then link it. It is always inappropriate for a name to link to a disambiguation page. @
Frietjes: could you please nuke this function? Schwede6623:55, 18 June 2020 (UTC)
User:Schwede66, what is the plan for the ca. 1500 pages in Category:Pages using infobox artwork with autolinked artist field? should we have a bot make
this edit first, which would preserve the appearance, but make it obvious how to fix incorrect linking?
Frietjes (
talk)
00:00, 19 June 2020 (UTC)
That would be appropriate,
Frietjes. Yes. Here's a suggested edit summary:
As per [[Template talk:Infobox artwork|this discussion]], auto-linking for this field will be turned off shortly and this edit is in preparation. Please confirm that the correct article has been targeted and if not, please change the link or unlink the name if the target article does not exist.
User:Schwede66, okay, I made a script that checks to see if the text is linked anywhere else in the article and only links if that is the case. in the cases where it doesn't find the linked text, I am fixing them by hand (using the nowiki hack where necessary). we can clean up any that are using the nowiki hack in a second pass (should be less than 100).
Frietjes (
talk)
00:52, 19 June 2020 (UTC)
Thank you! I'm glad to see autolinking removed. I've always hated this feature, and often had to go back and add "nowiki" to prevent linking to the wrong person. ---
Another Believer(
Talk)14:29, 19 June 2020 (UTC)
So is the idea that people who happen to be watching the article affected should manually reinsert the wikilink that has been removed if it was a good link? --
Andreas Philopater (
talk)
21:43, 19 June 2020 (UTC)
Frietjes has done a bot run and most links should be fixed already. If there's something left to attend to, please do so. Schwede6621:58, 19 June 2020 (UTC)
Improved mapping for major artworks and installations
@
Reify-tech: Hi and thanks for the question, sorry for answering so late. Pushpin maps do seem TO BE possible already, please read the
template documentation for instructions on how you can do that. Though yup you can use the format used in the Museum of Science and Industry article. I and many others prefer that style (called maplink or mapframe maps), as you can zoom in and out to see much more detail, and creating the maps is simpler and easier, and they will update automatically. There are guidelines on how to create those maps on this template's documentation as well, but you can find out more at
this link. Feel free to ask any more questions, and I'll do my best to help.
ɱ(talk)03:37, 8 October 2020 (UTC)
Thank you for responding to my inquiry. I am not expert on Wikipedia mapping capabilities, but will try to follow your links as I have time. I appreciate the pointers to more info about what is possible, and will ask more questions if and as I have them.
Reify-tech (
talk)
15:46, 9 October 2020 (UTC)
Proposal to add "former location" or "former coordinates" for statues etc that have been moved/removed
As the header says, shall we add an attribute to the infobox for "former location" or "former coordinates"? This would be useful for the many confederate statues etc that have been moved/removed recently. In research on one of the Columbus statues at a recent AfD, I discovered that it had actually been moved a couple of times, so this is an attribute that would possibly apply to many public artworks. Consider something like Richard Serra's
Tilted Arc, perhaps one of the most famous public artworks ever removed.
I guess this is a proposal, so please indicate if you
Prefer former coordinates. Thanks for bringing this up, it's an important factor that Wikipedia likely wasn't built with before such widespread removal of notable monuments. Definitely important to keep the coordinates on the Wikipedia articles in this way.
ɱ(talk)01:28, 3 July 2020 (UTC)
Definitely support. My off-the-cuff solution is to add a single new parameter, "former_location" or something like that, as a yes/no. If yes, it simply changes "Location" to read "Former location". That way, there's no need to modify the mapframe support.
Pi.1415926535 (
talk)
03:53, 3 July 2020 (UTC)
Support This certainly isn’t a new problem. Of the articles that I have written about artworks, three of them are not in their original location, with two of them in their third location by now. The new parameters should thus allow for more than one former location. Schwede6615:02, 3 July 2020 (UTC)
Support Relocation of major artworks has been happening for a long time, including Egyptian
obelisks and large Renaissance sculptures which have famously been seized and taken as war booty, sometimes later returned and sometimes not. Whatever mechanism we use to indicate physical location should accommodate multiple successive relocations, optionally with the dates of occurrence (if known). It should also be possible to indicate "Location unknown", such as with the legendary
Amber Room, whose original installation in Saint Petersburg (Russia) was well-known, but which mysteriously disappeared during World War II, although a reconstructed reproduction was completed in 2003. There are many other examples of lost artworks, including ones stolen during the
Isabella Stewart Gardner Museum theft. I prefer "former location" as easier to understand, whereas "former coordinates" may sound very technical and somewhat intimidating to the average reader.
Reify-tech (
talk)
15:46, 9 October 2020 (UTC)
In case anybody thinks that lost artworks are rare occurrence, there is an extensive Wikipedia article on "
Lost artworks", and its bibliography doesn't yet mention two recent books I have which were published about the topic.
Reify-tech (
talk)
15:57, 9 October 2020 (UTC)
Is it appropriate to give an article about a photographic artwork the coordinates of where that photo was taken? (eg. Station Squabble, which appears to have the coordinates of Charing Cross tube station.) The documentation says the coordinate field is "only for the exact coordinates (when known) of the artwork's own location", but that could charitably be read either way. --
Lord Belbury (
talk)
15:41, 9 March 2021 (UTC)
Metric vs. imperial dimensions first
I'm writing a page for an artwork in the United States (
Draft:Archimedean Excogitation), so I'd like to list the imperial dimensions first. I'm not sure if there's any way to do this, though, and the code is more than a little scary, so I don't want to mess with it. Help? {{u|Sdkb}}talk09:38, 5 March 2021 (UTC)
Frietjes, I ran across this in
The Peace Child of Hiroshima. It has the imperial dimension first in the prose (as expected for U.S.), but metric first in infobox. It would seem that the template, if given imperial, would display imperial first. The way it works may be influenced by also supporting both both imperial and metric (not just one with auto conversion to the other). There would need to be a new parameter to say which one to output first, or it could just stay with metric first in that case since this is probably so uncommon it's not worth worrying about. But for the common case, can you see how difficult it is to output the given measurement system first.
MB02:32, 5 May 2021 (UTC)
@
MB and
Sdkb: unfortunately the code for dimensions is a complete nightmare. the last time this came up (
this thread) I suggested that you could just use |dimensions= with the same {{convert}} as the prose (easier to keep consistent with cut-and-paste from the prose).
Frietjes (
talk)
16:00, 5 May 2021 (UTC)
Frietjes, yeah, I figured that might be the case. It'd be good to Luaify the template, perhaps. Regarding triggering, there could be a parameter, and/or it could cue off templates like {{Use American English}}. {{u|Sdkb}}talk17:37, 5 May 2021 (UTC)
@
Sdkb: I would think the obvious thing to do would be to show imperial first if imperial are specified and metric first if metric are specified.
Frietjes (
talk)
17:50, 5 May 2021 (UTC)
@
Frietjes: An edge case where that might work poorly is where the canonical units are imperial, but the imperial units are "non-numeric" because they use fancy fractions via {{frac}}, so metric is specified manually. {{
Nihiltres |
talk |
edits}}05:02, 19 May 2021 (UTC)
@
Sdkb: As the author of the original mess (woo, ten-year-old edits that predate Lua!), I'll take another look at Lua-fying it … I've bounced off the task at least twice because
Module:Convert is awful to use externally. The logic of the original mess is actually fairly straightforward if decomposed … it's just massively redundant, which means it's all but unreadable. For the record, this pseudocode should largely summarize the logic:
for each unit-system in {metric, imperial} do
for each dimension in {height, width, length} do
if unit-system dimension provided, then display that dimension (handling special ftin case)
else if opposite unit-system is numeric, then display conversion (handling special ftin case)
else if opposite unit-system dimension present, then show an error placeholder
else display nothing (this dimension isn't present)
--
if this dimension and any next dimension is present, then add a spaced times symbol
display the unit for the unit-system
handle diameter similarly to single-dimension logic of HWL
if "dimensions" param is present, then display its content
if "dimensions_ref" param is present, then display its content
The redundancy comes from "unrolling" the loops (since wikitext lacks loops) and duplicating a lot of stuff across the if/elseif structure (because wikitext is largely
stateless, so "state" is held by branching and copying). {{
Nihiltres |
talk |
edits}}05:02, 19 May 2021 (UTC)