Situating Cognition


0.01 2008-08-28 -17:28 -0700

My short title for these notes is now "Situating Cognition," since it is something we do.  In Understanding Computers and Cognition, Winograd and Flores identify some apparent errors in our naive approach to that [Winograd1986].  The authors have a caution against "situating," and I want to satisfy myself that I am not committing violence to a view of cognition and computing that I wish to speak consistently with.

I am also not sure about my direction here.  I think I need to stand back and take a simpler view.  The key thing is that, in my work on nfoWare and beyond, I want to speak of Situating Data, Situating XML, Situating Java, and maybe Situating Computation, but certainly Situating Trust.  The topics that I have identified here look at a progression that is important to me.  And it may not hold together that well.  Or, if it does, I may need to change the nomenclature I am using just the same.

By the way, beyond the title here, I am not going to get into Cognition very much, unless something in my review of notes returns me to that in section 4 or something beyond that.

-- Dennis E. Hamilton
Seattle, Washington
2004 January 11

1. Situating Computation

2. Computation in the World

3. Confirmable Experience 

4. Emergent and Resilient Computing


End Notes

1. Situating Computation

By "situating" I mean placing in context.  I also mean grounding in some way.   

In Understanding Computers and Cognition, there are cautions about using "situation" as an activity-oriented location.  I am uncomfortable with suggesting that I can distinguish computation.

1.1 Why "Situating?"

On May 29, 2003, I began something I had always meant to do:   learn Java.  My prior experience was limited to "Hello, World" in Microsoft Visual J++.  I knew Java was the latest thing, and had become the academic-instruction programming language of choice.  So, instead of studying Object-Oriented Programming in C++, about which I already knew more than I needed, I used the occasion to elect Object-Oriented Programming in Java for my M.Sc in IT programming requirement.

It did not take me long to become moderately frustrated while also excited to begin to see how Java works and what the underlying model of Java Object Oriented Technology is.  So, I began to have fun and also be dismayed about how "unsituated" the treatment of Java is in particular and instruction about programming is in general.  

I took this as an opportunity for me to contribute something.  It seems to me that we somehow skip a step and burden the Java neophyte with an absence of grounding (as if OOT excuses us from having to do that), and the result is even more confusing than use of conventional simpler languages (such as C).

Although I had wanted to call what I created "Java Inside Out," that family of titles is already over-used.  "Situating Java" was my second choice, but it grew on me.

1.2 Situating Meaning

On August 7, 2003, I began something else I had been meaning to do: dig into the full array of XML specifications.  I did that by electing the new Web Applications module as part of my M.Sc in IT studies.

I wasn't far into this module when I realized that the situation of XML was perhaps even more important than situating of Java.  First, they are both alleged to rely on Unicode.  Secondly, the futures of XML and Java application are heavily intertwined in the Web Services area.  And, somewhere, the conceits that XML is (1) self-describing and (2) conveys meaning, are bought into without questioning.  (I have also used "self-describing" in ways that I now see as ridiculous.)

There were even more startling observations, having to do with the assumption that the syntax (or signature) of an interface is sufficient to define an API.  And then there is the "Semantic Web."  

I had already been reading [Winograd1986], so it was natural to add "Situating XML" to my job jar of projects.

1.3 Situating Data

In a way, much of what there is to say about how XML relates to meaning is about how data and digital media have anything to do with language.  I already knew that the way that columns are named in relational-database tables is not exactly self-describing or even adequately descriptive.  Put simply, the computer (or RDBMS) doesn't know what we are talking about and it is not clear that we do either.  

Nevertheless, on October 16, 2003 I began a course on Databases as one of my M.Sc in IT required courses.  It was predictable that I would run into problems of semantics and situation of meaning here as well.  I found database systems to be surprisingly undisciplined and incoherent.  That is not a project that I want to take on.  I did have the pleasure of digging out E. F. Codd's foundational papers on relational database systems.  But I am going to situate data at a level that supports XML and programming systems (and database systems) without taking on the problem of what data the data in a RDBMS "is," "represents" or otherwise signifies.  That's just too much.  I may have to say something about it, but not yet.  Meanwhile, I have Bill Kent's Data and Reality, and that will be helpful.

1.4 Situating Considered Harmful

Now, what to do about the cautionary aspect of "situation" in Understanding Computers and Cognition?

1. The pitfall appears to be in the assumption that there are objectively-classifiable situations in the world [Winograd1986: 5.5 p.69].  

2. See if how I am using "situating" is useful or not.

3. Then use it anyhow, with a promise to be careful and attentive.


[clean these up: The Winograd ones are now also in bibliographies, and the Devlin one should be added to a bibliography.]

