XMP, Krita, KFileMetaInfo and Strigi

[Cyrille Berger]

> 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.
Yes its the results of my thinking about metadata for krita for more than a 
year now :) (since noticing the problem of the previous metadata handling in 
Krita)

> What is important that all KDE apps show the same metadata for files.
What do you mean by that ?

> If we start using different libs for this, this will not happen and
> that is very confusing for the user.
I don't think user should ever see a library, and not even been talked about a 
library. A user just have to see a User Interface, but unless I have missed 
something that's not about what we are talking about ?

> > 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
Yes it is, but a rational isn't a double, it's a division between two 
integers.
For instance, there is no double representation of the rational 2 / 3 
(0.66666666666666666666666666666666 is just an approximation, even if the 
mathematical theory says that 0.666 followed only by 6 is equal to 2 / 3, but 
there is no way to represent such a thing in double, 2/3 is represented by 
0.666..67 in a double anyway).

> >  - 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?
No you didn't understand, their are two kinds of lists: lists for which order 
matters (a list of author, they are usually sorted in the order of importance 
of his work) and list for which order don't matters (like keywords). And 
while it's very understandable that an application wants to sort a list of 
keywords, it is unacceptable for a list of authors.

> >  - 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.

Unrelated.
Lets take an exemple out of the XMP spec , it defines a Dimension structure as 
follow:
 - one field named "w" of type real
 - one filed named "h" of type real
 - one filed named "unit" of type string

How I would use that structure in the code is:
QMap<QString, Value> dimensionValue;
dimensionValue["w"] = 10.0;
dimensionValue["h"] = 20.0;
dimensionValue["unit"] = "cm";

Then I create a metadata entry:
metaDataList["nameofthetag"] = Value(dimensionValue, Value::TypeStructure );

The second example is called "Alternative Arrays". The main usecase for this 
is for translation of some metadata (but there are some other uses in the 
spec). So basically in your code you have
QMap<QString, Value> description;
description["fr-fr"] = "Ma description";
description["en-us"] = "My description";

then I create the metadata entry as
metaDataList["dc:description"] = description;

So what the difference ? The difference is that spec limit the number and the 
name of values in a structure (dimensionValue["x"] = 3.0; is invalid while 
adding description["de-de"] = "meine Beschreibung"). So 
there is a need for later purpose to make a distinction between those two 
(not counting that it helps when saving if you have an idea of the real type 
of the value).

> >  - 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.

And once again you miss the point :) Maybe I shouldn't have spoken of the 
UserType in this sentence. So forget about the first line and reread the 
rest.

> > 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
As you are aware QValidator takes a QString in input and return true if the 
string is a valid answer.
What is needed here is more complex, among other things:
 - each tag is associated to a single type, so when the tag is initialized it 
needs to be initialized with the correct value
 - structures needs to be checked to see if they have the correct fields (no 
field "x" for the Dimension and not missing a field "h")

> > > 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.
I am bit confused now, but I talk with Sebastien about XMP/Exif/IPTC metadata 
and he told me Nepomuk couldn't help me directly in that matter, so I must 
have missed something.

> > 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
There are other missing stuff in strigi annalyzers and KFile* but they don't 
need changes, they are just addition, so I didn't spoke about them (unless 
you want to ?).

> 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.
I really really don't see any lost. The biggest part of all this is allready 
assumes by other libraries that are shared.

> > 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.
... (I really love to see that kind of comment, that soooo constructive)

-- 
Cyrille Berger