8 Steps to Linked Content
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.
More links to Tim Stehle
