The Need for Collaboration and Interoperability...
In our day to day work, we occasionally lose sight of the goals we are trying to accomplish, and we need people to remind us of those goals and set us on our way. The May issue of Dr. Dobbs has such an article. "A Manifesto for Collaborative Tools" by Eugene Eric Kim reminds us of Doug Engelbart's vision. Published in 1962, "Augmenting Human Intellect: A Conceptual Framework" (or here) discusses how the complexity of problems that people are trying to solve is increasing at an extremely alarming rate. Not only must our solutions scale to solve these problems, but by working together, we will get collectively smarter and be more efficient, and computers are a tool that can help us accomplish this goal.
One example that Eugene presents to demonstrate that our current tools are inadequate is that document sharing is typically done via e-mail, instead of through a more collaborative environment, such as Yahoo! Groups or Buzz Saw, amongst others. In either form, the electronic documents that we share are not really as flexible as their paper counterparts, which could be marked up and annotated quite easily; Word documents, on the other hand, are not well suited for this, and although it provides some annotation facilities, they are not as flexible as paper. Another example of this same idea is presented in What UML Is and Isn't, in which the author states the UML is best for whiteboards and paper, and he rarely creates such diagrams in a UML tool.
Eugene highlights that some of the issues with some of the existing tools is that they were not designed for people, in which he quickly adds that our needs are very broad and varied and that we will always use a number of different tools. The latter point really leads to one of the points of his Manifesto, which is interoperability. To be interoperable, we need standard components, and in order to create these standard components, we have to communicate with each other and see what we have accomplished this far. Eugene compares this need for standard components and a standard language to what the relational algebra and SQL has done for databases; most databases on the market today support SQL, and this allows us to (technically) interoperate between database vendors and communicate in a common language.
Interoperability requires tools that all do the same subset of functionality. The example that Eugene uses is that our PIM's generally offer the same basic functionality, but you currently cannot use the address book of one product and the date book of another. In order to do this, we would require components that offer similar functionality and a way to link this functionality together.
When people first think of interoperability, one of their first reactions is to use XML, and the interoperability issue is solved. The problem with this is that the focus point should not be the syntax, but rather the way to express the data and manipulate it. The goal of all XML (and SGML) was to express data as graphs (as demonstrated at the RDF Validator), however, if there were standard ways of manipulating graphs, this syntax would be irrelevant. Think about a problem such as 5 + 6; no matter how this problem is displayed syntactically, the answer will be 11, because we all know how to manipulate the data.
One argument against interoperability is that it is not marketable and not the developer's fault. I agree that it is not the developer's fault, because the developer generally builds what their organization desires. As for not being marketable, I would agree with Alan Cooper in that people do not necessarily know what computers can do, and usually are just happy that they do something. In Software Engineering courses, we learn that customer's communication with developers do not always list all requirements and everything that the software should do. These two aspects are probably why they are currently not marketable. Eugene's goal in his document was to bring awareness, and this is exactly what I see it doing; prior to the awareness of interface design, our user interfaces were in a horrible state. Hopefully Eugene's paper and others like it will influence interoperability as an important consideration of software development; besides his recipe on accomplishing interoperability is fairly simple.
If you spend any time at Eugene's web site, you will quickly notice that each paragraph has an identifier, allowing you to link directly to reference a specific paragraph. This ability is mentioned in the Manifesto, and this would definitely be useful for some blogging. The idea is to break complex documents into smaller pieces, depending on the domain. These smaller pieces, coupled with standard methods for manipulation become a language.
As an example of a common language, Eugene provides Engelbart's Backlinks idea, in which documents would know the other documents that refer to it, and he provides us with a few instances of this idea in our current environment which we may not think that they actually are the same, but the actually are. An obvious one is Google's use of a backlink count to a document to calculate its relevance, for example. The blogs are also backlinks in a different sense, however, a direct version of this is TrackBack's, which allow bloggers to know when other bloggers are referring to their entries, and Eugene believes that this could be standardized and used throughout the web. These two examples (and Eugene's other two examples) all share a common goal of seeing how people react to one's work.
In elaborating on the need for designing people centric software, Eugene indicates something new. People are quickly catching on the software usability and interactivity problem, and the problem here is not the lack of ideas on how to solve the interaction problems, but rather that many of the good ideas do not make it into software. There are many reasons for this, however, one interesting one that he mentions is that developers spend a lot of time reinventing the wheel. Instead, we should be reusing components, such as open source tools, such as Mozilla's XUL component for user interfaces.
The Semantic Web is attacked within this manifesto, indicating that although this provides a standard way to represent knowledge, it does not describe the intermediate step, which is how to convert our information to the Semantic Web. Attack is a little harsh; the point of his discussion, however, is that we have to think bigger than we currently are thinking. Interestingly enough, Michael Swaine's Programming Paradigms in the same issue1 also describes Kuro5hin.org's recent Prolog Introduction for Hackers, which compares RDF to Prolog's rules; this is one extremely powerful observation; just imagine this grand scale induction engine. Another recent use for RDF is for desktop data with the end goal of interoperability.
The issue that Eugene mentions on the Semantic Web is that we have problems communicating with each other, so how realistic is it that not only will humans benefit from it and computers. Even in Software Engineering: A Practitioner's Approach, Dr. Pressman states that SQA is done only because of people's inability to communicate and to perform with perfection. As with most topics, you can find people with varying opinions on that topic on the web, so with the above idea that the RDF is like a Prolog-rule, I think that this will quickly lead to inconsistent data, which we will have to deal with.
Eugene's recipe for getting there is fairly simple: be people centric, be willing to collaborate, create a shared language, and keep improving. Some people were a little disturbed by the lack of concrete examples, but the point of Eugene's manifesto is to get us thinking in the right direction, not dictating how to get there. The key is to be willing to collaborate, and once this occurs, more collaborative efforts can occur.
In The New Paradigm of Tools, Marc (Cantor?) discusses (amongst other very interesting things) how the number of truly ground-breaking software products has dropped down in the last year, and he argues that everything we need to be interoperable and collaborative has already been invented, and now it is the time to make it work together. So, let's start talking and putting it together!
[1] In the same article, Michael also talks about another book from 1962, The Structure of Scientific Revolutions by Thomas Kuhn, which Swaine's analysis is an expose of how scientists actually do science as opposed to how they think they do science.