XMP, Krita, KFileMetaInfo and Strigi

[Cyrille Berger]

> XMP seems to be a pseudo-standard already in use so there is no point in
> trying to replace it with a Nepomuk ontology. In addition the XMP data is
> stored in the file itself (right?).
That's correct (except with s/pseudo// ;) ).

> That is why I thought Nepomuk could not 
> solve the problem right away. What would be of interest however, would be
> to also store the data in Nepomuk to make it searchable and linkable. maybe
> for this we need a bridging ontology that links XMP data with data
> specified in Nepomuk ontologies.
Yes but that's really for the future :)

> But as far as KFileMetaData is concerned I also think it would be good to
> make it powerful enough to handle the metadata used in Krita. However,
> since the KDE API is frozen, how about you, Cyrille, model your xmp lib
> very closely to kfilemetadata so it can easily be merged in KDE 4.2 or 5.0
> or whatever.
Yes that's more or less the case, especially that now we have talked about it 
on irc and found an acceptable solution that wouldn't need much change, 
except that it indeeds require only the addition of a function. The solution 
would be to store a rational as a QList<QVariant> (containing two int) and 
then when accessing the metavalue  RationalDataType( entry->getValue()); (and 
etc) but it still need the addition of a function returning the type of the 
value.

And as the validation process is not yet define in either solution, I see no 
problem having two experimentations done at the same time in different place 
and then a discution on how to merge them.

Not counting that KFileMetaData needs to read from a QIODevice limited to the 
metadata blob of a file. And now that I think about it I wonder if it 
wouldn't be better to have a KBlobMetaDataReader/Writer different of a 
KFileMetaData, as anyway the KFileMetaData that strigi use reads file, and 
the one needed by Krita reads memory blob, part of a file, but still there is 
a functional difference.
-- 
Cyrille Berger