v0.48 IPTC/XMP tagging is confuse

[mahikeulbody]

NB. It is not a new problem specific to v0.48.

First, let summarize the situation as I understand it
The standard is drived by the IPTC organisation. At the begining it was represented by the IIM model. Later Adobe created XMP which is more a new implementation (based on XML) of the IIM standard that really a new standard. IPTC organisation decided to adopt XMP and defined a new standard described by the IPTC Core schema and the IPTC Extension schema. This new standard is not only a new implementation in XML of the IIM model, it also defines new tags and deprecates others. So IPTC Core and IPTC extension schemas describe all IPTC tags of the new standard and they describe also their suggered XMP implementation (name space:tag name).

The situation of XnViewMP
IPTC/XMP Editor shows IIM tags, the old standard of IPTC (so the Editor should be called IIM/XMP Editor since it is now a non-sense to opposite IPTC and XMP). In fact, it would be better it shows the IPTC Core and IPTC Extension tags (or at least a subset of them) with their name in the new standard. By default it should write them using the new implementation (XMP) but keeping of course the option to write them using IIM standard (some IIM fields are deprecated but the standard defines a mapping).

Since XnViewMP doesn't use the exact name of the current IPTC standard, it is difficile to know the meaning of each field shown by the IPTC/XMP Editor. For example, City idoesn't mean the city where the photo is taken but the City of the Author/Creator since it is written into photoshop:City tag (this name space is dedicated to the author, caption writer, etc...). IPTC defines others fields to describe the location where the photo is taken (LocationCreated or LocationShown, etc...). Speaking about this example, I think it would be nice to have these fields since probably they make more sense of many of VnViewMP users that City of the Author.

Sorry for this long post and "félicitations" for the nice job.

[mahikeulbody]

After to read http://www.metadataworkinggroup.org/pdf ... idance.pdf I think a way to clarify that could be to reorganize XnViewMP IPTC/XMP Editor with the following tabs :

Keywords
Description
Date/time
Rating
Copyright
Creator
Location

Inside each tab, the Editor could use a translated expression to describe the tags followed by the exact tag name into XMP standard (name space:tag name). For example : Mots clé (dc:subject).

Mode option could be use the string "IPTC-IIM" instead of "IPTC".

Ok, it is more a request that a bug but I think it is a way to correct the mess with location items.

[xnview]

Keywords
Description
Date/time
Rating
Copyright
Creator
Location

How do you see the editor?? Which correct terms?

[KlausT]

mahikeulbody, your summary is correct on the whole, but your conclusions with respect to XnViewMP need some clarifications:

• XnViewMP claims to support IPTC-Core but not IPTC-Extension (see
  http://www.iptc.org/cms/site/photometad ... =CH0101#17).
  This means that the new properties introduced in IPTC-Extension (like "location shown" and "location created") are not relevant for XnViewMP as long as XnViewMP does not claim to support IPTC-Extension.
• The terms "legacy" and "deprecated" must be clearly distinguished: the properties marked "legacy" are still part of the IPTC-Core specification, whereas the properties marked "deprecated" do not. The deprecated IIM properties (Urgency, Category, and Supplemental Categories) can still be used and mapped to the corresponding XMP properties, but outside the IPTC-Core spec.
• Your argumentation concerning "City" is not correct: this metadata property is marked "legacy" in IPTC-Core because there is a better solution in IPTC-Extension, but this neither means that "City" is no longer supported in IPTC-Core nor that it changes semantics, as your statement implies (this would introduce a severe compatibility problem).
• The City-example refers to the metadata structure "Contact Information Details" in IPTC-Core. This structure contains a component "City {contact info detail}" and must be referred to in combination with the structure name in order to be clear. The same holds for the metadata structure "Location Details" in IPTC-Extension with the component "City {location detail}".
• XnViewMP's metadata editor is from history an IPTC-IIM editor. I agree with you that the Mode setting in the Options-tab should be more precise with respect to the saved and mapped metadata. For example, the IIM-Contact field is a bag of simple text-string(s) and cannot be mapped directly to the XMP-structure, so XnViewMP ignores IIM-Contact (and some other fields as well) when mapping IPTC-IIM to XMP (mode: "IPTC, update or create XMP"). The missing mappings are not clear from the mode setting and the tab contents.
  Therefore, I suggest to offer two basic modes:
  1. IPTC-IIM (this is current "IPTC only");
  2. IPTC-Core (this is current "XMP only" with the supported metadata);
     this IPTC-Core mode should have two additonal options:
     - update or create IPTC metadata (if selected, XMP metadata dominate IPTC-Core in case of inconsistency);
     - update or create XMP metadata (if selected, IPTC-Core metadata dominate XMP in case of inconsistency).
     if none of these two additional options is selected, only the XMP metadata will be handled (current "XMP only" mode).
  With this approach, it is always clear to the user from the tab contents, which metadata fields are supported by the respective mode.
  
  Unfortunately, there is a bug in the metadata editor: the editor first tries to read the IPTC metadata, even if "XMP only" is selected and the XMP metadata differ from IPTC in contents. It should be clear to the metadata editor, which metadata section is preferred.

Thanks for your patience ... spec discussions are always lengthy.

[Vapavite123]

Hello,

French :

How do you see the editor?? Which correct terms?

How do you see the editor??

C'est probablement un des plus complet et des plus faciles d'utilisation en dehors des programmes de type professionnel ou prévu qu'à cet effet et surtout un des plus compatible !

Which correct terms?

Les appellations sont libres et de toutes façons aucuns termes simples ne permettraient de définir un ensemble de champs. Pour exemple, Description n'étant pas plus clair que Légende car aucuns des deux ne dit expressément que le nom de l'auteur (de l'image et/ou de la description) figure parmi les champs

Ceci n'exclut pas :

Qu'Il pourrait y avoir incompatibilité ou (bug) dans la mesure ou deux champs: Contact et Content location name sont définis dans XNV comme répétable alors que dans les nouvelles normes ils ne le sont pas (ou plus). Ceci étant à vérifier et peut être à corriger !

Il y à aussi que certains champs apparaissent comme pouvant être répétables dans le Panneau Info tel que par exemple dans l'onglet XMP : Creator[1]. Le [1] étant superflu me semble t-il et pouvant être mal interpréter lors de la lecture par l'utilisateur et/ou le programme !

C'est correct de dire que "Contact" ne se trouve pas à la bonne place dans l'onglet Info/XMP par rapport aux onglets de la fenêtre d'Edition. Je dirais même que plus globalement et si cela était possible, ce serait bien s'il y avait une plus grande corrélation entre les appellations des onglets et les termes qui définissent les groupes dans les onglets IPTC&XMP du Panneau Info

Bien à vous