XMP, Krita, KFileMetaInfo and Strigi

[Cyrille Berger]

Hi

Note, I am not subscribed to kde-core-devel, so don't forget to CC me if you 
want me to see the answer.

First I think there is one little glitch, KisMetaData and Strigi don't share 
the same goal, one is designed around XMP for supporting and editing XMP like 
metadata, while Strigi is designed to index data and metadata.

While it's possible to merge both in a single unified library I am not sure it 
is worth the added complexity. That said, we should indeed make sure to share 
as much as possible code, but that's more or less allready the case.

> I read your post on metadata in Krita and would like to point you to
> the KDE4 way of handling metadata to make sure all applications
> benefit from your efforts.
>
> - getting metadata
>   For retrieving metadata, one should write a strigi analyzer. Doing
> so makes the data available for indexing in Strigi and Nepomuk and
> KFileMetaInfo. There's a tuturial on techbase and plenty of example in
> the strigi codebase.

KFileMetaInfo reads file, Krita has allready the file I definitively don't 
want the file to be read twice, so it would need to a method or constructor 
to read from a buffer limited to the metedata chunk of the file.

> - writing metadata
>   For this there are two possibilities which should be merged at some
> point. You can write data into a file by implementing a KFileWritePlugin.
> This allows you to write into the file via the KFileMetaInfo
> interface. You can also annotate data via the Nepomuk interface.
Same problem as above.

But the biggest problems and limitations comes from KFileMetaInfoItem
- QVariant is not good enought:
 - it lacks some important types like rationals
 - no distincion between ordered list / unordered list (I know it might seems 
unimportant, just treat an unordered list as ordered, but the fact is an 
application should never never sort an ordered list)
 - there are two associatives array in XMP (and only QMap in QVariant), 
Structure and Alternative Array, there is in fact a huge difference between 
the two, Structure has a limited set of possible keys, while Alternative 
Array is not limited
 - all the above can be more or less hacked in QVariant using UserType, even 
if a real API to manipulate them is better. But there is an other problem 
which need an extended QVariant . In XMP value can be associated to 
a "Property qualifier" (unless doing something really horrible like storing 
all value in QList<QVariant> with first item the value and the second item 
the property qualifier...). The typical use case of "property qualifier" is 
for a list of author of a document, imagine for instance a book with 
illustrations in it, you would have to authors "Paul" (the text writter) 
and "Jane" (the drawer), "property qualifier" allow to indicates that Paul 
was the text writer and Jane "the drawer".

The whole framework also lack validation Schema but that's a slight problem 
that could be added at Krita level, even if I do think it's better to have 
Value (QVariant), Entry (KFileMetaInfoItem) and Schema interacting close 
togther, for instance to have KFileMetaInfoItem::setValue call the Schema to 
check if it can accept this value and then for instance try to convert it if 
possible.KFileMetaInfoItem

> I'd love to help you with this effort, since obviously XPM is an
> important file format.
XMP isn't really a file format :) But yes it is very important, and not only 
for image application, but for most of document application, it has 
application for Video and Audio as well, even if in those area the use of XMP 
is even less widespread than for Images.

Anyway, here is how I see sharing code, and in a way that don't bloat both 
framework, I much prefer to have things keep simple, especially that neither 
KisMetaData nor the base KMetaData library (KFileWritePlugin + 
KFileMetaInfoItem) are that big.

Sharing code should happen at lower-level library. It's imperative to be done 
at (least at) that level. I see two possibilities:

- very low level, directly out of libexiv2 (I strongly discourage the use of 
libexif) for Exif/IPTC tags (and maybe XMP is the future, Exempi is an other 
candidate for XMP tags, but digikam and Krita are allready depending on Exiv2 
so I don't think having KDE on something else is a good idea unless there is 
a very good reason). libexiv2 gives a pair of key/value, that can be plug 
directly in Strigi, or after some transformations in 
Krita/Digikam/gwenview/...

- or possibely at higher level, libkexiv2, it's a KDE wrapper around libexiv2 
use by at least Digikam, the reason why we don't use it (yet?) in Krita is : 
it doesn't output (yet?) a list of pair of key/value

And honestly I do believe that it is better to it this way than twist either 
framework to adjust to the need of the other.

-- 
Cyrille Berger