Comments on: XMP vs RDF or RDF vs XMP

By: Cyrille Berger

Cyrille Berger — Thu, 28 Jun 2007 20:48:00 +0000

@bruce, Curriously what you blame on XMP, I do blame it to RDF I find they use string for too many things in Exif. As for your example, that is correct, but nothing prevent you to propose a schema with a structure with more information for the author field.As for Krita, KOffice, Metadata, ODF, Nepomuk, KDE there will be a big clash at some point, and being aware of it sooner might help to smooth the problems, and hopefully some of those points will be discussed at next Akademy. An other problem might comes around OpenRaster, that some people wants to push in ODF, and I for myself favor use of XMP in it as long as there is no other decent specification for graphics metadata to replace it. So that might make an other clash, but that one doesn’t concern me, as anyway, I don’t want OpenRaster to be part of ODF.The perfect solution would be, of course, for Adobe to donate XMP to the W3C which would allow them to update it and make it more compatible with recent RDF, or for Adobe to do the work. As rewritten a specification that would replace XMP requires a lot of work and testing, times I am not willing to invest myself.

By: Bruce

Bruce — Thu, 28 Jun 2007 20:41:00 +0000

Also, on “I also have serious doubts that if I found something lacking in a W3C specification which is as likely to happen than in XMP, they would even bother to listen to me So for a miserable ant like me it doesn’t make a real difference.”I think there’s still a significant difference between a multi-vendor consortium that has public comment policies and so forth, and a spec developed by a single company according to its own priorities. The first characteristic means its less likely the resulting spec has significant problems, and the second means there is a mechanism for fixing problems.

By: Bruce

Bruce — Thu, 28 Jun 2007 20:17:00 +0000

I missed this conversation earlier. One of the practical problems with XMP the last I looked is that it it tends to treat all properties as strings. But a whole lot of useful metadata is about objects; an author is not a string "Jane Doe" but a person that has the name "Jane Doe" and so forth. This has practical consequences for users and applications.But this all depends on what you need. I raised the issue in an earlier comment in part because I thought Krita has some connection to KOffice. I would think, then, that you might want to look into a common metadata approach and code, API, etc. In that case, XMP would yield problems.I could be wrong in that assumption, though. If the scope of this will only ever be images in Krita, then it might be fine to use XMP.

By: Cyrille Berger

Cyrille Berger — Sun, 24 Jun 2007 20:51:00 +0000

Not that not good enought, it would need to be able to export. And that's more tricky than it seems, and that's what needs a lot of work, that I feel unneeded. (and it requires a lot of changes inside nepomuk spec as well).The problem is that the convertion you do must ensure that you can recover the original meaning of the data following the Exif/IPTC specification, and that's something which is not guaranteed by Nepomuk.But I really really don't understand the problem of having Krita manipulates the metadata as XMP/Exif/IPTC, and then Nepomuk load the XMP metadata from this file and do whatever it wants to it.

By: superstoned

superstoned — Sun, 24 Jun 2007 20:09:00 +0000

So I take it if Nepomuk could import XMP, that’s not good enough yet for you, so you need a seperate way of reading it anyway?Or is it that it would take much more work to get XMP in Nepomuk and then in Krita than doing it directly? I could see why you would want to go your own way in that case – you’d rather work on Krita…

By: Cyrille Berger

Cyrille Berger — Sun, 24 Jun 2007 13:40:00 +0000

Well we are currently discuting the subject But no Krita using their XMP filter is not the problem. XMP is not even the problem. What Krita needs is the possibility to load and save all metadata from Exif/IPTC. And currently XMP is only “next generation” specification with that kind of guarantees. While it could be added to Nepomuk, it’s a huge task, I am not willing to do it, and I am not sure I will have the time to evaluate it, even if some of the Nepomuk folk seems to want to do that.What I would see a more usefull spending of their time is ensuring that Nepomuk gets capable of importing XMP into their representation.

By: superstoned

superstoned — Sun, 24 Jun 2007 11:54:00 +0000

OK, but if Nepomuk and Strigi need to support XMP anyway, would working together (eg Krita using their XMP filters) not be better? If you work on XMP, Strigi/Nepomuk and all apps using them would have better meta-info about files using XMP, right?

By: Cyrille Berger

Cyrille Berger — Sun, 24 Jun 2007 08:03:00 +0000

No it means, in facts Krita needs a reliable way of converting from and to Exif/IPTC tags, and currently only the XMP specification guarantee this. But the way I see things, Krita can very well work with XMP, while Nepomuk/Strigi work with RDF, they just have to provide a way to convert XMP to RDF (like they allready for Exif to RDF).

By: superstoned

superstoned — Sat, 23 Jun 2007 22:10:00 +0000

So, you can support RDF, but then you can’t FULLY support XMP, right? Or you can support XMP, but then there is no RDF. Are you sure there is no way to solve this? It sucks to have to make a choice between interoperating with the vast majority of Graphics tools, or with the rest of KDE…