Docbases are rich with implied interconnectedness. For example, a report about Internet Explorer in the ProductAnalysis docbase might prompt a reader to explore the docbase along several dimensions:
More reports about Internet Explorer
The previous report about Internet Explorer
More reports by the author of this report
The next report by the author of this report
More reports about Microsoft products
More reports due around the same time as this one
In the relational database discipline, we satisfy the “More reports about...” kind of request with an SQL query, such as:
select * from docbase where product = 'Internet Explorer'
To handle a “Next report by author...” kind of request, we fetch and then navigate within a result set. These mechanisms enable users to explore the interconnectedness of a data set. But they don’t reveal it explicitly. That’s our goal in this chapter.
I’ve said that a docbase marries two disciplines: data management and publishing. From a data-management perspective, it might be enough to just bolt a web interface onto standard database query mechanisms. But a docbase isn’t just a database; it’s a hypertextual publication. The interface to that publication is distributed across every page of the docbase. A docbase works best when every piece of its distributed interface answers two basic questions: “Where am I?” and “Where can I go from here?”
The answers to these questions can take many shapes and styles. In the BYTE Magazine docbase ...
No credit card required