At Johns Hopkins, we're about to embark on a content strategy adventure led by Ahava Leibtag and her posse at Aha Media Group. Our team has been thinking a lot about content over the past year as we designed and built our news aggregation thingy that we call the Hub. I'm excited to work with Ahava in part because she's passionate about structured content, and as I think about structuring everything on jhu.edu, I start to wonder what we do with it once it's smashed into tiny structured pieces.
This process of breaking big blobs of content into smaller chunks has been on our minds a lot, because at the center of our Hub is an ever-growing database of lovingly smashed-apart content fields (sometimes called "structured content" when people are being extra polite) and a RESTful API to deliver that content to whoever might be interested. Our latest work on that API has us thinking about how to make it more hypermedia-driven.
To understand how structured content is connected to apis and hyperblahblahs, you have to understand a little about "resources". For us, articles are our biggest resource. If you want article content from our database, you should be able to go to /articles and see a list of article resources, or to a URL like /articles/55 and see the information for one specific article.
A well-designed, hypermedia-driven resource is a combination of information about itself and information about its relationships to other resources. An article might have a headline and a summary, but it might also be related to a collection of image resources or tag resources. A consistent definition of each of those relationships is extremely important when trying to put them all together (what is this collection of things called "images" and how are they related to this "article"?).
The internet happens to be built on a system that supports these kinds of relationships. If you've ever built a website, you may have seen something like this: <link rel="stylesheet" href="" /> That "rel" attribute is a centrally defined relationship that says the document you're looking at is related to some other document, found at the location defined by the "href" attribute, and related as a "stylesheet". Your web browser knows what to do with "stylesheet" related documents, which allows us to separate things and trust that a client (a browser, etc) can easily and accurately put them back together.
This brings me back to my concerns about structured content. Once you break apart all your fields so that futuristic refrigerators can display your beautiful content, how does the refrigerator know how to put it back together?
Tonight, while driving home from Target, I was talking to myself about this problem. At some point in my conversation I decided the answer might be "rels", or a list of centrally defined relationships between a content object and its FIELDS. Say we have a "news article" content object. We might partially define it like this:
Content Object Definition
name: News Article
description: Text content about news information
field_rels:
descriptive_title
teaser_title
excerpt_summary
image_thumbnail
Then each relationship would have its own definition.
Relationship Definitions
descriptive_title:
type: rich text
description: A title that aims to accurately and sufficiently describe the content of the object.
teaser_title:
type: rich text
description: A typically shorter title that may be more mysterious or unintuitive, but that aims to create interest in the object.
etc.
Now when we define an article resource for something like the Hub, we can first identify "article" as being defined by the generally accepted "News Article" content object definition, linking to that definition document in some central place. When we define the specific fields of our resource, each field would have a name and a "rel" too, for example relationg our "headline" field to the "descriptive_title" relationship definition.
When the refrigerator (or the microwave or the mini-screen inserted in everyone's future eyeball, or what have you) receives your article content, it immediately knows what types of fields it has to work with. It might say, "I need a descriptive_title for this case, looks like that's in the headline field here, and I also need an excerpt_summary and a thumbnail, and those will all fit in this space like this..."
Sidenote: The relationship definitions might even point to some kind of "master field type", like "rich text" above, that defines what each device should expect from any field identifying as that kind of relationship. This field is a "teaser_title"? That's defined as a "plain text" field so I don't expect there to be any HTML tags or other markup in it, I can just display it inside of my own
<p>tags. This "excerpt _summary" should be a rich text field so display it as-is with its own markup. And so on.
The most powerful part of this kind of set up is that "rels" are extendable. When you define a resource, you can list the "rel" as something predefined like 'descriptive_title', or list it as "http://mysite.com/field_rels/seo_title", with that URL pointing to your own custom definition. The "client" (that's what the refrigerator or the eyeball screen would be called, generally) can still learn about how your fields go back together because the relationships are all defined in a consistent way.
These thoughts are all over the place and still really fresh (Target is only 5 minutes from my house so I didn't have a ton of time to talk to myself about all of this). Are there other strategies for how to put our humpty dumpty content back together once we successfully smash it into structured pieces?