Human communication has context, session, and state. All
the social negotiating and fluff conversation is simply
setting the context. Once all the stupid hellos and
introductions and descriptions have been given, you have
the ability to actually communicate (or in Rohit's case,
finish up your watered down call scotch on the rocks and
move on down to the next bar stool as there's a null
intersection between attributes of human communications and
the social life of a Newport debutante). Next time you see
that person, you also have a shared, common understanding
about what you can and can't talk about. Finally,
you say your goodbyes, sometimes amicably, sometimes not,
but usually to the agreement of both.
I have this theory that organizations are like people. They
are groups of people behaving as a single entity, sometimes
the right hand not knowing what the left is doing, but all
mixed up with technology and communications channels and
organizational memory.
If you think about the steps to actually communicate ideas
to another person with the steps to actually communicate,
collaborate, coordinate, and complete work between organizations,
the steps are very similar. I also assert that just having
the data isn't enough to accomplish work/communications/collaboration.
I would like to see the WWW evolve from a data-sharing, data-centric,
data-oriented infrastructure to something a little more proactive,
reactive, assertive, task-oriented. Basically something that
includes behavior that you (being the technical programmer,
manager, non-technial end-user) can describe, share, visualize,
distributed, dynamically change, and interconnect. Not just data.
In the true theory of never typing something in that you can
cut and paste, this is from a paper that will never get published
in this form, but it emobdies the above ideas (full text at
http://gbolcer.ics.uci.edu/papers/cobbler.html).
<snip>
While the number of WWW users has increased significantly,
collaboration between distributed users is limited because the complex
workflow processes, i.e., the control and coordination policies,
remain difficult to specify or establish. In order to participate in
these processes, stakeholders not only need to exchange data ,
they need to negotiate the policies governing their collaboration. This
requires a task-oriented view rather than a data-oriented view. The
series of steps for two or more people, workgroups, or companies
to collaborate on a project using the WWW are 1) matching of
resources and people at the appropriate level and negotiating their
roles, 2) formation of constraints, responsibilities, deliverables,
and plans, 3) execution of the process including scheduling, handoff,
and sharing of data, and 4) establishing completion criteria. Augmenting
the data-oriented view of the WWW with this task-oriented view
can be accomplished by building atop the WWW infrastructure and
tools....
Collaboration
steps Data Oriented Task Oriented
===================================================================
Matching Content based search tools Behavior based search tools;
Evaluate usability and Eval based on tools that can
closeness od data and formats; produce, consume, manipulate, or
Implicit access control, translate format; explicit ACL,
readability. changeability, permissions.
Formation Agree on data formats Agree on use of compatible tools
Rely on standard content Responsibilities and actions
handlers; data owned by defined; ownerships of data is
residing server. independent of location.
Execution Updates or completion by Broadcast, synchronizations,
polling; Email used for CSCW; Scheduling, controlled info
announcements and notification sharing
Completion Each HTTP request independent Each HTTP request is part of
an overall task where the
the task can be applied or
revoked as a transaction.
Matching. "Who do I need to talk to in order to get this changed?" or
"Am I talking to the right
person?" are the first steps in matching the participants in a
collaboration process. In most cases, the
correct matching of collaborators does not occur with the first contact.
Simply identifying the data to
be changed isn't sufficient, even if the data is in an agreed-upon
format. In a task-oriented view of
the WWW, matching is augmented by examination of participant-specific
tool capabilities,
permissions, roles, and behaviors. Tools and individuals can be matched
by their functionality, not
just the data-formats they recognize.
Formation. Once the participants have been identified, agreements must
be made on interchange
formats and interaction protocols. As the WWW currently exists,
participants depend upon standard
content handlers at the distributed sites, and coordination is
determined simply by ownership of the
latest version, as determined by the server on which it resides. With a
task-oriented view, the
ownership of data can be defined independently of its location.
Participants may define the expected
responsibilities, which actions should be allowed or restricted, and
which tools should be employed.
Execution. Once the responsibilities have been divided up, the creation
and handoff of artifacts such
as documents or source code can commence. In the data-oriented view
completion of an activity is
usually indicated by the existence of a new link or creation of a new
artifact. Other sites obtain status
information by polling for the existence or checking the date of the
link; they become entangled in a
"keep checking back" syndrome. Notification usually occurs outside of
the WWW through
announcements to specific participants using e-mail. With notification
support built into the web, as
discussed above, an event-driven, task-oriented model is possible, in
which participants can be
notified directly of key project events, as needed and when appropriate.
Similar to how some
Computer Supported Cooperative Work systems allow controlled exchanges
by "granting the floor"
to the current speaker, such events could be broadcast, synchronized,
and scheduled in order to create
policies for controlled information sharing between distributed sites.
Completion. HTTP requests are normally performed as individual actions.
Since HTTP is a stateless
protocol, there is no current support for considering a group of related
actions as a single task.
However, many software engineering activities require changes to
multiple resources to occur
atomically (i.e. as transactions), at least from the point of view of
users of those resources. None of
the changes should be applied if any fail. In order to provide support
for transactions, it may be
necessary to establish a completion criterion or agreement between
client and server such that a group
of HTTP requests can be applied in isolation and only committed when
both sides agree.
</snip>
Wow, communication takes a lot of work.
> classical definition). That is why it needs to be modeled by object
> systems (or is that vice versa).
So, the questions is, are current object models semantically
sufficient for modeling human behaviors? I know my answer to the
question and it's related to the same lackilities as other
things that aren't 'Internet Scale'.
Greg
>
> Life, of course, is about behavior (reproduction & growth being the
> classical definition). That is why it needs to be modeled by object
> systems (or is that vice versa).
>
> Bosons and Fermions, if you will.
>
> -- Ernie P.
>