Template talk:Art Photo/2014

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

"artwork" parameter

What is the artwork parameter for? It has no explanation given on the doc page ... —SamB (talk) 19:54, 10 February 2014 (UTC)

Never mind, I figured it out (and documented it) myself ... —SamB (talk) 06:16, 15 February 2014 (UTC)

Issue with MediaViewer

Hello, I'm not sure if this problem is caused by the template or by the MediaViewer, but here it is:

I've recently discovered this template and decided to give it a try with File:Bust of Wilhelmine of Bayreuth.jpg (view in MediaViewer). I the normal view of the current implementation of MediaViewer, the license is displayed (correctly) as CC-BY-SA (photo license), but the author mentioned is the sculptor (artist). The sculptor did not release the bust under a creative commons license, it is just free to shoot per {{FOP-Germany}} and the CC-license is for the photo I took of it, so the author to be credited should be photographer (additionally mentioning the scuplptor is good, but not necessary). To make things even more confusing, if you click on view terms next to the license, {{FOP-Germany}} (artwork license) is being shown instead of the picture's license.

It seems like this template was engineered for faithful reproductions of 2D {{PD-Art}}-files, where the photo is not considered to be copyrightable on its own. {{Artwork}} recommends to use {{Art photo}} for cases like this, but it ios not yet listed at Commons:Machine-readable data, so I guess the problem lies somewhere in the machine readable part? (pinging User:Fabrice Florin (WMF)) --El Grafo (talk) 09:37, 15 September 2014 (UTC)

 Info The attribution part is still wrong in the recent design prototype. --El Grafo (talk) 09:55, 15 September 2014 (UTC)
The purpose of this template was mostly to provide proper description to photographs of the sculptures. All sculptures require specifying author and license for both the sculptor and the photographer, so this template provides clear delineation between the two. The template is not listed in the Commons:Machine-readable data because it relies on more basic 2 templates which are listed there. --Jarekt (talk) 16:34, 15 September 2014 (UTC)
Actually my last statement was not correct. {{Art photo}} relies on {{Artwork}} and {{Photograph}}. {{Artwork}} is documented in Commons:Machine-readable data but {{Photograph}} is not. I will try to correct it. My assumption is that the issue with MediaViewer is that {{Artwork}} and {{Photograph}} templates are very similar, so the image might have 2 sets of similar or almost identical tags.--Jarekt (talk) 16:42, 15 September 2014 (UTC)
I feel like the information is too complex and ambigious in the current template system for a computer to correctly interpret it easily (without massive special casing). I think the eventual switch to wikidata style information storage will help with more complex cases such as this. Bawolff (talk) 00:35, 16 September 2014 (UTC)
@Bawolff and Jarekt: I agree that this is complex stuff and that it might be easier to handle once whe have switched to Structured Data. But that's still far away and we can't wait for that. This is a copyright violation – exactly the kind of stuff the community got so very upset about when MediaViewer was launched. I'm not saying this is MV's fault though: If the template delivers ambiguous information we must change the template. For photographs of sculptures that are either very old or fall under the Freedom of Panorama, there are only two things that must be displayed in MV: Author and license of the photograph. Anything else can remain on the file description page. If this template is also used for photographs of other objects with different terms, we might have to implement some kind of manual switch or split it into different templates. (By "we" of course I mean "someone who knows how to do this" *cough*). --El Grafo (talk) 13:56, 16 September 2014 (UTC)
I agree that most sculptures out there will be in public domain or fall under freedom of panorama, but it is quite possible that some will have CC licenses (and OTRS templates) from the sculptors. Like for example File:Szczesciarze (Luckers) Wroclaw dwarf 03.JPG. --Jarekt (talk) 14:30, 16 September 2014 (UTC)
@Jarekt: That's what I meant with that last sentence. Either somewhere in the template → metadata → MediaViewer queue some kind of "inteligence" must be included that decides which license(s) and author(s) need to be displayed, or different templates for different cases mut be created. Unfortunately, I'm not good with templates, so I won't be of much help here :-( --El Grafo (talk) 07:54, 2 October 2014 (UTC)
Pinging User:Guillaume (WMF) who is the point person on the WMF side for template-level improvements as part of the File metadata cleanup drive.--Erik Moeller (WMF) (talk) 06:51, 17 September 2014 (UTC)
Thanks, Erik. Nothing has changed in this regard after the recent update of MediaViewer. This is essentially a copyright violation (not mentioning me as the author of the photograph). Pinging User:Guillaume (WMF) again … --El Grafo (talk) 07:54, 2 October 2014 (UTC)
El Grafo: I'm sorry for the delay. I can't look into this this week but I promise I'll see if I can fix this next week. guillom (talk) 16:20, 2 October 2014 (UTC)
User:Guillaume (WMF), I do not know much about machine readable data and how it is being used by tools, but I suspect that the first step of the solution will be differentiate the tags added by {{Artwork}} and {{Photograph}} templates. See Commons:Machine-readable data. {{Photograph}} was an offshoot of {{Artwork}} and I did not change machine readable tags at the time of the creation. Latter I was reluctant to change it as I do not know what tools might rely on them (if any). Once {{Artwork}} and {{Photograph}} templates use different tags one can use some logic to recognize {{Art Photo}} and give proper credit to both the artist/sculptor and the photographer. Please feel free ping me if you need some help with those templates, if nothing else I can provide historical context. --Jarekt (talk) 16:45, 2 October 2014 (UTC)
So, I think I've mostly wrapped my head around what's happening here. The problem is indeed that {{Art Photo}} wraps {{Artwork}} and {{Photograph}} into the same page, and that both of them emit fileinfotpl_aut metadata. MediaViewer can't just append them because they're qualifying different things (we can't say the author is "Gabriele Plössner and El Grafo", because then the license doesn't match that author).
One solution would be (as discussed above) to disambiguate between the artwork and the photograph. Most of the machine-readable markers in {{Artwork}} are prefixed with fileinfotpl_art_, but the main ones are not, probably because used independently, it makes sense to use them.
So, we could keep the current markers in {{Photograph}}, and use the fileinfotpl_art_ prefix for all markers in {{Artwork}}: this means using fileinfotpl_art_aut instead of fileinfotpl_aut, etc.
However, this also means changing CommonsMetadata's behavior to handle these new tags, for example by doing the following:
  • If we have fileinfotpl_art_aut or fileinfotpl_aut and only that one, we display the one we have.
  • If we have both fileinfotpl_art_aut and fileinfotpl_aut, we display both of them.
