This decade has seen a tectonic shift in technology: the new information applications which are succeeding are those in which information is based on simple topics; the new document major document formats are those which allow the packaging of a topic.
The organization of information in to simple interlinked topics, typically something that can be described in a single phrase, is the common factor between such seeming disparate but succeeding technologies as the web-based Wikipedia, Amazon, Google, Ebay, Flickr, MySpace, YouTube, blogs, RSS, but also has had strong impact in non-WWW areas: the ITIL Configuration Item, the SCORM Learning Object, the S1000D Descriptive Module, integrated UML systems, for example.
The difference from the WWW in general is that though web technologies indeed encourage small pages, their is no necessity that pages are about one topic in particular. So the WWW is an excellent basis for implementing topic-based systems, but not itself one. Similarly, RDF may allow resources to be linked, but these are not necessarily at the level of topics. Another way of looking at topics is that a lack of topicality is what makes an poor index item poor.
There has been a decade long process at ISO SC34 to make and develop a series of standards based on topics, for example the Topic Map standard, IS 13250. This is good technology (like Xlink and RDF) to look at when considering how to implement a topic-based system.
The rise of Topics represents a great challenge to operating system and desktop suite vendors. When we look at Windows, or Mac or Linux window managers, we see that they really interact with the user at the wrong level. They say that the topic the user is interested in is applications and files. But how many people nowadays start their computer interaction with a web browser pointed to Google? There are still people whose organizing topic of interest in their computer interaction is the file or application, of course, but they have been swamped by people who are interested in the topic.
There are interfaces which organizes the user with different topics: most notably the Sugar interface of the One Laptop Per Child ($100 computers) in which the primary metaphors are the person (and their private activities and journal), the neighborhood, and the group (and group activities and bulletin board.) The interaction topics are “people, places, objects, actions”. But as with the desktop, these are not topics in general, just the topics of one domain (a fairly compelling domain, that of children and communities).
Indeed, we can see the large successful web applications as being topic-based interfaces each for particular domains and scopes. A lot of the Web 2.0 or Social Interface systems talk focuses on the human or social or write-able web aspects; my question is this: should we think of Topics as the “how” and the social aspect as the “why”, or should we think of the Topics the “why” and the social aspects as the “how”?
Moreover, should Linux, Windows, Mac and all seriously respond to the rise of Topical Interfaces by ditching the desktop metaphor? I tend to think yes: in terms of my supprt/runner/plug-in model topic interfaces belong at the “suite” level, and a desktop interface is just another suite.
One reason I found (and still do find) the Windows desktop so cumbersome to use compared to the a UNIX shell or the old Mac desktop was that it never seemed to provide me with the topics I was interested in. When the topic was “Installed programs” it lets me look at a menu from the start button, but not all programs are there; I have to switch to a completely different system, the file explorer, and look in Program Files and figure out from the files and directories what applications are there. We have to fight with the army we have, not the army we want, but we won’t win unless we have the army we need.
Topical Interfaces have eclipsed the Desktop Interface and are severely challenging the central position of the file., because increasingly the value of some information is in its linked-in-ness to some larger system. From this point of view, the recent trend (JAR, WAR, EAR, ODF, Open XML, SCORM, etc) to use ZIP and therefore package together all the files needed for one application session can be seen as an attempt to turn documents themselves in to a container for a bounded topic. OOXML’s Open Packaging Convention (OPC) represents the high-point (though not the state of the art, for which see RDF and ISO Topic Maps) in this trend, adding a linking and typing mechanism (relationships) within the ZIP package, However, the moves to make a platform out of the office suite and out of the Web browser (and the various Java Rich Client Platforms such as Eclipse, NetBeans, and so on) fall short of providing the integrated, topic-based interfaces.
The two worlds need to converge: we need Topical Interfaces which lets us navigate between and within topics and perform transactions, but which also allow each Topic can be bundled and shipped around as a document.
Over the last few months, in the office where I work, I have seen an amazing development effort that already is producing benefits, where a collaborative annotation system (PageSeeder) has been used to build a topic-based software engineering system that uses topics to tie all parts of a software job together:
- along ITIL lines, the basic abstract objects of interest inside the system and deliverables are identified as topics (e.g.a publishing system for pharmaceutical documents has “drug” as a central topic, regardless of whether there is a corresponding XML element for drug or how the requirements were organized, because the topic of “drug” is pivotal for discussion and use of the system),
- then links made to the original business requirements, architecture documents, sample documents, design documents, schema elements, stylesheets, test document and transforms, and bug tracking.
- All email and correspondence is saved by thread under a topic, and documents sent as attachments themselves are linkable.
The result is that when a customer decides they want some issue dealt with (new or altered functionality, bug fix, etc) and lodge this with a description, it is possible to trace trough the system to find all the original business requirements, which XML elements are affected, which scripts and styles and programs use these elements (and consequently, what will break or also need to be attended to), what previous discussion has been made, whether the new requirement contradicts an old requirement, and so on. (Some of the topics can be mashups of information in existing systems of course.)
I like your thoughts, coincides with what I'll be talking about at semantic strategies 07 regarding travel. Slide #4, Rick J. quote on topical interfaces, thanks!
The speculation:
http://lists.xml.org/archives/xml-dev/200609/msg00411.html
The math:
http://www.miislita.com/term-vector/term-vector-3.html
The inevitable:
www.patentstorm.us/patents/5659766.html
len
It's surprising that you could mention SCORM and S1000D but not DITA. It's totally topic based and has a nifty inheritance model for information types too.
F.: Yes DITA is another of topic-based schemas. Thanks for pointing it out!
(AFAIK DITA doesn't specify any user interaction by topic or and it doesn't have any particular file packaging mechanism, so it isn't a complete overlap on my topic (like ITIL and others I mentioned): it is not the mere use of topics, it is the topic as the prime method of interaction and the single-topic compound document that I was interested in.)
(In the publishing world, the use of generic and container based systems is not news, see for example the old military IETM work and so on. Cue Len.)
Rick is correct. The use of topic-driven and container systems predates the web. Work on MIL-D-28001 systems based on the earlier MIL-D-38784 and even earlier wase ongoing prior to HTML in IETM systems although the applications of networked documents was not as advanced particularly the use of path-based identifiers and simple protocols. The IETM systems pollinated the web system designs. The US Navy and Air Force had done extensive work on topical containers. The US Army genericized those in the IADS project (still ongoing) and the US Navy Metafile for Interactive Documents beat XUL and XAML to the punch by a decade.
It is a common pattern for small dedicated groups of advanced professionals to push ahead and plow ground for later groups to follow. The US and European DoDs and other insideTheFirewall groups usually have many pockets of advanced research and it is these demonstrations to select groups that convince funding agencies (See DARPA) to fund public and university projects to create in the clear versions of systems (See Mosaic) that are simpler but ready for the mass distribution into industry. While more publicized in areas such as aeronautics, it is common at every level of defense work and the price for the pioneers is anonymity. The reward is to see the frontier while it is still pristine and to move this knowledge into different applications, for example, topical organization of searching in real-time 3D worlds and messaging.
"their is no necessity that pages are about one topic in particular"
or
"there is no necessity that pages are about one topic in particular"
or
"pages need not concern a single topic."
"This decade has seen a tectonic shift in technology: the new information applications which are succeeding are those in which information is based on simple topics; the new document major document formats are those which allow the packaging of a topic."
This sentence is badly formed: it begins with false alliteration, in the middle it has a senseless repitition, and it ends with a term you do not define, a term that has nothing to do with technology per se. You are forcing the reader to guess at what you mean.
Do you mean something like this:
"The successful new document formats are those that center on topics. By topics, I mean..."
You do not define what you mean by "topic" and "topical interface" and "topical document" and it is difficult to guess how it is different from the name of a file. Do you mean meta data, a sort of yellow sticky added to a file? Do you mean searching or categorizing based on content? Do you mean manually linking related files?
You seemed to have written this quickly, without proof reading it.
It seems that the only people who understand what you are trying to say are people who could have dashed off the same thing.
This sounds like it may be an interesting subject.
I had saved this page in my news reader so I could read it carefully, but my time has not been rewarded.
KIT #1: Thanks for the typo corrections. Your name makes the Google Ads go crazy, by the way :-)
I do write fast: it is a blog not an essay (though I usually work out the entire item away from the computer, often in a long shower and sometimes taking over a week); and I do need a good editor: every writer does. But I don't need to apologize if my thoughts are unfinished: that is the way thoughts are.
KIT #2: You are wrong that the first sentence is badly formed AFAIKS. Maybe 'which' should be 'that'.
False alliteration? That suggests you are trolling.
By topic, I don't think I mean much other than the plain English meaning of the word. Consequently, it needs no definition. You want my second sentence to define "topic" more, but it does-- The organization of information in to simple interlinked topics, typically something that can be described in a single phrase,... (i.e. a simple topic is typically something that can be described in a single phrase, and information is being organized and interlinked as simple topics.)
However, I will go over the blog sometime this week to fix typos and clarify sentences.