{"id":1782,"date":"2014-10-22T00:00:00","date_gmt":"2014-10-21T22:00:00","guid":{"rendered":"https:\/\/wwwneu.strehle.de\/tim\/weblog\/archives\/2014\/10\/22\/1743\/"},"modified":"2025-07-31T22:02:23","modified_gmt":"2025-07-31T20:02:23","slug":"1743","status":"publish","type":"post","link":"https:\/\/www.strehle.de\/tim\/weblog\/archives\/2014\/10\/22\/1743\/","title":{"rendered":"Rights Management in the DC-X DAM \u2013 and RightsML"},"content":{"rendered":"\n

I had the honor to attend the \u201cMachine Readable Rights Workshop\u201d at the IPTC Autumn 2014 meeting<\/a> in Frankfurt, Germany today. And to hold a short presentation [PDF]<\/a> on \u201cRights Management in the DC-X DAM\u201d. Here\u2019s what I intended to say (the actual talk was a bit shorter):<\/p>\n\n\n\n

\"\"\/<\/figure>\n\n\n\n

<\/p>\n\n\n\n

\u201cI\u2019ve been following the IPTC<\/a>\u2019s work for many years and I think you\u2019re doing a great job, and you keep changing the news industry for the better. Thanks for that! And I\u2019m also excited to meet some of the people I follow on Twitter in real life. Thanks a lot for the invitation to this workshop!<\/p>\n\n\n\n

Digital Collections<\/a> is a rather small DAM system vendor, but has lots of experience in the publishing industry. 23 years ago, we were one of the first companies in the world to build digital newspaper archives, and to import digital text and photos from news agencies into a full-text searchable database.<\/p>\n\n\n\n

\"\"\/<\/figure>\n\n\n\n

<\/p>\n\n\n\n

Our product DC-X is a pretty normal DAM system: It provides a database and search engine, at which you can throw any kind of file or text. Our customers usually keep their editorial newspaper or magazine content in it, and input from news agencies and photographers: Images, videos, article text, PDF pages and so on. The largest installations store tens of millions of documents and receive tens of thousands images per day. We extract text and metadata, and make it searchable and editable. And then we\u2019re integrating that with other software: editorial systems, Web CMS, syndication and so on. Our customers are calling DC-X their \u201ccontent hub\u201d.<\/p>\n\n\n\n

\"\"\/<\/figure>\n\n\n\n

<\/p>\n\n\n\n

I have to admit that I haven\u2019t heard our customers ask for RightsML<\/a> support so far. I\u2019d love to play with RightsML, but that\u2019s why we haven\u2019t started work on an implementation yet. But I really hope this is going to change, and maybe you can provide me with some selling points today.<\/p>\n\n\n\n

\"\"\/<\/figure>\n\n\n\n

<\/p>\n\n\n\n

But what our customers are asking for is rights management inside our application. They need to know whether they\u2019re allowed to use an image online \u2013 or in new output channels, like an app. Costs are important, too; expensive images need to be marked as such. And customers who open up their historical newspaper archives might have to set rights for old content.<\/p>\n\n\n\n

\"\"\/<\/figure>\n\n\n\n

<\/p>\n\n\n\n

We started working on that feature four years ago, and maybe a third or half of our customers have already started using it. We\u2019re focusing on what we call \u201crights profiles\u201d, which is a set of rights metadata that is identical for multiple digital assets. We\u2019re trying to model the actual contract between a content provider and the content user in a rights profile.<\/p>\n\n\n\n

\"\"\/<\/figure>\n\n\n\n

<\/p>\n\n\n\n

For example, there\u2019s a contract between a newspaper publisher and the German news agency dpa that permits the newspaper to use images online and in print without paying royalties per image (covered by a yearly fee). One contract means one rights profile in our software, which is linked to the thousands of images from the dpa within the DAM. We\u2019re storing the rights metadata in a structured, machine readable way. You can see a textual description on the right hand, and two icons below the image that mean \u201cOnline usage OK\u201d and \u201cPrint usage OK\u201d.<\/p>\n\n\n\n

\"\"\/<\/figure>\n\n\n\n

<\/p>\n\n\n\n

Then there are rights that are valid only for a single image \u2013 we\u2019re calling these \u201cspecial agreements\u201d. Special agreements take precedence over rights profiles. So when the news agency revokes an image, you don\u2019t have to remove the rights profile for the general contract \u2013 you add a special agreement for that image, whose properties then selectively override the rights profile\u2019s. In the screenshot, you can see me adding a special agreement with \u201cUsage permitted: None\u201d.<\/p>\n\n\n\n

\"\"\/<\/figure>\n\n\n\n

<\/p>\n\n\n\n

Look how the print and online usage are now grayed out, and a red warning sign is displayed.<\/p>\n\n\n\n

\"\"\/<\/figure>\n\n\n\n

<\/p>\n\n\n\n

The rights metadata form can be customized, of course. Here\u2019s a complex real-life example.<\/p>\n\n\n\n

\"\"\/<\/figure>\n\n\n\n

<\/p>\n\n\n\n

Now how could RightsML help us? One of the biggest hurdles for our customers to adopt our rights management features is that they have to manually define all these rights profiles, and configure our software to link to the correct rights profile on import. That\u2019s a lot of work. It would be great if content providers could do that work instead and provide the correct rights profile. But because we have built our own proprietary and simplistic rights engine, we\u2019re stuck. Implementing RightsML would enable interoperability.<\/p>\n\n\n\n

Two more things I\u2019m currently thinking about with regards to RightsML:<\/p>\n\n\n\n

\"\"\/<\/figure>\n\n\n\n

<\/p>\n\n\n\n

First: The spec says that RightsML need not be embedded, it can be \u201ccommunicated separately\u201d. That seems to be an attractive option for a couple of use cases: A) When many content items share the same rights. We don\u2019t want to store the same set of rights again and again for each item. Not just to save space, but to make it easier to edit rights in our system. And B) we often have images in our systems that must be bought before they can be used, and the exact rights are being negotiated on the phone or during an online purchasing process when the image file is already in the production process.<\/p>\n\n\n\n