Devlin, Keith.  Extending Barwise and Perry's Relational Theory of Meaning.  CSLI, Stanford University (March 2003).  PDF available on the web at <>
Winograd, Terry. Moving the semantic fulcrum.  Linguistics and Philosophy 8, 1 (1985), 91-104.
Winograd, Terry., Flores, Fernando.  Understanding Computers and Cognition: A New Foundation for Design.  Addison-Wesley (Reading, MA: 1986, 1987).  ISBN 0-201-11297-3 pbk.
Winograd, Terry.  Is Realism for Real? A Response to John Perry's seminar.  CSLI Monthly 2, 5 (February 1987).

End Notes

This is just a sophisticated name for loose clipping from my bibliographic entry that I want to reduce and expand in the body of this note.  Then I suspect the end notes may disappear, but maybe not, because I like to retain historical connections.  (They can always go in a supporting page.  I will work that out later.

     [dh:2002-12-02] I have been reading of professional development and preparing to participate in an on-line M.Sc program.  We are using computer-mediated communication in an asynchronous learning model.  In looking at how we might develop collaboration, I was reminded of recent articles by Peter Denning and that brought me back here.  
     "We conclude here by pointing out that computer tools themselves are only part of the picture.  The gain from applying conversation theory in organizations has to do with developing the communicative competence, norms, and rules for the organization, including the training to develop the appropriate understanding.  This includes the proper terminology, skills, and procedures to recognize what is missing, deteriorated, or obtruding (i.e., what is broken-down), and the ability to cope with the situation." -- p.162, section 11.5, Tools for Conversation.
     I take it that we might refer to "community of practice" in this context.  The authors seem to go far beyond the establishment of a craft, however, continuing to say: "People have experience in everyday dealing with others and with situations.  Nevertheless, there are different levels of competence.  Competence here does not mean correct grammatical usage or diction, but successful dealing with the world, good managerial abilities, and responsibility and care for others.  Communicative competence means the capacity to express one's intentions and take responsibilities in the networks of commitments that utterances and their interpretations bring to the world.  In their day-to-day being, people are generally not aware of what they are doing.  They are simply working, speaking, etc., more or less blind to the pervasiveness of the essential dimensions of commitment.  Consequently, there exists a domain for education in communicative competence: the fundamental relationship between language and successful action.  People's conscious knowledge of their participation in the network of commitment can be reinforced and developed, improving their capacity to act in the domain of language." --p.162, section 11.5, Tools for Conversation.
     [dh:2003-08-04] I was reading one more inspiring article by Peter Denning, who refers to this material and related work in his "The Profession of IT" column in Communications of the ACM.  I started browsing in Chapter 12 and I was enthralled by the view of design enough to promise myself to read the book all the way through.   I found one of the cleanest popular expositions of ideas about existence in language and a wonderful description of the confluence of principles identified by Heidegger, Austin, and Maturana.  I have been pondering how to approach situating computing and dealing with what it is we are doing with computers and how that relates to language and who we are with language.  I see much that can be used in the calibration of my efforts, especially in being careful not to make over-reaching claims or interpretations of what is accomplished in proposing to situate computing.  (It is basically about having a disciplined way to look at what it is we are computing for as well as what the mechanisms, processes, and instruments of the activity are -- appropriately distinguished and qualified.)
     Although I have much to digest and review (witnessed by all of the colorful post-its flowering from the margins of my copy), I do notice that there are a couple of positions taken that I am hesitant to concede have been fully demonstrated, though I have no idea what would constitute such a demonstration.  The following seems crucial: "A computer can never enter into a commitment (although it can be a medium in which the commitments of its designers are conveyed), and can never enter as a participant into the domain of human discourse. ... Even the ability to utter a 'true statement' emerges from the potential for commitment, and the absence of this potential gives computers a wholly different kind of being." (8.5: p.106).  This is predicated on the notion that computers "are incapable of making commitments and cannot themselves enter into language." (6.4, p.76).  It is difficult for me to imagine exactly how one could establish being for a computing system in a way where this was possible, but I don't see the basis for "never" here.  I will continue my exploration.
     However I become satisfied about that question, the value of this book for me is unquestionable.  In particular, I can see the power of this perspective in addressing what it is we can do well with computers and how to demonstrate when we have done that.

-- Dennis E. Hamilton
2003 August 4


0.01 2003-12-20 Consolidate Notes on the Book (orcmid)
I have made a complete reading of the book, finding that it has pertinence to my ideas about confirmable experience and coherence as well.  I will now see how to organize all of my Post Its here.
0.00 2003-08-04 Initiate Separate Notes (orcmid)
I moved my lengthy annotations to here, in preparation for gathering more notes on the text as I work through the final two chapters.  This is highly unstructured and a placeholder that allows me to simplify the annotation in the bibliographic entry.
Hard Hat Area You are navigating Orcmid's Lair

created 2003-08-04-14:21 -0700 (pdt) by orcmid
$$Author: Orcmid $
$$Date: 13-08-22 13:02 $
$$Revision: 25 $