XMP, Krita, KFileMetaInfo and Strigi

[Jos van den Oever]

2007/6/22, Cyrille Berger <cberger at cberger.net>:
> 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 was not talking only about the search functionality. The most
important point is about KFileMetaInfo. Since Strigi provides the
information for KFileMetaInfo, it is relevant here, but KFileMetaInfo
is the main topic.

The code you are writing is a duplication of the functionality of
KFileMetaInfo. If you miss functionality in KFileMetaInfo, let's try
to put it in there. Granted the API froze, but who knows, you seem to
have researched your needs thoroughly and we might be able to work
with it.

What is important that all KDE apps show the same metadata for files.
If we start using different libs for this, this will not happen and
that is very confusing for the user.

> > 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.
This is not a critical point. Granted, analyzing the data from a
buffer is nice because it is faster, but such a small performance gain
(in the case of single files) can not be the main argument.
If it is really such a big problem, we can add a constructor or help
function that reads from buffer. Strigi can already do this, so
extending KFileMetaInfo like this is no problem. Currently it feeds
libexiv2 a buffer to get info out of it for analyzing jpeg files.

> But the biggest problems and limitations comes from KFileMetaInfoItem
> - QVariant is not good enought:
>  - it lacks some important types like rationals
a double is not a rational? QVariant::Double

>  - 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)
I'm not sure I understand, if a list must be sorted, the analyzer
should sort it and pass it on sorted. Can you provide the use case?

>  - 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
Sounds like QValidator + QMap to me. Input validation when editing is
important. That is why KFileWritePlugin provides access to a
QValidator for the widgets.

>  - 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".
This type of information is indeed harder, but we should solve it at
the KDE level, not for one particular app. A UserType is not a hacked
solution in my opinion if it serializes nicely.

> 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
QValidator in KFileWritePlugin

> > 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.
And that is the reason it should be incorporated in the Nepomuk
ontology and work with Strigi and KFileMetaInfo. If this is not
possible, then these frameworks are inadequate and should be enhanced.

> 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.
I completely agree, but I dont think KisMetaData should exist at all
except as Strigi analyzers and KFileWritePlugins. By going your own
way, you completely miss the point of the semantic desktop, which is
to allow all applications to know more about files and other objects
on the desktop. If krita speaks its own language, it cannot talk to
the other desktop apps and you lose the advantages this brings. This
is more effort than writing your own stuff because you have to
converse with others to get it working and agree on a common approach.
This is not always easy, but the result is all the move valueable.

> 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.
If you like to be on an island then yes.

Cheers,
Jos