\"\"\/<\/figure>\n\n\n\n

<\/p>\n\n\n\n

And the second thing: In my eyes, rights are pretty different from other kinds of metadata. And the data structures and algorithms for storing and evaluating RightsML or PLUS<\/a> expressions are complex and hard to implement. It starts with having to create several database tables just to store the rules. I don\u2019t see too many software vendors doing a proper implementation soon.<\/p>\n\n\n\n

\"\"\/<\/figure>\n\n\n\n

<\/p>\n\n\n\n

But that rights are so different, and essentially independent of the content, is also an opportunity: It allows us to handle rights outside of the existing applications. Ideally, there would be an application that specializes in displaying, editing and evaluating machine readable rights. A Web CMS or DAM could call its API to store or retrieve rights, and to evaluate whether a specific usage is allowed. Later you could add contract, usage and royalties information. (A part of that functionality seems to be covered by the PLUS Registry<\/a>, by the way. But personally, I\u2019d favor a local registry over a central one \u2013 I\u2019m not sure about performance and security, and we\u2019d want to use the registry for article text as well which isn\u2019t the PLUS use case.) I\u2019m convinced that open source, easily-integrated \u201cmachine readable rights hub\u201d software would help drive RightsML adoption.<\/p>\n\n\n\n

\"\"\/<\/figure>\n\n\n\n

<\/p>\n\n\n\n

I\u2019m looking forward to the discussion. Thanks for your time!\u201d<\/p>\n\n\n\n

Update:<\/em> See my follow-up post The business case for machine readable rights<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"

I had the honor to attend the \u201cMachine Readable Rights Workshop\u201d at the IPTC Autumn 2014 meeting in Frankfurt, Germany today. And to hold a short presentation [PDF] on \u201cRights Management in the DC-X DAM\u201d. Here\u2019s what I intended to say (the actual talk was a bit shorter): \u201cI\u2019ve been following the IPTC\u2019s work for […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_share_on_mastodon":"0"},"categories":[1],"tags":[],"class_list":["post-1782","post","type-post","status-publish","format-standard","hentry","category-weblog"],"share_on_mastodon":{"url":"","error":""},"_links":{"self":[{"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/posts\/1782","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/comments?post=1782"}],"version-history":[{"count":1,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/posts\/1782\/revisions"}],"predecessor-version":[{"id":1924,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/posts\/1782\/revisions\/1924"}],"wp:attachment":[{"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/media?parent=1782"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/categories?post=1782"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.strehle.de\/tim\/wp-json\/wp\/v2\/tags?post=1782"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}