The single, central content repository might exist somewhere, but the businesses I’ve seen employ a dozen or more content-focused systems: ECMS, WCMS, DAM, search, publishing systems… All of which need to be integrated for content and workflows to cross system boundaries with ease. (For example, to search and select images in the DAM system and place them in a Web CMS gallery, or in a print layout tool, without having to download files from the DAM to manually upload them into the WCMS.)

Bespoke point-to-point integrations between each of those systems are way too much work. (More on this in Improving DAM Interoperability In 2017.) I think Linked Data is a good model for making systems interoperate well, minimizing the amount of integration work required. Here’s eight “Linked Content” steps towards better interoperability, embracing Web architecture:

1. Each content object has its own Web page (“details page”)

First, every photo, article, or video needs its own permanent URL (see Cool URIs don’t change). Example: some random Flickr image.

Your system might already have such a details page URL. If not, start with this step even if you’re not ready for the rest; people will enjoy being able to share links to content via Skype or mail.

2. The details page contains structured metadata.

Just like the Flickr page linked above (check out its HTML source code), the details page should contain structured metadata (inside HTML “meta tags”).

Other Web sites and services (not just LinkedIn, Twitter or Facebook) can read that data to display a nice preview with headline and image instead of an ugly HTTP URL.

(More on that, including a video, in my Web frontend integration post.)

3. The API is accessible from the details page.

I assume that your content system offers a HTTP API (REST API, Web Service, RPC, whatever). The content object’s details page should include a link to the API so that software doesn’t have to construct it manually.

It doesn’t matter whether the API lives on a separate URL, or the detail page itself can return XML or JSON data (via content negotiation).

4. The details page URL is used to reference the object.

Whenever other systems reference a content object, they should use the full details page URL (not the ID or UUID from the originating system).

Object metadata read from the originating system can be stored as a copy in other systems to reduce the number of API calls. But the important thing is storing the URL, and displaying it as a hyperlink whenever the content is referenced in the user interface.

Note that the details page URL is three things in one: unique identifier, link to a human-readable Web page about the object, and link to the machine-readable API (see above).

5. The details page URL can be used for drag & drop.

People can drag URLs from the browser’s address bar. Your content system should accept a dropped detail page URL to establish a link to the content object.

See the video in Web frontend integration: Just drop me a link.

6. Chooser dialogs (“picker”) are available.

A “picker” is the Web equivalent of the “File / Open” dialog. People can invoke them to choose content objects from another system (see Google Picker and Dropbox Chooser).

Your system should be able to both invoke another system’s dialog, and offer a dialog to be shown by others.

7. Webhooks are available.

Webhooks are a way for one system’s API to notify the other’s about interesting events. For example, a DAM system could tell a WCMS to send a notification whenever an image from the DAM is published on the Web.

Webhooks should be supported both ways, i.e. your system’s events should be made available to other systems, and your system should be able to subscribe to other system’s events.

8. Metadata is exchanged in a standardized format.

To further reduce the amount of coding, configuration and documentation, all metadata exchange should use existing vocabularies and standards wherever possible.

I’d start with schema.org. It offers lots of helpful types and attributes already and is actively being evolved. It’s a format-agnostic schema so you can use it from JSON, XML, or RDF.

What do we gain?

Web standards-based, reusable interfaces leads to open, interoperable systems. Loose coupling is good for reliability and evolvability. You can set this up in any Web technology stack, on local servers or “in the cloud”.

As a bonus, you can treat foreign, external content (YouTube videos, tweets) similar to your own. And these principles aren’t limited to content systems, of course.

Problems to be solved

How do systems communicate with each other (directly or via an integration layer / “bus”)? How do authentication and authorization work? We’ll have to figure this out.

Also, this is a rather data-centric view, services and workflow processes are missing from that picture. But on top of this foundation, it should be relatively easy to implement a workflow system, “content hub” or search engine.

What do you think? Makes sense, too simple, too hard, you’re already doing it? Let me know via Twitter or mail!

Related blog posts: Web frontend integration: Just drop me a link., Web app interoperability – the missing link, System architecture: Splitting a DAM into Self-Contained Systems, Improving DAM Interoperability In 2017.

P.S.: If you’re into content system interoperability, why not join us in the W3C DAM group?