XMP vs RDF or RDF vs XMP

This is an answer to a comment from Bruce on my previous post, and the reason why I favor more XMP than RDF; at least at the moment. I will start by saying no decision have been taken on whether Krita should be “limited” to XMP (or RDF), or whether OpenRaster will be using XMP instead of RDF.

XMP is subset of RDF

So XMP is a subset of RDF and doesn’t support all the features of RDF, and it’s using an older version of RDF. I can understand that it makes it harder to use a RDF parser to manipulates XMP data, but from my point of view it’s hardly a problem, as long as XMP allows to do everything I want to do in metadata in Krita. Then, I would add that supporting XMP is important because it’s quiet well established in the graphic world.

XMP is not fully opened

That said I shared the same wish as Bruce that Adobe would open up more the XMP specification. But the real reason behind the current “embrace” of the Open Source world for XMP is that Adobe made the first step. While until very recently the XMP Spec was only available with a package that only Adobe could distribute, meaning they could shut down the access to XMP at any moment. But with their recent change of licensing policy, it makes XMP attractive to open source application. While adding support to XMP is unlikely to change their mind on opening more the specification, not supporting it is clearly showing Adobe that we don’t care, and then why should they care ?

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.

So why, even with that bad point, I still prefer XMP over RDF ?

The first reason is that I still don’t understand the full extend of RDF (after having spending quiet some times digging on the w3c or in the web), which either mean I am completely stupid or that it covers too much. While XMP is designed specifically for multimedia documents, and it has everything needed for handling the associated metadata. And I much more favor simplicity, and having more specifications instead of one that suppose to rules all the other.

I am also missing something from the Exif and IPTC schemas I found for RDF (unless I didn’t see something), they don’t defines the types of each fields.

XMP is vastly used in the graphics world

To finish, the main reason why I consider it is important to support XMP is that there is an increasing number of files which includes XMP metadata.

This entry was posted in Krita, Open Source and tagged , , , . Bookmark the permalink.

9 Responses to XMP vs RDF or RDF vs XMP

  1. superstoned says:

    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…

  2. Cyrille Berger says:

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

  3. superstoned says:

    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?

  4. Cyrille Berger says:

    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.

  5. superstoned says:

    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…

  6. Cyrille Berger says:

    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.

  7. Bruce says:

    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.

  8. Bruce says:

    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.

  9. Cyrille Berger says:

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

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>