The information template field "source" is currently matched to "Credit". I think this is wrong or at least misleading.
The content is often a simple "{{own}}" or a URL.
I suggest to rename the key to "FileSource".
Version: unspecified
Severity: normal
URL: https://commons.wikimedia.org/w/api.php?action=query&titles=File:Krokydolith%20-%20Mineralogisches%20Museum%20Bonn%20%287385%29.jpg&prop=imageinfo&iiprop=extmetadata&format=jsonfm
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Declined | None | T71914 data labels in imageinfo API don't make sense | |||
| Duplicate | None | T59189 Rename key "Credit" to "FileSource" |
Keys for the fields parsed from the description try to match the keys from the file metadata, in this case the Credit field from XMP [1], which "Identifies the provider of the objectdata, not necessarily the owner/creator". In the end, I don't think the naming matters a lot - eventually all such metadata should end up in Wikidata, and the community can decide what property name is best. Until then, only tools will see the field names anyway (we should have better documentation for them, though).
[1] http://www.iptc.org/std/IIM/4.1/specification/IPTC-IIM-Schema4XMP-1.0-spec_1.pdf#page=17
amruthasangeeth wrote:
I would like to work on this bug.Can someone please assign this to me.
Change 107368 had a related patch set uploaded by Amruthasangeeth:
Renamed 'Credit' to 'FileSource'
While I appreciate the idea of adhering to standards, it doesn't make any sense for us to try to follow XMP (which is designed for very different use cases and not adequate for our needs). It would be much less confusing for everyone if we just followed our own template parameter names.
The reason for using the XMP naming schema is that the data extracted from the templates is merged with the XMP data from the file. That way, if the file page does not have an {{Information}} template but the file has a Credit EXIF field, it can be displayed as the author.
In hindsight, that was not a good way of doing things - the XMP vocabulary is not so great and translating it to the names used by [[commons:COM:MRD]] would have been better.
The extmetadata API might soon be superseded by the structured data API though (I am hoping to put up an RFC about that this week); I am not sure it is worth breaking BC on an API that is going to be deprecated any minute.
(In reply to Tisza Gergő from comment #6)
That way, if the file page does not have an {{Information}} template but the
file has a Credit EXIF field, it can be displayed as the author.
(Artist, not Credit. Confusing indeed.)
I am not sure it is worth breaking BC on an API that is going to be deprecated any minute.
I would normally be inclined to agree with you, but I would be surprised if the Wikidata API was available in less than a year.
We intend to create a high-level API on top of the low-level data storage mechanism (which might be templates or Wikibase properties, depending on whether the file has been migrated yet); this API won't require Wikibase to be even installed. In it's first iteration, it will be just the current template parsing logic plus a sane output format (non-flat, better field names, none of the value/source/hidden stuff). I think it should be up in a month or two.
How is the progress on the high-level API going? If it doesn't look like it will be implemented soon, can we go ahead and fix the low-level API? The API hasn't been around for that long, so I don't think breaking backwards compat would be a huge deal. As far as I know, the only significant consumers of it are the desktop MediaViewer and the mobile MediaViewer.