Gregg,

In case I'm wrong and you are not so Cognitively Simple that you have lost all curiosity about things outside your immediate awareness, here is a gift for you:

Beyond the Repertory Grid: New Approaches to Constructivist Knowledge Acquisition Tool Development

Jeffrey M. Bradshaw Computer Science, Research and Technology, Boeing Computer Services Seattle, Washington 98124 USA

Kenneth M. Ford Institute for Human & Machine Cognition, University of West Florida, Pensacola, Florida 32514 USA

Jack R. Adams-Webber Department of Psychology, Brock University, St. Catharines, Ontario, Canada L2S 3A1

John H. Boose Computer Science, Research and Technology, Boeing Computer Services Seattle, Washington 98124 USA

Abstract

Personal construct theory provides both a plausible theoretical foundation for knowledge acquisition and a practical approach to modeling. Yet, only a fraction of the ideas latent in this theory have been tapped. Recently, several researchers have been taking a second look at the theory, to discover new ways that it can shed light on the foundations and practice of knowledge acquisition. These efforts have led to the development of three "second-generation" constructivist knowledge acquisition systems: DDUCKS, ICONKAT, and KSSn/KRS. These tools extend repertory grid techniques in various ways and integrate them with tools springing from complementary perspectives. New understandings of relationships between personal construct theory, assimilation theory, logic, semantic networks, and decision analysis have formed the underpinnings of these systems. Theoretical progress has fostered practical development in system architecture, analysis and induction techniques, and group use of knowledge acquisition tools.

http://pages.cpsc.ucalgary.ca/~gaines/BooseBradshaw/BeyondtheRepGrid.doc

Gentleman Joker Joe

On 7/11/06, Joe Whitehurst <joewhitehurst@gmail.com> wrote: > Gregg, > > My master's thesis was about Cognitive Simplicity--Complexity ( a > measure completely orthogonal to measures of Intelligence) I > demonstrated that the proportion of sentences containing the identity > and predication forms of the verb to be in a large sample of writings > by college freshmen correlated highly with measures of Cognitive > Simplicity-Complexity derived from George Kelly's Role Construct > Repertory Grid test. The higher the proportion of sentences with > identity and predication forms of the verb to be the higher the > simplicity score (proportion of variance accounted for by the first > principal component). I've noticed that most of your postings have > a high proportion of sentences with the identity and predication forms > of the verb to be. The Cognitively Simple also tend to be visceral > reactors. I think I've got your number! To get a sense of the > meaning of the bipolar construct Cognitive Simplicity-Complexity > compare the The Blue Book of the John Birch Society (extreme end of > Cognitive Simplicity) and the US Constitution (extreme end of > Cognitive Complexity). > > Gentleman Joker Joe > . > > On 7/11/06, sas-l@datasavantconsulting.com > <sas-l@datasavantconsulting.com> wrote: > > SCL Joe, > > > > You are no gentleman. Not even by the most liberal stretch of the > > definition. You are, however, very much a 'turd'. At least as far as the > > term is defined by m-w.com in the 2nd instance: > > > > 2 usually vulgar : a contemptible person > > > > Peter and others, give it up! You can't polish a turd! > > > > Gregg Snell > > > > > > Original Message: > > ----------------- > > From: Joe Whitehurst joewhitehurst@GMAIL.COM > > Date: Tue, 11 Jul 2006 19:08:30 -0400 > > To: SAS-L@LISTSERV.UGA.EDU > > Subject: Re: Weekly SAS Tip Revival > > > > > > Peter, > > > > With respect to programming tools, I find the old nostrum about the > > right tool for the job to be empty of meaning. To be able to choose > > the best tool from among many or even two would seem to require > > intimate knowledge of both or all. What I see instead are choices > > made because that's all a given programmer knows. To use a programming > > language I think it reasonable to assume that a programmer must > > "know" the language to some degree. I think it is a rare programmer > > indeed who carefully examines all the tools available and then chooses > > the "right" one for the job. The pace of life from where I sit simply > > cannot permit such a luxury.. > > > > SAS has two very different system development tools--SAS/Base and > > SAS/AF. I believe that SAS Institute made a colossal marketing > > mistake when they initially (circa 1989) called the programming > > language in SAS/AF, Screen Control Language which led almost a > > generation of SAS users to assume that SCL was for interactive systems > > only. I am simply trying to raise consciousness in the world wide > > SAS community that SCL now called SAS Component Language (I would > > have called it SAS Control Language) is designed for _all_ (batch and > > interactive) SAS system development and possesses features which > > clearly make it.superior to SAS/Base with the Macro Language for > > systems development including a whole system debugger, a source > > control facility, a detailed performance measuring tool which > > measures performance down to the resource utilisation of individual > > statements and functions and a syntax almost exactly like the datastep > > language which makes the transition from datastep programming to SAS > > Component Language programming a matter of 3 to 5 days of the right > > kind of training. More later... > > > > Gentleman Joe Joker > > > > > > On 7/11/06, Peter Crawford <peter.crawford@blueyonder.co.uk> wrote: > > > so Joe, > > > it seems you are adding to the proverbial world of > > > > > > "do as I say - not as I do" > > > > > > or "rules for you - that I need not follow" > > > > > > "there are more messages to follow that make it all clear" > > > > > > surely that is not a strong foundation for any message ? > > > > > > Can the message be paraphrased > > > after learning base SAS, > > > before learning SAS macros > > > the would-be senior-programmer/developer should learn > > > and appreciate SAS/SCL > > > ? > > > > > > I learned the hard way, to protect the points of my chisels > > > and screwdrivers, from abuse. Unfortunately they were not > > > hard enough for the abuse they suffered as I learned ;-) > > > > > > The right tools make a task simpler to maintain and use. > > > If SAS/SCL is the right tool, we should use it. If we don't > > > have SAS/SCL available should we not even attempt a solution? > > > > > > Sometimes we might be able to justify using macros. > > > I offered some concepts for programmers new to macros, in > > > a paper at http://www2.sas.com/proceedings/sugi31/038-31.pdf > > > The macro is so small it might be hard to replicate in SCL, > > > but it is very functional. > > > > > > each to his own, surely ? > > > > > > Peter > > > > > > > > > On Tue, 11 Jul 2006 16:50:45 -0400, Joe Whitehurst > > > <joewhitehurst@GMAIL.COM> wrote: > > > > > > >Peter, > > > > > > > >The simple answer is no. But, I cannot say everything at once so I'm > > > >guilty of focusing on what is most salient. Saying is serial > > > >behavior. I eagerly await the invention of hyper-speech! > > > > > > > >Joe > > > > > > > >On 7/11/06, Peter Crawford <peter.crawford@blueyonder.co.uk> wrote: > > > >> Joe > > > >> > > > >> without getting covered in the proverbial cloud of words, may I query > > > >> something that you seem to "truly" believe. > > > >> I disagree that scl always provides a superior solution > > > >> to a well designed macro. > > > >> Or is this not what you try to say? > > > >> > > > >> > > > >> Peter > > > >> > > > > > > > > > -------------------------------------------------------------------- > > mail2web - Check your email from the web at > > http://mail2web.com/ . > > >