The other new fields would probably work similarly (if fileinfotpl_X and fileinfotpl_art_X are present, display both, otherwise display the one we have) but I'm a bit worried about the interface becoming too crowded.
User:Tgr (WMF), do you think this would make sense from a CommonsMetadata perspective? How much does it complicate things? My impression is that it adds complexity, but it's complexity we'll need to handle at some point anyway. Is there an easier way to solve this problem? Guillaume (WMF) (talk) 10:06, 8 October 2014 (UTC)
Thanks for your thoughts, Guillaume. Yes, this is complex, but this seems to be just the tip of the iceberg. As Kaldari pointed out at Commons talk:Structured data#Anything missing?, when it comes to media other than still images, we'll have to consider things like composers vs. performers vs. recordings for music or audio vs. video for movies, etc. Afaik, we don't have templates for that yet to worry about now, but I guess it would be wise to keep that in mind when tackling the current issuses … --El Grafo (talk) 13:20, 8 October 2014 (UTC)

@Guillaume (WMF), El Grafo, and Jarekt: I would say

  • if we just want Media Viewer to ignore {{Artwork}}, rename its fields to *_art_*. (But I imagine this would cause trouble for scans of artworks?)
  • if we want to use artwork fields as a fallback, the template should qualify the different information templates with some top-level class; that the fields which have the same role have the same id makes sense. (Well, two fields having the same id never makes sense, and COM:MRD should have used classes instead of ids, but whatever.) Plus, you have to define the priority order of templates (object/artwork -> photograph -> book?) Also, should this be a per-field fallback or a template-level fallback (ie. only ever touch Artwork if there is no Information)?
  • if we want to merge the author field (ie. return "Foo and Bar" when there is a Photographer template with author:Foo and an Artwork template with author:Bar), I'm not sure the templates need to be changed right now, unless we want to have a fixed order (e.g. photographer always comes first). For all other fields, merging doesn't really make sense IMO.
  • combining information from different templates in a structured way (i.e. returning something like {photograph: {author: Foo, description: XXX}, artwork: {author: Bar, description: YYY}} from the API) is just not going to happen, sorry. The current API format used by CommonsMetadata is extremely hostile towards multivalued fields; the structured data project will offer much better ways to handle this, it just doesn't make sense to work on CommonsMetadata hacks instead.

--Tgr (WMF) (talk) 13:30, 8 October 2014 (UTC)

For reference, Bugzilla: 57465/Bugzilla: 57310 is about selecting one value per field in a more intelligent way; Bugzilla: 57259 is about returning multiple values. --Tgr (WMF) (talk) 13:35, 8 October 2014 (UTC)

