3b. Relational Structure (Inter-Repository)
Your completed content objects might relate to content in another repository. Say our news article written by Bob Smith is on our intranet. It’s therefore somewhat related to Bob Smith’s Active Directory record (which is also content, just not in a traditional content management system).
This link could be loose or formal. Bob Smith’s name on the byline could be a mailto
link. Clicking it would pop open a new email in Outlook addressed to Bob, and clicking on Bob’s name in the email would open a dialog with all the information about him stored in Active Directory
More formally, it can be more explicit via something like RDF. Our Active Directory system might expose Bob’s data via a Web service and our intranet has a page which pulls that data and renders an employee profile page we can get to from our news article.
Even more explicit, Ad might expose a URI, and the CMS might hold our news article, which references the Active Directory URI via RDF or other semantic linking scheme. So there is now a “hard” link between these two content objects in two different repositories.
This is the inter-repository level – still talking about content objects, but how they’re organized between repositories, rather than within a repository.
4. Information Concept Structure
A repository of content might be related to another repository of content then be brought together as part of a larger information concept to which they both belong.
Say our humble news article is in a content management system inside our company as part of a larger intranet. It may be a piece of a larger construct. For instance, if it’s a news article about the new Whizbang 5000 project, then other content from other repositories might also relate. If someone is searching the organization for information on the W5000, this news article might come back, as well as 453 emails from their index, 13 wiki pages, 57 Word documents, and 19 images. All this content together from all these repositories forms a larger – albeit amorphous – construct of “Whizbang 5000 Data.”
We’re still talking about content objects here, but now as repositories of content objects within larger information concepts.
In an attempt to put it all together, here’s a completely contrived example that pretty much works backwards from the stages explained above –
Mary needs to know why the Whizbang 5000 uses a Gimmel Widget to tighten the Whatoozit Nut.
She searches the intranet for “whizbang 5000 gimmel whatoozit.” Given the search parameters, the results are all part of a very loose construct of “Whizbang 5000 Data.”
She looks through the results, and finds some news articles in a content management system (a single repository) from the communication team about the development of the Whizbang 5000. She pages through these, and sees the title of a single article called “Connectors for the Whizbang 5000” written by a veteran company engineer named Bob Smith.
Opening this single content object, she doesn’t find what she needs, but thinks maybe the author would have written something else. She clicks on Bob’s name and goes to his author page (a different, related content object), where she finds he’s written another article called “My Theories on Widgets” She reads the summary (a single content property) of this article, and thinks it’s close to what she wants.
Opening the article, she finds a table of content at the top which extracts the heading from the content of the body of the article. There’s a heading called “Why I Love the Gimmel Widget.” She clicks that heading to scroll down to the content, and, under the heading, she finds that Bob’s mother’s middle name was Gimmel.