The single, central content repository might exist somewhere, but the businesses I\u2019ve seen employ a dozen or more content-focused systems: ECMS, WCMS, DAM, search, publishing systems\u2026 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.)<\/p>\n\n\n\n
Bespoke point-to-point integrations between each of those systems are way too much work. (More on this in Improving DAM Interoperability In 2017<\/a>.) I think Linked Data<\/a> is a good model for making systems interoperate well, minimizing the amount of integration work<\/a> required. Here\u2019s eight \u201cLinked Content\u201d steps towards better interoperability, embracing Web architecture:<\/p>\n\n\n\n First, every photo, article, or video needs its own permanent URL (see Cool URIs don\u2019t change<\/a>). Example: some random Flickr image<\/a>.<\/p>\n\n\n\n Your system might already have such a details page URL. If not, start with this step even if you\u2019re not ready for the rest; people will enjoy being able to share links to content via Skype or mail.<\/p>\n\n\n\n Just like the Flickr page linked above (check out its HTML source code), the details page should contain structured metadata (inside HTML \u201cmeta tags\u201d).<\/p>\n\n\n\n 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.<\/p>\n\n\n\n (More on that, including a video, in my Web frontend integration<\/a> post.)<\/p>\n\n\n\n I assume that your content system offers a HTTP API (REST API, Web Service, RPC, whatever). The content object\u2019s details page should include a link to the API so that software doesn\u2019t have to construct it manually.<\/p>\n\n\n\n It doesn\u2019t matter whether the API lives on a separate URL, or the detail page itself can return XML or JSON data (via content negotiation<\/a>).<\/p>\n\n\n\n Whenever other systems reference a content object, they should use the full details page URL (not the ID or UUID from the originating system).<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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).<\/p>\n\n\n\n People can drag URLs from the browser\u2019s address bar. Your content system should accept a dropped detail page URL to establish a link to the content object.<\/p>\n\n\n\n See the video in Web frontend integration: Just drop me a link<\/a>.<\/p>\n\n\n\n A \u201cpicker\u201d is the Web equivalent of the \u201cFile \/ Open\u201d dialog. People can invoke them to choose content objects from another system (see Google Picker<\/a> and Dropbox Chooser<\/a>).<\/p>\n\n\n\n Your system should be able to both invoke another system\u2019s dialog, and offer a dialog to be shown by others.<\/p>\n\n\n\n Webhooks<\/a> are a way for one system\u2019s API to notify the other\u2019s 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.<\/p>\n\n\n\n Webhooks should be supported both ways, i.e. your system\u2019s events should be made available to other systems, and your system should be able to subscribe to other system\u2019s events.<\/p>\n\n\n\n To further reduce the amount of coding, configuration and documentation, all metadata exchange should use existing vocabularies and standards wherever possible.<\/p>\n\n\n\n I\u2019d start with schema.org<\/a>. It offers lots of helpful types and attributes already and is actively being evolved. It\u2019s a format-agnostic schema so you can use it from JSON, XML, or RDF.<\/p>\n\n\n\n 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 \u201cin the cloud\u201d.<\/p>\n\n\n\n As a bonus, you can treat foreign, external content (YouTube videos, tweets) similar to your own. And these principles aren\u2019t limited to content systems, of course.<\/p>\n\n\n\n How do systems communicate with each other (directly or via an integration layer \/ \u201cbus\u201d)? How do authentication and authorization work? We\u2019ll have to figure this out.<\/p>\n\n\n\n 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, \u201ccontent hub\u201d or search engine.<\/p>\n\n\n\n What do you think? Makes sense, too simple, too hard, you\u2019re already doing it? Let me know via Twitter<\/a> or mail<\/a>!<\/p>\n\n\n\n Related blog posts:<\/em> Web frontend integration: Just drop me a link<\/a>., Web app interoperability \u2013 the missing link<\/a>, System architecture: Splitting a DAM into Self-Contained Systems<\/a>, Improving DAM Interoperability In 2017<\/a>.<\/p>\n\n\n\n1. Each content object has its own Web page (\u201cdetails page\u201d)<\/h3>\n\n\n\n
2. The details page contains structured metadata.<\/h3>\n\n\n\n
3. The API is accessible from the details page.<\/h3>\n\n\n\n
4. The details page URL is used to reference the object.<\/h3>\n\n\n\n
5. The details page URL can be used for drag & drop.<\/h3>\n\n\n\n
6. Chooser dialogs (\u201cpicker\u201d) are available.<\/h3>\n\n\n\n
7. Webhooks are available.<\/h3>\n\n\n\n
8. Metadata is exchanged in a standardized format.<\/h3>\n\n\n\n
What do we gain?<\/h3>\n\n\n\n
Problems to be solved<\/h3>\n\n\n\n