We can not just ignore the {{Artwork}} template fields, since artworks might be copyrighted too, as in this case where sculptor licensed his works as CC and numerous photographers (using different CC license) took pictures of them. So I would be leaning towards merging of the fields. However we would have to also deal with the license. Lets just look at some example cases:
  1. Artwork license: PD; Photograph license: CC -> API could just return Photograph's CC license and the photographer as author
  2. Artwork license: CC; Photograph license: PD -> API could just return artwork's CC license and the artist as author
  3. Artwork license: PD; Photograph license: PD -> API could just return either artwork's or photograph's info
  4. Artwork license: CC; Photograph license: CC -> we need to merge authors and licenses. If licenses are not the same I would return info that the status can not be automatically determined.
We could also introduce some new template with additional hidden fields where machine friendly versions of license, author and attribution, etc. are kept. Those fields would take precedence if found, and we could manually fix some most troublesome files not handled by the current software. A little like en:template:Persondata. So far the main purpose of the Commons infobox templates was to display metadata information clearly to the users. Uploaders are always encouraged to preserve as much of the metadata as possible and when dealing with works of multiple authors to provide license templates for all authors in country of the origin and in the US. When we run into complex metadata we packed it into various fields of the infoboxes with the the main objective being human readability not machine readability. When we run into complex licenses we created Multi-license copyright tags, which are also likely to be impossible to untangle if we start mixing different non-PD licenses. So the API should not attempt to figure out author/license/attribution for 100% of files and concentrate on 90% of the easy cases with single license and author and a hidden template with machine friendly inputs can be provided for the rest. --Jarekt (talk) 15:58, 8 October 2014 (UTC)
--Jarekt (talk) 15:58, 8 October 2014 (UTC)

