[Digikam-users] What is being/will be done about the tags management problem?

[Jean-François Rabasse]

On Tue, 19 Feb 2013, Elle Stone wrote:

> On 2/19/13, Brian Morrison <bdm at fenrir.org.uk> wrote:
>>
>> I don't mean to sink any ships here, but isn't this problem related to
>> which programs support which metadata?
>
> Well, there are all kinds of use cases and of course I am thinking
> about my own use case. But I'm pretty sure I'm not the only person
> using digiKam who doesn't let digiKam write to the image metadata
> but instead uses sidecar files.

You're not the only one :-)
(As discussed here recently, some naughty programs (The Gimp:-) tend
to corrupt metadata. Sidecar files is a safe alternative to embedded
data into images files.)

> So it seemed appropriate to bring up the issue of keeping sidecars 
> sychronized with the database.

+1
As Gilles said a couple of hours ago, default behaviour and options
should cover the majority of users needs. And having consistency
between write/read operations seems a fair default.

>> Isn't this exactly why sidecar files came about? A way of keeping data
>> associated with a file in such a way that programs that don't know
>> about it don't mess with it?
>
> I was under the impression that sidecar files serve two purposes:
> Provide a place to store metadata for file formats to which digiKam
> can't write, or for which writing is still experimental. And provide a
> place to store metadata if for whatever reason the user doesn't want
> to write to the actual image file.

Brian, sidecar files are not exactly a way for an application to
« hide » its data to other programs. The internal sidecar files
structure is an Adobe standard (XMP/RDF) and any program equiped
with a XMP parser is able to read any conformant sidecar file, or
embedded data in images files, whichever program created it.
(It's the same structure, exactly, and it's possible to insert a
sidecar file content into the image and vice versa. Metadata handling 
tools as exiftool or exiv2 do that.
As Elle said, sidecar files is only an alternative to writing into
the images files.

What is application specific is XMP schemas, aside from standard
schemas (XMP Base, Dublin Core, etc.)
And a metadata reader is just expected to read and use recognized
metadata schemas, and ignore specific ones.
That's what most software do. Interoperability is guaranteed for
standard schemas, it is optional regarding specific schemas.
(Feed an image tagged with Digikam to some Adobe software, it's
unliquely that the software with accept to deal with DK data.)

But, and that's probably why discussions about metadata often focus
around tags, structured tags and tags trees are special metadata 
properties. Why special ? Two reasons :

1. It doesn't exist in standard schemas, it has been ignored or 
forgotten. (I'd rather think forgotten).

2. It's a *very* useful feature. And the proof is that most software
environments offer this feature, use it, and implement it.
Because of point 1., each software does its personal implementation 
(Digikam tagslist, Adobe Lightroom hierarchical subject, Microsoft 
Photo, etc.)

The bad new is that this important data can't be easily shared.

The good new is that the XMP/RDF is a standard so, aside from such
or such application, it's always possible to perform applications
compatibility. So probably the simple strategy is to expect programs
to handle correctly their metadata, and rely on external tools when
conversions are needed.
E.g. reading digiKam:Tagslist "Location/Country/City" and converting
to lr:hierarchicalSubject "Location|Country|City" can be done even
without Digikam nor LightRoom.

The important thing is data content (and semantic), not formal
representation. I don't know which images manager I'll be using in
20 years, but I'm sure I want to keep my tags (and title, description
et al.) because it's part of the image memory.
For photo hobbyists, and we're are photo hobbyists, our images are
not just scanlines of coloured pixels.

Regards,
Jean-François