![]() |
Bibliography
Readings/Notes |
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
References
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.
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.
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.
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.
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.]
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.
-- Dennis E. Hamilton
2003 August 4
![]() |
You are navigating Orcmid on GitHub |
created 2003-08-04T21:21Z by orcmid |