More steam in the engine again...
After going away and thinking some more, I latched on to this issue from my earlier post below:
>And in asking that question, one then has to return to the question of whether there can be a >generalisation over the relationship between knowledge workers and the knowledge in the >collaboration funds?
I suggest:
General types of knowledge or general modes of knowledge activity--
What/Where? --- Implemented as effective search and retrieval, possibly topic maps (but more on this below), &c. Scoping matters.
How & In What Order? --- Here I think of Linux HOW-TO databases, but with greater structure and better nesting/ordering of related tasks (job for creation by ZigZagging methinks). E.g. Query: "If I am at A and I want to achieve F, what do I do?" And the system works out the ordering of subtasks for me. Note the relationship between this and 'What/Where?'
Then I would add to those more refined activities required in the mode of collaboration:
Background/Foundation Information/Knowledge Collection + all their connections. The starting point of a project. (But needs to be tractable so what is the cut-off point e.g. for a complexity theorist?).
Addition/Removal/Edit + Consequences
History -- Where we are at & How we got here from there.
No doubt there are others that I can't think of right now.
So, ditching dreams of huge AI brains that can do it all for me and sticking to the real world, where does this analysis get me? The following is a strictly personal vision, and probably Doug Englebart has said/built all this before a few thousand times.
I go into work, and switch on my comp. My desktop comes up. I run my augmentor. There are folders corresponding to projects and I can take various views of any connections (people, events, news, decisions, topics) between these projects at this high level diagrammatically. Any member of any projects has a similar view on their desktop -- perhaps governed by some permissions systems.
I open a folder. Which folder I open is a matter for my own time management. Different agents have run behind the scenes to dredge up matters relating to projects ((people, events, news, decisions, topics) with suitable distinctions for intranet, extranet, and Internet derived information). These connections are then displayed, again diagrammatically, with views for timeline, human relations, skill patterns, requirements, HOW-TO, dialogues, decisions, etc., and I can edit in or out connections according to relevance (but only in the way I might take a class out of a particular compile, whilst not deleting entirely from my code repository). Depending on what I am looking at or pointing at in a given view it should be possible to fire up a relevant tool with a single click to make a change. Context is crucial. If I choose I can run the change as a scenario, like in Jack Park's Scholar's Companion (forthcoming) so that I am alerted to consequences. If approved the change is echoed to all others in the project with relevant permissions that need to know.
I should also be able to choose modes of collaboration, like "let's all scribble on the digital sketchpad at once".
Project administrator designates could choose to admit a person in a certain manner (e.g. read-only, or independent-post-but-not-edit and so forth).
Clearly the 'views' in there is where it all goes rather foggy. So work needs to be put in there.
Now, about topic maps and virtual filesystems...
ISO 13250 Topic Maps sprang out of Conventions for the Application of HyTime (CApH). So it would not surprise me if topic maps were intended to sit in the layer above groves. I.e. topic maps used to address points in groves, not the actual resources direct. It has troubled me for some time that the relationship between the conceptual graph and the resource indicators in topic maps is both underspecified within the structure of a topic, imho, and so strong within the processing model. It left no space for functional connections between these two layers. But what if your occurrence was a function to a set of points in a grove -- what power! But this is akin to putting, say, Prolog over the top of HyTime groves -- is there anything in the TM spec that says you have to use a dedicated TM engine?
For me though, the relationship between the topic map data, and what an inference engine could do in that position is not clear (yet). Perhaps Steve Newcomb is grinning while he reads this because he already knows in detail.
It is a platitude to say that the key to all this is the management of interactions between data sets along different vectors. Smells like rule sets to me.
So what are the data sets? What are the vectors?
Time to hunt down studies of actual IT collaborations. Have there been any posted to this list already before my time here?
HTH,
Peter
----- Original Message -----
From: archaon
To: unrev-II@yahoogroups.com
Sent: Saturday, May 26, 2001 1:24 PM
Subject: Re: [unrev-II] Ubiquitous Collaboration
Hi Lee,
Your text is interesting & reads well.
As someone who has unfortunately recently had to leave a zone of collaboration (employer) owing to illness (M.E.), naturally I am interested in a couple of issues that don't seem to be indicated in your text thus far (unless I've missed something - my powers of sustained concentration aren't that hot at present). I apologise for the following consisting more of questions than of answers.
I think there is an epistemological "hiatus" that exists between workers and the shared knowledge idea. So much of human capability, even in collaboration, is based on the individual's powers of memory, inquisitiveness, rate of information uptake, and acuity of reason (ignoring for the moment issues like moral character, which you raised in the issue of trust). There is also the matter of 'need to know' in its non-perjorative sense: I often don't need to know _everything_ my co-worker is thinking. This is not necessarily a bad thing, as sometimes specialisation in the pursuit of goals enables greater productivity for the team as a whole. So it becomes clear that 'role' and 'capability' are very important on the human side of the equation.
In the ideal open collaboration, the ideal democratic one, if you will, these ideas of role and capability are at a minimum of emphasis - they are utterly subordinate to the act of open collaboration. And often in such collaboration, the issues over which people collaborate are matters of mere debate - short and broad, like voting for a new law. Prior learning is perhaps not a great prerequisite, and minorities are less likely to suffer exclusion.
(Also, how do you enable those of lesser capability to collaborate? E.g. my memory isn't that hot right now either, but putting it all on hard disk somewhere still doesn't solve the problem that I can't find what I've forgotten, and it's no use just asking the system to remind me about everything. Or maybe I'm blind and I can only read as fast as the artificial voice on my system can read & talk.)
Other collaborations are much more focussed on particular results and require specialists who adopt quite fixed roles to accomplish the ends in the minimum time/cost. These collaborations are long and narrow, and a great deal of expertise and capability is required to fill any of the given roles in the team.
So the question arises, what sort of architectural approach do you take to cater for this spectrum of activity? Match the system to the task, or one-size fits all Procrustean special, or one basis that adapts to the circumstances of the users' activities - multiple and parallel as these might be?
And in asking that question, one then has to return to the question of whether there can be a generalisation over the relationship between knowledge workers and the knowledge in the collaboration funds? Does a fixed format for encapsulating knowledge nuggets cure all? Or is that just Procrustean again?
And that in turn takes you back to the Socratean question of "What is knowledge?". I read a pragmatic definition recently (possibly Peircean) that ran along the lines of, "useful stuff remembered." I think in that word 'useful' there is implicit the notion of constantly being able to re-query the base knowedge fund with different filters -- a notion that has arisen on this list once or twice since I began listening in. Let me add to that notion. I suggest that either the base knowledge fund or the result of a filtered query has to be coherent without eliminating pluralism of assertion.
Does pluralism require distribution of resources as a prerequisite? Which bits are non-monotonic and which aren't?
There's a lot hidden in that word 'coherent' too. Should the knowledge base control the coherence (with possibly inadequate approximations to human rational processes)? Or should people take the strain? What could a process of computer assistance look like for that?
Phew! I've run out of steam now.
I hope that wild splurge was useful.
atb,
Peter
----- Original Message -----
From: Lee Iverson
To: unrev-II@yahoogroups.com
Sent: Monday, May 21, 2001 9:34 PM
Subject: [unrev-II] Ubiquitous Collaboration
I'm in the process of putting together a White Paper, and as part of the
introduction I've written down a few thoughts about the background for
understanding and enabling ubiquitous collaboration.
I'm looking for some feedback on this, especially relevant history that
I may have missed or misstated and other barriers that people can think of.
Ill-formed or preliminary off-the-cuff responses are fine and
appropriate given that the source material is really of the same form at
this point.
Ubiquitous Collaboration
Collaboration systems have had an uneven relationship with the development of personal and interactive computing. Douglas Engelbart's Augmentation Research Center (ARC) at SRI International is perhaps most famous for developing the computer mouse. It was however a crucible for the evolution of computing and succeeded by developing and deploying the oNLine System (NLS), a computer system that implemented a fully interactive, collaborative, graphical computing and software development environment in the late sixties, an era when punched cards and batch processing were the state of the art for access to computing resources. The system embedded a completely shared working environment at its core so that anybody working on any part of the system was always collaborating with his/her colleagues, either actively or passively. It was a system of ubiquitous collaboration. His system and ideas catalysed a revolution in the development of computing environments and personal computing. Unfortunately, for many reasons both technical and social, much of the work of this group was either ignored or was transformed into forms that diminished the role of collaborative work, which was fundamentally at the core of Engelbart's goals.
In many ways, the system that halted Engelbart's collaborative enterprise was Email. While simply a small part of his system, it was delivered in a much simpler, more evolutionary fashion to the broad community of scientists working in the Arpanet environment. It presented a just good enough technology that was much more evolutionary than the radically revolutionary system Engelbart had assembled. Email became the killer app for the early Arpanet and is in some ways still the primary collaborative technology in wide deployment today.
The dream of ubiquitous collaboration still remains today, a fundamental part of what Engelbart has called his Unfinished Revolution. Engelbart was and is convinced that the only way to really tackle the most difficult basic problems that we are presented with as individuals, groups and societies is through a kind of teamwork in which the accumulated knowledge of the group is necessarily greater than that of any individual. An individual's role in the collective enterprise is then to augment the collective knowledge base by observation and synthesis. The networked computing environment that is now widely deployed with the Internet and World Wide Web is but one piece of the whole system needed to truly enable this collaborative knowledge development. Collaboration is currently a kind of afterthought with much knowledge work, with each individual locked in his or her own cubicle between group meetings, exchanging a few email messages when necessary.
We anticipate a work environment in which every person is organically connected to a team of common purpose no matter what they are doing or what software they might be using. An individual's thoughts, decisions and actions become amplified and enhanced by an automatic, seamless integration with the thoughts, decisions and actions of others. And the collective enterprise becomes centered on a deeply cross-linked repository of accumulated knowledge and action, which is completely open for exploitation and application to any new team activity. It is only with this kind of infrastructure in place that the true potential for radical enhancement of efficiency and productivity can be realized. This will only happen when the barriers to the accumulation of group knowledge and group processes are torn down.
Barriers
We need to understand those barriers then. There are clearly both technical and social barriers, with corporate and individual motivations interfering with collective work. In order to frame this analysis we will assume that the "worker" we will examine is someone Engelbart has called a "knowledge worker," someone whose job or avocation involves the exploitation, organization and production of knowledge. It is a class that includes virtually all white-collar workers and managers as well as reporters, researchers, and anyone doing any kind of paperwork. In many cases, we are talking about anyone who does or could use a computer for performing virtually any task.
A huge technical barrier is something I will call the tyranny of format, the fact that an enormous amount of what could be useful and reusable knowledge is trapped inside proprietary or inaccessible data formats. Much of this reality is driven by the fact that virtually every new application and new version of an application involves the creation of a new, incompatible data storage format. The barrier to sharing even the products of work, much less the process, becomes one of incompatibility of application formats.
Another problem is the disintegration of knowledge, in which the concentration of work on personal, loosely-networked computers with distinct data stores means that in many cases the vast preponderance of potentially exploitable team knowledge is distributed in a completely inaccessible way on tens or thousands of un-indexed and often inaccessible individual computers. Many large enterprises attempt to solve this problem with central data stores and shared filesystems to ensure that the products of work are centrally maintained and accessible. Unfortunately, these systems become mandated, imposed solutions that often do not significantly enhance the productivity of individual users. Networks are always slower and less reliable than local storage, so intermediate versions and temporary documents always stay on local disks. Moreover the means by which the central stores are organized are rarely appropriate or adaptable to the range of work that individuals need to perform, so the central store is almost always "for management" and not "for me."
We can identify another barrier as the transience of history, the loss of many of the most important pieces of collective knowledge to an unrecorded and imperfectly recalled past. Consider the ubiquity and importance of meetings in collective work, all the way from impromptu "water-cooler" meetings to brainstorming sessions to formal meetings. Every aspect of one of these meetings which goes unrecorded and thus unintegrated into a collective repository, is thus inaccessible to anyone but the participants. And even for the participants in these meetings, so much that is important to the development of ideas is often lost, with much of the process of producing good ideas and rejecting bad ones lost to the imperfect memories of only the direct participants. Even in situations which are completely computer-centered, the history of a document and the connection between email about a document and the document itself is often never collected or linked together and is thus inaccessible to future collaborators or just someone trying to reconstruct an argument.
Another barrier to the enhancement of collaboration that arises when considering meetings is the impermanence of passive knowledge, in which knowledge that is not actively and consciously integrated into the system is lost. Much of this can be considered to be knowledge of history, but in this case the emphasis is on the effort often required to ensure that useful dialogues and observations are actually recorded and integrated into a collective knowledge base in a useful way. It is often simple to record and store meetings either with a human note-taker or a digital recording, but without content-based retrieval mechanisms and means of exploiting these recordings and integrating them into the products that are being produced by the team it is of little advantage to do so.
A more social barrier is the failure of trust, the loss of motivation or interest in deep collaboration by the breakdown of social conventions that often accompany attempts at collaborative work, even within teams of common interest. Some of this breakdown comes from a kind of disconnection associated with certain forms of communication, such as email. We are all familiar with how easily perceived insults or real flames can cause irreparable rifts in relationships when email exchanges are part of the relationship. Another kind of problem is that the ease of copying and disguising of documents and the lack of adequate audit trails can obscure the actual relationships between documents and their key contributors and thus stand in the way of an individual's commitment the social contracts that lead to contributing to a collective endeavour.
If we are to propose a technical solution to these problems, it must address each of these technical barriers and provide some realization for the kinds of social support needed to overcome those barriers as well.
Community email addresses:
Post message: unrev-II@onelist.com
Subscribe: unrev-II-subscribe@onelist.com
Unsubscribe: unrev-II-unsubscribe@onelist.com
List owner: unrev-II-owner@onelist.com
Shortcut URL to this page:
http://www.onelist.com/community/unrev-II
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
Yahoo! Groups Sponsor
AdministrativeConstructionCustomer ServiceEngineeringFinancial ServicesHealth CareInformation TechnologyLegalMedia/Arts/DesignSales & MarketingScientific & Technical
Community email addresses:
Post message: unrev-II@onelist.com
Subscribe: unrev-II-subscribe@onelist.com
Unsubscribe: unrev-II-unsubscribe@onelist.com
List owner: unrev-II-owner@onelist.com
Shortcut URL to this page:
http://www.onelist.com/community/unrev-II
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
This archive was generated by hypermail 2b29 : Sat May 26 2001 - 17:00:30 PDT