Version: (using KDE KDE 3.5.5) Installed from: Compiled From Sources It would be nice to add a comment to a tag. Explanation: For example for a town it would be nice to provide some remarks (notes, historical information, ...) or a weblink for later reference. Or for tags classifying animals (like butterflies etc.), one could add information helping in the classification, comments on similar ones, notes on the typical behaviour or where the could be found (i.e. all those things one looks up in a book and normally forgets quickly ;-).
Comments for Collections also would be useful.
Aren't collections supposed to go away?
Never have seen official confirmation. Generally I like collections but they terribly clash with current albums management.
OK. #1 is INVALID ;)
Marcel, This file is relevant of new DB schema which do not include a comment for tag... I propose to add it to DB schema, if you is agree... Gilles Caulier
There were quite a lot of ideas for restructuring tags, comments, dates, more advanced stuff. For me, when I worked at the DB last Summer, I left this area of DB changes for later versions...
*** Bug 228883 has been marked as a duplicate of this bug. ***
Marcel, DB schema for 2.0.0 include Tags comment field ? Gilles Caulier
*** Bug 192447 has been marked as a duplicate of this bug. ***
*** Bug 329352 has been marked as a duplicate of this bug. ***
*** Bug 190935 has been marked as a duplicate of this bug. ***
Up! A tag description/comment/note field could be very useful… specially for searching in a Digital Asset Management way. This tag's description/comment/note field can be use as a way to "control" the vocabulary in order to dictate your own semantic manifestations of metadata in the indexing of items. In the first time it should be a good "quick and dirty" way to add informations helping in the use of tags themselves, translations, lists of synonyms etc.
I'm still learning of all the possibilities in metadata, but here are my thoughts: There are other metadata fields/properties available for additional details. Controlled vocabularies, URI links, hierarchies are specialized use cases with their own dedicated properties available. It might be a mistake for digikam to keep this data hidden in it's own DB nested under "tags". Tags are just a simple list of individual keywords. If more complexity is needed, there are other fields/properties available. As always, I like to refer everyone to the MWG Guidelines ;-) http://www.metadataworkinggroup.org/pdf/mwg_guidance.pdf
Dear Alan, Very interesting. From this MWG Guidelines, I understand that specs/standards/best practices (provided by Adobe, Apple, Canon, Microsoft, Nokia and Sony) said: 1. Keywords (also called "tags") are available in "IPTC Keywords" and "XMP (dc:subject[*])" metadata (The MWG Guidelines, p. 35); 2. IPTC Keywords is mapped to XMP (dc:subject); 3. XMP provides the ability to add qualifiers for each keyword to define a semantic. For future extensibility, these attributes SHOULD be preserved on any keyword manipulation; 4. recommended best practice is to use a controlled vocabulary for keywords (XMP Specification part 1 - Data model, serialization, and core properties, Table 4 - Dublin Core properties, p. 26). So… I really think that a description/comment/note field associated with each tag is a good compromise…
I think one could be looking beyond simple keywords/tags. For example, MWG Guidelines include detailed Location fields, both GPS and Textual properties. The guidelines provide for hierarchical keywords. There are guidelines for image collections, including reference URI's. And for Description, which provides a more verbose description of the content of an image. digikam already offers these properties and functions. They are independent from and complimentary to the simple list of keywords.
Alan, You're right: location, textual properties, source references and all verbose description fields for explicitly *describe the content of an image* already exist. Here, unless I am mistaken, we discuss the opportunity to add (or not) *comment field for the tag object* in the digiKam interface/DB schema: ie *qualifiers for each keyword* in order, e.g. to comment tags, control tags vocabulary, define a semantic to tags, give translation to tags, etc., for tags themselves (these attribute refer only to tag and should be preserved on any tag manipulation, as provided by industry recommendations…) Is there something I missed or misunderstood?
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.
> confirm that the issue still persists Yes, still no description field for tags in digiKam 7.8.0 :-(