@Jarekt: I don't agree with that assessment. Ignoring the Artwork template is not ideal but I don't see any legal problems.

  • 1: PD artwork, CC photo: we show data from the photo template so license requirements are met.
  • 2a: CC artwork, PD photo which is derived from the artwork in such a way that it does not require permission from the artwork author (eg. freedom of panorama): since the photo is PD, we are free to do whatever we want with it (i.e. neither the artist nor the photographer has to be credited).
  • 2b: CC artwork, "PD" photo where "PD" means that the contribution of the photographer is non-protected (such as a photo of a painting): PD is just used wrongly in this case, the photo must be CC due to share-alike.
  • 3: PD artwork, PD photo: again, we are free to do whatever we want.
  • 4: CC artwork, CC photo: displaying the author of the photo meets the requirements of the license, IMO. CC requires you to credit the photographer (since you are making copies of the work), and it requires the photographer to credit the artist (since he is making an adaptation of the artist's work). It does not require you to keep credits to previous authors GFDL-style when you credit the last author though (in fact, that was one of the main reasons for switching from GFDL to CC).

So displaying only the Photograph template when it exists, and otherwise displaying the Artwork template should be always legal, as far as I can see. It can be suboptimal, even slightly rude to the artist in some cases, but it's not a copyright violation, and so not an emergency that would justify us hacking together temporary solutions instead of working on the robust, long-term one. --Tgr (WMF) (talk) 06:15, 9 October 2014 (UTC)

Tgr (WMF), About the case #4: I just reread CC-BY-SA-3.0 and the section 4c has this section "in the case of an Adaptation, a credit identifying the use of the Work in the Adaptation (e.g., "French translation of the Work by Original Author," or "Screenplay based on original Work by Original Author"). The credit required by this Section 4(c) may be implemented in any reasonable manner; provided, however, that in the case of a Adaptation or Collection, at a minimum such credit will appear, if a credit for all contributing authors of the Adaptation or Collection appears, then as part of these credits and in a manner at least as prominent as the credits for the other contributing authors." It sound to me that in cases like this file. You need to credit all contributing authors (sculptor and the photographer) in the same manner. Also if the sculptor sends his permission to OTRS with CC-BY license which requires attribution, I assume he imagines that we will be using his name in the attribution, not just the photographers name. --Jarekt (talk) 13:16, 9 October 2014 (UTC)
@Tgr (WMF): What about still copyrighted artwork but photographed/published under freedom of panorama (FOP), mainly sculptures in public places? Example: File:St Mariä Heimsuchung, Rhöndorf - Madonnenstatue - Peter Terkatz-0962.jpg. AFAIK we have to credit the sculptor and and the photographer. — Preceding unsigned comment added by Raymond (talk • contribs) 12:16, 9 October 2014 (UTC)
@Raymond: Freedom of panorama means exactly that you don't have to do anything about the original copyright, since there is a law allowing you to make photographs of the sculpture, so you don't need a license or permission from the author; as long as the FOP law itself does not require you to attribute the sculptor (which none that I know of does), you don't have to.
I agree that we should credit the sculptor (even if it's not legally required, it's just the right thing to do) but we should work on finding a good way of doing that, even if it takes a while, instead of trying to do it right now in hacky ways (which would not be particularly hard, but I am worried that it would end in a long hunt for edge cases). --Tgr (WMF) (talk) 07:19, 9 October 2014 (UTC)
Hi Tgr (WMF), while that might be the case in some jurisdictions, this is incorrect at least in Germany. For Germany see § 63 (1) UrhG (here in English for convenience: http://www.gesetze-im-internet.de/englisch_urhg/englisch_urhg.html#p0411). You don't need a license from the author, correct, but you have to attribute the author (at least if their name is directly provided on/at the reproduced embodiment of the work). It is unclear in Austria and Switzerland where (unlike in German law) such an obligation is not expressly provided in the law, but some commentators still held it's implied (see e.g., for Switzerland: Macciacchini/Oertli, Handkommentar Urheberrechtsgesetz, 2nd ed. (2012), Art. 27 [14], and for Austria: OGH [Federal Supreme Court], decision of June 12 1994, 4Ob80/94 -- Glasfenster ["[...] es kommt daher darauf an, ob der Beklagte den Künstler nach den im redlichen Verkehr geltenden Gewohnheiten und Gebräuchen nennen hätte müssen. Daran kann bei den hier gegebenen Umständen nicht gezweifelt werden"] and Walter, Österreichisches Urheberrecht, 2008 [1332]). — Pajz (talk) 18:09, 9 October 2014 (UTC)
  • (Edit conflict)I think Tgr is correct on FOP point; there is no legal requirement to credit the author of original art work if FOP applicable. We are not crediting the architects in most photos of architectures.
  • @Tgr (WMF): Your point 2b is a bit vague. In fact, it should be "Copyrighted art work with a free license (CC BY, CC BY-SA, GFDL, FAL, etc.), copyrighted photo with a free license compatible to the license of artwork." If the artwork has a copyleft license (CC BY-SA, GFDL, FAL, etc.), the photograph also must have the same license. Otherwise (CC BY, Attribution, etc.), the photograph can have a compatible license; may have a more restrictive license (but PD not possible; you are right as you said above due to the attribution requirement). Anyway both parties need to be attributed. Jee 07:27, 9 October 2014 (UTC)
  • I'm not sure about point 4; the legal code is not talking much about it. But my understanding from this and this is that "every modifications from the original must be mentioned" in 4.0 licenses. I don't know how it is possible/meaningful without mentioning original work and its author. Jee 08:07, 9 October 2014 (UTC)

@Jkadavoor: you are probably right. After discussing with some people, the best option seems to be to use the values from the Photograph license, but show an additional note saying "and X more authors" which links to the file page. All other solutions run into one of these problems:

  • there is an obvious way of merging author fields of different templates, but no such method for source and license fields
  • we don't want to show multiple authors under one license if that license is not actually accurate for some of them
  • there is limited space so complex situations like "by Author 1 under CC-BY-SA, based on Author 2 By CC-BY" cannot be expressed

--Tgr (WMF) (talk) 16:28, 9 October 2014 (UTC)

Tracked in Bugzilla: 72081, Bugzilla: 72084 and Bugzilla: 72082. I'll try to summarize the solution, please tell me if you see problems with it:

  • the following templates can introduce additional authors: {{Information}}, {{Artwork}}, {{Photograph}}. (I've omitted {{Book}} as I can't really think of a case when the book author should be included in the attribution.)
  • right now there isn't a machine-readable way to tell apart these templates. They should all get a top-level class that identifies them. (Book to, so it can be safely ignored. Right now its field ids have just enough overlap with other templates to be useless but potentially harmful.)
  • when there are multiple such templates present, Media Viewer should use the most relevant (the one that is closest to the actual image). That would be, from highest to lowest preference, Photograph -> Information -> Artwork (?)
  • when there are multiple templates providing author information, Media Viewer should append to the author name (which is taken from the most relevant template) a link to the file page, with the text "and N other authors".
  • to support this, CommonsMetadata should have a new AuthorCount field.

This all is of course a horrible hack, but with the work on proper support for structured data already started, I'm pretty amenable to horrible but quick hacks for the meanwhile. --Tgr (WMF) (talk) 17:55, 15 October 2014 (UTC)

Retrieved from "https://commons.wikimedia.org/w/index.php?title=Template_talk:Art_Photo/2014&oldid=641367901"