On 9/29/15, Jane Park &lt;janepark(a)creativecommons.org&gt; wrote: Hi Jane. We support both XMP and Exif (along with some other things like PNG iTXT chunks, the older non-xmp version of iptc, etc). To be specific, we only accept properties we are already aware of. Since XMP is an open standard that anyone can add to, we won't recognize any properties not on our whitelist. In the interface, we sometimes present all file metadata under the name "Exif" regardless of where it comes from, so depending on who you ask people might say we only support exif, which is untrue. Its just how we communicate this data to the user. I was actually the one who added the initial support for XMP in MediaWiki as part of a google summer of code project in 2010, so I'm intimately familar with that part of the code. So on the subject of ingestion for license data: Sometimes there are properties across different standards with the same meaning. Sometimes we try to map them together, often letting one type of metadata overwrite another. We try to follow http://www.metadataworkinggroup.org/pdf/mwg_guidance.pdf We generally only use the ingested metadata to display in a table on the image description page for extra infomration. We rely on the user to provide license info, and generally don't take that (or much else) from the file's metadata. The primary information about an image displayed by MediaWiki is directly from the user, not the file's metadata. One exception to that, is uploadWizard. It suggests some values based on image exif for date, author, gps location. It does not prefil license at this time. I don't know much about how it works or even if it uses MediaWiki's file metadata extraction routines, or its own thing. We recognize the following properties related to licensing/authorship: Exif: *Copyright *Artist PNG text chunks: *Copyright *Author *Artist Legacy IPTC: * Copyright (2:116) * Byline (2:80) * Credit (2:110) [Although, that doesn't mean what you normally think credit does] * Contact (2:118) XMP: *XMP (using http://creativecommons.org/ns# namespace): ** license ** morePermissions ** attributionURL ** attributionName *XMP (using http://ns.adobe.com/xap/1.0/rights/ namespace ): ** 'Certificate' ** 'Marked' ** 'Owner' **'UsageTerms' **WebStatement * XMP (http://purl.org/dc/elements/1.1/) **rights **creator **contributor *Exif encoded as XMP (aka http://ns.adobe.com/tiff/1.0/ namespace) **Artist **Copyright * XMP (new iptc http://iptc.org/std/Iptc4xmpCore/1.0/xmlns/ ) **CreatorContactInfo Note: IPTC-as-XMP has some props related to copyright/authorship we don't support such as Licensor Note: We do not extract CC-tags from SVGs Its also possible I missed something here. As for adding metadata to images: *We serve the original image exactly as is, if the user asks for the image in the original size. This would include all original metadata, but we don't add any *If the user asks for a small image, we strip all metadata except colour profile. We add a comment (JPEG: a JPEG COM segment. PNG: some sort of text chunk) saying "File source: <url to file>" I personally think we should be adding copyright metadata to thumbnails (but I do not consider it a high priority). Particularly for larger thumbs, where the overhead would be minimal. XMP has a downside of not being that compact. XML is not very compact to begin with. Additonally the official spec suggests people add a lot of whitespace to allow in-place editing, and do not use compression, even if the format supports it, so that people can just scan the file. Most libraries that write it seem to do that. Which is unfortunate from our prespective where we are trying to minimize thumb size. If we were to start adding metadata to thumbs, I think we would start with exif Artist and possibly an exif copyright field that has info on the license. I would be supportable of a system where if the thumbnail is super small (say < 5 kb), we put nothing, if it is medium size (5-300kb) we put those two exif fields I mention. If its > 300kb, we put author, copyright, gps, creative commons xmp tags in it. But other's might feel that reducing thumb bandwidth is more important then the metadata, so its something that would probably have to be discussed (Not to mention, so far nobody has actually volunteered to code it...) That said, I do not see what creative commons stands to gain from adding more metadata standards. The existing XMP fields seem good for people who want fine grained info about the copyright of their image. It seems like new exif fields would take a long time to propagate to implementations As for what standards are widely used: Ancedotally, there's probably a lot more people using Exif then anything else, but that's due to automatic support for digitial cameras. It seems very few people explicitly mark their images with metadata. I hope that helps -- -Brian

If you want Commons' community opinion, you'd better see commons-l. (CC'd) -- revi https://revi.me -- Sent from Android -- 2015. 9. 30. 오전 6:19에 "Jane Park" &lt;janepark(a)creativecommons.xn--org&gt;-4f21ay07k 작성:

The main issue with this effort, on Wikimedia and elsewhere, will be that there is no guarantee we have any metadata about file attribution and copyright status. See also https://meta.wikimedia.org/wiki/File_metadata_cleanup_drive Even if you made a <link rel="license">-like thing and collapsed all the PD tags under PDM's URL, it would be quite a mess. And Flickr is not so consistent in how it marks public domain. And Google is dropping support for license statements altogether. Etc. Nemo