From owner-port-peer-review@bootstrap.org Tue Jul 2 06:14:15 2002 Return-Path: Delivered-To: port-peer-review-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 806CE56FFC; Tue, 2 Jul 2002 06:14:15 -0700 (PDT) Delivered-To: port-peer-review@bootstrap.org Received: from smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net [207.172.4.60]) by bi0.bootstrap.org (Postfix) with SMTP id CAB8656FFB for ; Tue, 2 Jul 2002 06:14:13 -0700 (PDT) Received: from 207-237-200-232.c3-0.23d-ubr1.nyr-23d.ny.cable.rcn.com ([207.237.200.232] helo=rcn.com) by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.35 #5) id 17PNkH-0005K4-00; Tue, 02 Jul 2002 09:31:05 -0400 Message-ID: <3D21AB09.5080804@rcn.com> Date: Tue, 02 Jul 2002 09:30:49 -0400 From: Gary Richmond User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: port-peer-review@bootstrap.org Subject: Re: [port-peer-review] reviews References: Content-Type: multipart/alternative; boundary="------------070408000201040406060205" Sender: owner-port-peer-review@bootstrap.org Precedence: bulk Reply-To: port-peer-review@bootstrap.org --------------070408000201040406060205 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit On6/26 Jun 2002,Aldo de Moor wrote in response to comments by Phillipe Martin: >The complexity of socio-technical system evolution is such that >methodological support is essential. Most methodologies, e.g. in knowledge >and requirements engineering, focus on the lowest levels (information >system, usage context). > It is apparently all too easy to forget the important distinction you made between TOOL and SYSTEM (in response to a comment on your paper by Janos Sarbo). The pragmatic principle and related notions like Doug Engelbart's of "improving on improvement" essentially require consideration at the meta-level. Peirce's pragmatism is, of course, not a tool, but a theory within the methodological part of his logic, "the highest and most living branch of logic." CP 2.333 (which at one point he interestingly refers to as "transuasional logic"). There seems a tendency to conflate the two, often reducing everything to tools and their use; or alternatively, finding this, and the other distinctions you made, mere "common knowledge" (though, of course, common knowledge itself needs to be criticized in a thorough-going pragmatism), rather than to see reflection at this level essential to the growth of collaborative communities. As you wrote: > Pragmatic approaches at the higher meta-levels >(design, improvement) that center on making efficient and effective >community-controlled systems evolution possible, hardly exist. Doug's work >is one of the few exceptions.[emphasis added] > And your work is another. In collaboratories generally, and certainly in a project such as PORT, meant to be pragmatic in the Peircean sense, that is, methodologically pragmatic, I would imagine that the process of "improving upon (systemic) improvement" could be seen as almost equivalent to pragmatic method put into practice by a community. It is, as you suggest, a matter of tools and the people developing and using them within interpenetrating systems and their contexts. There are real complexities here that are far from trivial. Further, this evolution ought not--if we really want to optimize community and inter-community collaboration as well as maximize the possibilities for evolutionary success in our endeavors--be left to chance, but should rather be guided by agreement on what would constitute the best methods employed at this level--in your sense of an interpenetration of contexts, the highest level of these entraining sub-systems to create a kind of system-of-systems. And this seems the thrust of Peirce's science: the fuller integration that quasi-necessarily follows from the generalization of methods (and findings) in each branch when guided by methodological consensus at the meta-level--your systems/contexts model--with the consequent improvement on improvement. . >This paper only introduces a (rudimentary) tool context model. It is not a >methodology in itself, but rather a meta-model that allows methodologies >to be positioned and compared. > In a brief paper I would think it would be difficult to present much more. Still, your paper seems to me to constitute something of a very general, though vague, blueprint of the kinds of distinctions that need be made and the relations between them. It is not a methodology in itself, for sure; but it is allied, as is Doug's fundamental notion, to the method of inquiry along Peircean pragmatic lines. In this context, it should be remember that while Peirce strictly excludes the socio-psychological from all his logical considerations, finally at the level of methodology he relaxes this stricture. He writes: > Peirce: CP .107. The regulation has served its end; why should it be > allowed now to hamper our endeavors to make methodeutic practically > useful? This making "practically useful" seems precisely the point of the PORT project. >>PM; Can any high-level methodology or set of "design principles" for >>"collaboratories" lead developpers to come up with new ideas, or ease the >>technical integration of already developped tools? >> > >AdM: The tool context model is a lens that allows one to focus on, literally, >the missing links between models and methodologies. By structuring 'common >content knowledge' it becomes possible to see the icebergs in the first >place, and to identify gaps in socio-technical methods for collaboratory >development. > I see your answer to Philippe's good question to be "yes." How could it be that improved communication at the design level would but help improve workflows, integrations of elements of projects, etc? And tools themselves could be expected to be developed with greater potential for integration following such systematic analysis applied to practice. It seems to me that such reflective structuring and restructuring would surely lead to increased creativity among tool developers and all others involved in collaboratories. > >Links increase complexity. Sometimes this is desired, for example when >linking processes from different levels (e.g. connecting a workflow >process to a design process, so that the workflow definition can evolve). >Sometimes, processes should not be linked too much. This could be the case >with two workflow processes. One such process (e.g. authoring process) can >feed into another (e.g. review process), but the inner workings of the >first process may need only to be a black box to the second process. > Your answer to Philippe's question regarding "links" suggests that this might become a crucial area for further inquiry at the meta-level. >I agree that the concept of 'link' needs to be further worked out. One >interesting issue would be a typology of links useful for collaboratory >evolution modelling. > The notion of a "typology of links" might be a fruitful topic for discussion at the ICCS PORT workshop. Regards, Gary Aldo de Moor wrote: >Dear Philippe, > >On Wed, 19 Jun 2002, Philippe Martin wrote: > >>Review 2 >>-------- >> >>Paper's title: Making Doug's Dream Come True: Collaboratories in Context >> >>Paper's author: Aldo De Moor >> >>Summary. The author claims that a high-level design approach (or >>"framework", or set of "design principles") such as Douglas Engelbart's >>is needed to design and integrate collaborative tools. Some distinctions >>(design principles?) are presented, and then used to present a few >>requirements for PORT. >> >>Clarity and precision. I do not know any precise, clear and easily >>appliable framework/methodology, e.g. in software engineering, knowledge >>engineering, and that includes the one I developped for "explanation >>generation" (as an extension and application of KADS) during my Honours >>thesis. I do not think there is an escape to that. >> >> >>Originality. Other frameworks are not cited although I guess this one >>competes or is complementary to quite a few. >> > >The complexity of socio-technical system evolution is such that >methodological support is essential. Most methodologies, e.g. in knowledge >and requirements engineering, focus on the lowest levels (information >system, usage context). Pragmatic approaches at the higher meta-levels >(design, improvement) that center on making efficient and effective >community-controlled systems evolution possible, hardly exist. Doug's work >is one of the few exceptions. > >>Interest of the approach. I am not convinced the few very general >>distinctions presented in the article are really guiding. Was the author >>guided by them to come up with the content (not the presentation) of his >>few notes on PORT? Wasn't this content already common knowledge and only >>a glimpse of the tip of the iceberg of the actually needed requirements? >> > >This paper only introduces a (rudimentary) tool context model. It is not a >methodology in itself, but rather a meta-model that allows methodologies >to be positioned and compared. > >>Ok, these notes are examples only but important requirements such as >>lexical/structural/semantic/ontological conventions (e.g. such as those >>I presented at ICCS'00) are not mentionned, nor is the need for >>knowledge-based cooperation protocols (asynchronous such as those in >>WebKB-2 or CO4, or synchronous shuch as those in Tadzebao and >>WebOnto). >> > >These are absolutely necessary, but not sufficient, as is also the gist of >Chris's replies to you, I believe. They could be positioned in the lower >context model layers, for example in defining tool interface and >integration properties. > >>Can any high-level methodology or set of "design principles" for >>"collaboratories" lead developpers to come up with new ideas, or ease the >>technical integration of already developped tools? >> > >The tool context model is a lens that allows one to focus on, literally, >the missing links between models and methodologies. By structuring 'common >content knowledge' it becomes possible to see the icebergs in the first >place, and to identify gaps in socio-technical methods for collaboratory >development. > >>Miscellaneous. Assuming that "links" do not impose constraints but only >>bring more information that may be exploited if necessary, I do not >>understand the last part of the second sentence in the following quote: >>"The more system processes are linked, the higher the level of >>integration. In some cases, a high level of integration may be >>desirable, whereas in other cases, having loosely coupled processes may >>be more useful." >>http://lab.bootstrap.org/port/papers/2002/demoor.html#nid021 >> > >Links increase complexity. Sometimes this is desired, for example when >linking processes from different levels (e.g. connecting a workflow >process to a design process, so that the workflow definition can evolve). >Sometimes, processes should not be linked too much. This could be the case >with two workflow processes. One such process (e.g. authoring process) can >feed into another (e.g. review process), but the inner workings of the >first process may need only to be a black box to the second process. > >I agree that the concept of 'link' needs to be further worked out. One >interesting issue would be a typology of links useful for collaboratory >evolution modelling. > >Aldo > >========================================================================== > ---/// e-mail: ademoor@kub.nl >IN|F/OLAB phone +31-13-4662914/ > > > >30 > >20, fax +31-13-4663069 > |/// home page: http://infolab.kub.nl/people/ademoor > >Dr. Aldo de Moor >Infolab, Dept. of Information Management - Tilburg University >PO Box 90153, 5000 LE Tilburg, The Netherlands >========================================================================== > > > > --------------070408000201040406060205 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
On 6/26 Jun 2002, Aldo de Moor wrote in response to comments by Phillipe Martin:
The complexity of socio-technical system evolution is such that
methodological support is essential. Most methodologies, e.g. in knowledge
and requirements engineering, focus on the lowest levels (information
system, usage context).
It is apparently all too easy to forget the  important distinction you made between TOOL and SYSTEM (in response to a comment on your paper by Janos Sarbo). The pragmatic principle and related notions like Doug Engelbart's of "improving on improvement" essentially require consideration at the meta-level.  Peirce's pragmatism is, of course, not a tool, but a theory within the methodological part of his logic, "the highest and most living branch of logic." CP 2.333 (which at one point he interestingly refers to as "transuasional logic"). There seems a tendency to conflate the two, often reducing everything to tools and their use; or alternatively, finding this, and the other distinctions you made, mere "common knowledge" (though, of course, common knowledge itself needs to be criticized in a thorough-going pragmatism), rather than to see reflection at this level  essential to the growth of collaborative communities.

As you wrote:
 Pragmatic approaches at the higher meta-levels
(design, improvement) that center on making efficient and effective
community-controlled systems evolution possible, hardly exist. Doug's work
is one of the few exceptions. 
[emphasis added]
And your work is another.  In  collaboratories generally, and certainly in a  project such as PORT,  meant to be pragmatic in the Peircean sense, that is, methodologically pragmatic, I would imagine that the process of  "improving upon (systemic) improvement" could be seen as almost equivalent to pragmatic method put into practice by a community. It is, as you suggest, a matter of tools and the people developing and using them within interpenetrating systems and their contexts. There are real complexities here that are far from trivial.

Further, this evolution ought not--if we really want to optimize community and inter-community collaboration as well as maximize the possibilities for evolutionary success in our endeavors--be left to chance, but should rather be guided by agreement on what would constitute the best methods employed at this level--in your sense of an interpenetration of contexts, the highest level of these entraining sub-systems to create a kind of system-of-systems.  And  this seems the thrust of Peirce's science: the fuller integration that quasi-necessarily follows from the generalization of methods (and findings) in each branch when guided by methodological consensus at the meta-level--your systems/contexts model--with the consequent improvement on improvement. .
This paper only introduces a (rudimentary) tool context model. It is not a
methodology in itself, but rather a meta-model that allows methodologies
to be positioned and compared.
In  a brief paper I would think it would be difficult to present much more. Still, your paper seems to me to constitute something of a very general, though vague, blueprint of the kinds of distinctions that need be made and the relations between them. It is not a methodology in itself, for sure; but it is allied, as is Doug's fundamental notion, to the method of inquiry along Peircean pragmatic lines. In this context, it should be remember that while Peirce strictly excludes the socio-psychological from all his logical considerations, finally at the level of methodology he relaxes this stricture. He writes:
Peirce: CP .107. The regulation has served its end; why should it be allowed now to hamper our endeavors to make methodeutic practically useful?
This making "practically useful" seems precisely the point of the PORT project.
PM; Can any high-level methodology or set of "design principles" for
"collaboratories" lead developpers to come up with new ideas, or ease the
technical integration of already developped tools?

AdM: The tool context model is a lens that allows one to focus on, literally,
the missing links between models and methodologies. By structuring 'common
content knowledge' it becomes possible to see the icebergs in the first
place, and to identify gaps in socio-technical methods for collaboratory
development.
I see your answer to Philippe's good question to be  "yes."  How could it be that improved communication at the design level would but help improve workflows, integrations of elements of projects, etc? And tools themselves could be expected to be developed with greater potential for integration following such systematic analysis applied to practice. It seems to me that such reflective structuring and restructuring would surely lead to increased creativity among tool developers and all others involved in collaboratories.

Links increase complexity. Sometimes this is desired, for example when
linking processes from different levels (e.g. connecting a workflow
process to a design process, so that the workflow definition can evolve).
Sometimes, processes should not be linked too much. This could be the case
with two workflow processes. One such process (e.g. authoring process) can
feed into another (e.g. review process), but the inner workings of the
first process may need only to be a black box to the second process.
Your answer to Philippe's question regarding "links"  suggests that this might become a crucial area for further inquiry at the meta-level. 
I agree that the concept of 'link' needs to be further worked out. One
interesting issue would be a typology of links useful for collaboratory
evolution modelling.
The notion of a "typology of links" might be a fruitful topic for discussion at the ICCS PORT workshop.

Regards,

Gary




Aldo de Moor wrote:
Dear Philippe,

On Wed, 19 Jun 2002, Philippe Martin wrote:

Review 2
--------

Paper's title: Making Doug's Dream Come True: Collaboratories in Context

Paper's author: Aldo De Moor

Summary. The author claims that a high-level design approach (or
"framework", or set of "design principles") such as Douglas Engelbart's
is needed to design and integrate collaborative tools. Some distinctions
(design principles?) are presented, and then used to present a few
requirements for PORT.

Clarity and precision. I do not know any precise, clear and easily
appliable framework/methodology, e.g. in software engineering, knowledge
engineering, and that includes the one I developped for "explanation
generation" (as an extension and application of KADS) during my Honours
thesis. I do not think there is an escape to that.


Originality. Other frameworks are not cited although I guess this one
competes or is complementary to quite a few.

The complexity of socio-technical system evolution is such that
methodological support is essential. Most methodologies, e.g. in knowledge
and requirements engineering, focus on the lowest levels (information
system, usage context). Pragmatic approaches at the higher meta-levels
(design, improvement) that center on making efficient and effective
community-controlled systems evolution possible, hardly exist. Doug's work
is one of the few exceptions.

Interest of the approach. I am not convinced the few very general
distinctions presented in the article are really guiding. Was the author
guided by them to come up with the content (not the presentation) of his
few notes on PORT? Wasn't this content already common knowledge and only
a glimpse of the tip of the iceberg of the actually needed requirements?

This paper only introduces a (rudimentary) tool context model. It is not a
methodology in itself, but rather a meta-model that allows methodologies
to be positioned and compared.

Ok, these notes are examples only but important requirements such as
lexical/structural/semantic/ontological conventions (e.g. such as those
I presented at ICCS'00) are not mentionned, nor is the need for
knowledge-based cooperation protocols (asynchronous such as those in
WebKB-2 or CO4, or synchronous shuch as those in Tadzebao and
WebOnto).

These are absolutely necessary, but not sufficient, as is also the gist of
Chris's replies to you, I believe. They could be positioned in the lower
context model layers, for example in defining tool interface and
integration properties.

Can any high-level methodology or set of "design principles" for
"collaboratories" lead developpers to come up with new ideas, or ease the
technical integration of already developped tools?

The tool context model is a lens that allows one to focus on, literally,
the missing links between models and methodologies. By structuring 'common
content knowledge' it becomes possible to see the icebergs in the first
place, and to identify gaps in socio-technical methods for collaboratory
development.

Miscellaneous. Assuming that "links" do not impose constraints but only
bring more information that may be exploited if necessary, I do not
understand the last part of the second sentence in the following quote:
"The more system processes are linked, the higher the level of
integration. In some cases, a high level of integration may be
desirable, whereas in other cases, having loosely coupled processes may
be more useful."
http://lab.bootstrap.org/port/papers/2002/demoor.html#nid021

Links increase complexity. Sometimes this is desired, for example when
linking processes from different levels (e.g. connecting a workflow
process to a design process, so that the workflow definition can evolve).
Sometimes, processes should not be linked too much. This could be the case
with two workflow processes. One such process (e.g. authoring process) can
feed into another (e.g. review process), but the inner workings of the
first process may need only to be a black box to the second process.

I agree that the concept of 'link' needs to be further worked out. One
interesting issue would be a typology of links useful for collaboratory
evolution modelling.

Aldo

==========================================================================
---/// e-mail: ademoor@kub.nl
IN|F/OLAB phone +31-13-4662914/ 30 20, fax +31-13-4663069
|/// home page: http://infolab.kub.nl/people/ademoor

Dr. Aldo de Moor
Infolab, Dept. of Information Management - Tilburg University
PO Box 90153, 5000 LE Tilburg, The Netherlands
==========================================================================











--------------070408000201040406060205-- From owner-port-peer-review@bootstrap.org Tue Jul 2 09:06:01 2002 Return-Path: Delivered-To: port-peer-review-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 4C79756FFE; Tue, 2 Jul 2002 09:06:01 -0700 (PDT) Delivered-To: port-peer-review@bootstrap.org Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.19]) by bi0.bootstrap.org (Postfix) with SMTP id E1D3256FFD for ; Tue, 2 Jul 2002 09:05:59 -0700 (PDT) Received: from mailscan-out3.cac.washington.edu (mailscan-out3.cac.washington.edu [140.142.32.18]) by mxout3.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.06) with SMTP id g62GMsYu028242 for ; Tue, 2 Jul 2002 09:22:54 -0700 Received: FROM mead2.u.washington.edu BY mailscan-out3.cac.washington.edu ; Tue Jul 02 09:22:53 2002 -0700 Received: from localhost (mkeeler@localhost) by mead2.u.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g62GMqBm097838 for ; Tue, 2 Jul 2002 09:22:53 -0700 Date: Tue, 2 Jul 2002 09:22:52 -0700 (PDT) From: Mary Keeler To: port-peer-review@bootstrap.org Subject: Re: [port-peer-review] reviews In-Reply-To: <3D21AB09.5080804@rcn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-port-peer-review@bootstrap.org Precedence: bulk Reply-To: port-peer-review@bootstrap.org Gary, what is the rest of the CP reference for the following quote you gave? --m. Peirce: CP .107. The regulation has served its end; why should it be allowed now to hamper our endeavors to make methodeutic practically useful? From owner-port-peer-review@bootstrap.org Tue Jul 2 09:33:59 2002 Return-Path: Delivered-To: port-peer-review-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id C124D56FFE; Tue, 2 Jul 2002 09:33:58 -0700 (PDT) Delivered-To: port-peer-review@bootstrap.org Received: from smtp01.mrf.mail.rcn.net (smtp01.mrf.mail.rcn.net [207.172.4.60]) by bi0.bootstrap.org (Postfix) with SMTP id BC3C856FFD for ; Tue, 2 Jul 2002 09:33:56 -0700 (PDT) Received: from 207-237-200-232.c3-0.23d-ubr1.nyr-23d.ny.cable.rcn.com ([207.237.200.232] helo=rcn.com) by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.35 #5) id 17PQrb-0007gj-00 for port-peer-review@bootstrap.org; Tue, 02 Jul 2002 12:50:51 -0400 Message-ID: <3D21D9E3.6020600@rcn.com> Date: Tue, 02 Jul 2002 12:50:43 -0400 From: Gary Richmond User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: port-peer-review@bootstrap.org Subject: Re: [port-peer-review] reviews References: Content-Type: multipart/alternative; boundary="------------030203080102020701040809" Sender: owner-port-peer-review@bootstrap.org Precedence: bulk Reply-To: port-peer-review@bootstrap.org --------------030203080102020701040809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Whoops. Left out the 2. Here's the whole except including 2.107 (my=20 emphasis) Peirce: CP 2.105 Cross-Ref:++ =A75. SPECULATIVE RHETORIC +1 105. All this brings us close to Methodeutic, or Speculative=20 Rhetoric. The practical want of a good treatment of this subject is=20 acute. It is not expected that any general doctrine shall teach men much = about methods of solving problems that are familiar to them. But in=20 problems a little remote from those to which they are accustomed, it is=20 remarkable how not merely common minds, but those of the very highest=20 order, stumble about helplessly. No class of thinkers can by anybody be=20 rated higher in heuretic genius than the mathematicians; and yet see how = they have boggled over comparatively simple problems of unfamiliar=20 kinds, such as Fermat's theorems, Steiner's theorems, the problem of=20 map-coloring, the theory of knots. Peirce: CP 2.106 Cross-Ref:++ 106. Many persons will think that there are other ways of acquiring=20 skill in the art of inquiry which will be more instructive than the=20 logical study of the theory of inquiry. That may be; I shall not dispute = it; for it would carry me far beyond the confines of my province. I only = claim that however much one may learn in other ways of the method of=20 attacking an unfamiliar problem, something may be added to that=20 knowledge by considering the general theory of how research must be=20 performed. At the same time, it is this theory itself, for itself, which = will here be the principal object. Peirce: CP 2.107 Cross-Ref:++ 107. In coming to Speculative Rhetoric, after the main conceptions=20 of logic have been well settled, there can be no serious objection to=20 relaxing the severity of our rule of excluding psychological matter,=20 observations of how we think, and the like. The regulation has served=20 its end; why should it be allowed now to hamper our endeavors to make=20 methodeutic practically useful? But while the justice of this must be=20 admitted, it is also to be borne in mind that there is a purely logical=20 doctrine of how discovery must take place, which, however great or=20 little is its importance, it is my plain task and duty here to explore.=20 In addition to this, there may be a psychological account of the matter, = of the utmost importance and ever so extensive. With this, it is not my=20 business here to meddle; although I may here and there make such use of=20 it as I can in aid of my own doctrine. Peirce: CP 2.108 Cross-Ref:++ 108. Time was when a theorem could constitute a considerable=20 contribution to mathematical science. But now new theorems are turned=20 out wholesale. A single treatise will contain hundreds of them. Nowadays = methods alone can arrest attention strongly; and these are coming in=20 such flocks that the next step will surely be to find a method of=20 discovering methods.+1 This can only come from a theory of the method of = discovery. In order to cover every possibility, this should be founded=20 on a general doctrine of methods of attaining purposes, in general; and=20 this, in turn, should spring from a still more general doctrine of the=20 nature of teleological action, in general.+2 Peirce: CP 2.109 Cross-Ref:++ 109. Although the number of works upon Methodeutic since Bacon's=20 Novum Organum has been large, none has been greatly illuminative.=20 Bacon's work was a total failure, eloquently pointing out some obvious=20 sources of error, and to some minds stimulating, but affording no real=20 help to an earnest inquirer. THE book on this subject remains to be=20 written; and what I am chiefly concerned to do is to make the writing of = it more possible. Peirce: CP 2.110 Cross-Ref:++ 110. I do not claim that the part of the present volume which deals=20 with Speculative Rhetoric will approach that ideal. As to the other=20 parts of my book, this prefatory chapter commits me to producing a work=20 of great importance or to being set down a drawler of nonsense. Mary Keeler wrote: >Gary, what is the rest of the CP reference for the following quote you >gave? --m. > >Peirce: CP .107. The regulation has served its end; why > should it be allowed now to hamper our endeavors to make > methodeutic practically useful? > > > > --------------030203080102020701040809 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Whoops. Left out the 2. Here's the whole except including 2.107 (my emphasis)

Peirce: CP 2.105 Cross-Ref:††
§5. SPECULATIVE RHETORIC †1

    105. All this brings us close to Methodeutic, or Speculative Rhetoric. The practical want of a good treatment of this subject is acute. It is not expected that any general doctrine shall teach men much about methods of solving problems that are familiar to them. But in problems a little remote from those to which they are accustomed, it is remarkable how not merely common minds, but those of the very highest order, stumble about helplessly. No class of thinkers can by anybody be rated higher in heuretic genius than the mathematicians; and yet see how they have boggled over comparatively simple problems of unfamiliar kinds, such as Fermat's theorems, Steiner's theorems, the problem of map-coloring, the theory of knots.
Peirce: CP 2.106 Cross-Ref:††
    106. Many persons will think that there are other ways of acquiring skill in the art of inquiry which will be more instructive than the logical study of the theory of inquiry. That may be; I shall not dispute it; for it would carry me far beyond the confines of my province. I only claim that however much one may learn in other ways of the method of attacking an unfamiliar problem, something may be added to that knowledge by considering the general theory of how research must be performed. At the same time, it is this theory itself, for itself, which will here be the principal object.
Peirce: CP 2.107 Cross-Ref:††
    107. In coming to Speculative Rhetoric, after the main conceptions of logic have been well settled, there can be no serious objection to relaxing the severity of our rule of excluding psychological matter, observations of how we think, and the like. The regulation has served its end; why should it be allowed now to hamper our endeavors to make methodeutic practically useful? But while the justice of this must be admitted, it is also to be borne in mind that there is a purely logical doctrine of how discovery must take place, which, however great or little is its importance, it is my plain task and duty here to explore. In addition to this, there may be a psychological account of the matter, of the utmost importance and ever so extensive. With this, it is not my business here to meddle; although I may here and there make such use of it as I can in aid of my own doctrine.
Peirce: CP 2.108 Cross-Ref:††
    108. Time was when a theorem could constitute a considerable contribution to mathematical science. But now new theorems are turned out wholesale. A single treatise will contain hundreds of them. Nowadays methods alone can arrest attention strongly; and these are coming in such flocks that the next step will surely be to find a method of discovering methods.†1 This can only come from a theory of the method of discovery. In order to cover every possibility, this should be founded on a general doctrine of methods of attaining purposes, in general; and this, in turn, should spring from a still more general doctrine of the nature of teleological action, in general.†2
Peirce: CP 2.109 Cross-Ref:††
    109. Although the number of works upon Methodeutic since Bacon's Novum Organum has been large, none has been greatly illuminative. Bacon's work was a total failure, eloquently pointing out some obvious sources of error, and to some minds stimulating, but affording no real help to an earnest inquirer. THE book on this subject remains to be written; and what I am chiefly concerned to do is to make the writing of it more possible.
Peirce: CP 2.110 Cross-Ref:††
    110. I do not claim that the part of the present volume which deals with Speculative Rhetoric will approach that ideal. As to the other parts of my book, this prefatory chapter commits me to producing a work of great importance or to being set down a drawler of nonsense.


Mary Keeler wrote:
Gary, what is the rest of the CP reference for the following quote you
gave? --m.

Peirce: CP .107. The regulation has served its end; why
should it be allowed now to hamper our endeavors to make
methodeutic practically useful?





--------------030203080102020701040809-- From owner-port-peer-review@bootstrap.org Wed Jul 3 03:28:05 2002 Return-Path: Delivered-To: port-peer-review-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id DCDE656FF3; Wed, 3 Jul 2002 03:28:04 -0700 (PDT) Delivered-To: port-peer-review@bootstrap.org Received: from pandora.cs.kun.nl (pandora.cs.kun.nl [131.174.33.4]) by bi0.bootstrap.org (Postfix) with SMTP id DA05756FF2 for ; Wed, 3 Jul 2002 03:28:02 -0700 (PDT) Received: from cs.kun.nl by pandora.cs.kun.nl via n032206.cs.kun.nl [131.174.32.206] with ESMTP id g63Aj1Q09225 (8.11.3/3.19); Wed, 3 Jul 2002 12:45:01 +0200 (MET DST) Message-ID: <3D22D6AB.E806DA8F@cs.kun.nl> Date: Wed, 03 Jul 2002 12:49:15 +0200 From: janos sarbo X-Mailer: Mozilla 4.76 [en]C-CCK-MCD {Starpower} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: port-peer-review@bootstrap.org, janos@cs.kun.nl Subject: Re: [port-peer-review] reviews References: <3D21AB09.5080804@rcn.com> Content-Type: multipart/alternative; boundary="------------2CDA74F878446BBF434853B5" Sender: owner-port-peer-review@bootstrap.org Precedence: bulk Reply-To: port-peer-review@bootstrap.org --------------2CDA74F878446BBF434853B5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit It seems that I made a terrible mistake by mixing up tools and systems. The funny thing is that I mixed them up without thinking of the possible consequences of this for the meaning of the text. What might make my malfunctioning interesting is the following. It is commonly agreed that we either know something, or we do not. In reality however we have both: at the same time we may know something and yet we cannot state that we (fully) understand its meaning (e.g. the meaning of tool and system, as well as, their differences in context). How is this possible? I remember that John McCarthy raised a similar question at Stanford University last year. The problem becomes especially clear when we are using computers which are tools inasmuch as their `rules' are (formally) defined. How are the rules of a non-formal system defined? If formally, then such a system must be a tool; if not formally, then those `rules' may not be said defined (I assume that any definition is based on facts and principles agreed on, which could be stated explicitly hence also formally). Best regards, Janos Sarbo Gary Richmond wrote: > > > On 6/26 Jun 2002, Aldo de Moor wrote in response to comments by > Phillipe Martin: > >> The complexity of socio-technical system evolution is such that >> methodological support is essential. Most methodologies, e.g. in >> knowledge >> and requirements engineering, focus on the lowest levels >> (information >> system, usage context). >> > It is apparently all too easy to forget the important distinction you > made between TOOL and SYSTEM (in response to a comment on your paper > by Janos Sarbo). The pragmatic principle and related notions like Doug > Engelbart's of "improving on improvement" essentially require > consideration at the meta-level. Peirce's pragmatism is, of course, > not a tool, but a theory within the methodological part of his logic, > "the highest and most living branch of logic." CP 2.333 (which at one > point he interestingly refers to as "transuasional logic"). There > seems a tendency to conflate the two, often reducing everything to > tools and their use; or alternatively, finding this, and the other > distinctions you made, mere "common knowledge" (though, of course, > common knowledge itself needs to be criticized in a thorough-going > pragmatism), rather than to see reflection at this level essential to > the growth of collaborative communities. > ------cut here------ --------------2CDA74F878446BBF434853B5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit It seems that I made a terrible mistake by mixing up tools and systems. The funny thing is that I mixed them up without thinking of the possible consequences of this for the meaning of the text. What might make my malfunctioning interesting is the following.

It is commonly agreed that we either know something, or we do not. In reality however we have both: at the same time we may know something and yet we cannot state that we (fully) understand its meaning (e.g. the meaning of tool and system, as well as, their differences in context). How is this possible?

I remember that John McCarthy raised a similar question at Stanford University last year. The problem becomes especially clear when we are using computers which are tools inasmuch as their `rules' are (formally) defined. How are the rules of a non-formal system defined? If formally, then such a system must be a tool; if not formally, then those `rules' may not be said defined (I assume that any definition is based on facts and principles agreed on, which could be stated explicitly hence also formally).

Best regards,
Janos Sarbo
 

Gary Richmond wrote:

 
On 6/26 Jun 2002, Aldo de Moor wrote in response to comments by Phillipe Martin:
The complexity of socio-technical system evolution is such that
methodological support is essential. Most methodologies, e.g. in knowledge
and requirements engineering, focus on the lowest levels (information
system, usage context).
It is apparently all too easy to forget the  important distinction you made between TOOL and SYSTEM (in response to a comment on your paper by Janos Sarbo). The pragmatic principle and related notions like Doug Engelbart's of "improving on improvement" essentially require consideration at the meta-level.  Peirce's pragmatism is, of course, not a tool, but a theory within the methodological part of his logic, "the highest and most living branch of logic." CP 2.333 (which at one point he interestingly refers to as "transuasional logic"). There seems a tendency to conflate the two, often reducing everything to tools and their use; or alternatively, finding this, and the other distinctions you made, mere "common knowledge" (though, of course, common knowledge itself needs to be criticized in a thorough-going pragmatism), rather than to see reflection at this level  essential to the growth of collaborative communities.
------cut here------
--------------2CDA74F878446BBF434853B5-- From owner-port-peer-review@bootstrap.org Wed Jul 3 08:19:10 2002 Return-Path: Delivered-To: port-peer-review-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id B027356FF3; Wed, 3 Jul 2002 08:19:09 -0700 (PDT) Delivered-To: port-peer-review@bootstrap.org Received: from mailone.kub.nl (mailone.kub.nl [137.56.0.62]) by bi0.bootstrap.org (Postfix) with SMTP id DBB3356FF2 for ; Wed, 3 Jul 2002 08:19:04 -0700 (PDT) Received: from prefix1 (prefix1.kub.nl [137.56.0.78]) by mailone.kub.nl (8.12.2/8.12.2) with ESMTP id g63FZwli012279 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 3 Jul 2002 17:35:58 +0200 (MET DST) Date: Wed, 3 Jul 2002 17:35:58 +0200 (MET DST) From: Aldo de Moor X-X-Sender: ademoor@prefix1 To: port-peer-review@bootstrap.org Subject: Re: [port-peer-review] reviews In-Reply-To: <3D22D6AB.E806DA8F@cs.kun.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.9 required=5.0 tests=IN_REP_TO,DEAR_SOMEBODY version=2.20 X-Spam-Level: Sender: owner-port-peer-review@bootstrap.org Precedence: bulk Reply-To: port-peer-review@bootstrap.org Dear Janos, > University last year. The problem becomes especially clear when we are > using computers which are tools inasmuch as their `rules' are (formally) > defined. How are the rules of a non-formal system defined? If formally, > then such a system must be a tool; if not formally, then those `rules' > may not be said defined (I assume that any definition is based on facts > and principles agreed on, which could be stated explicitly hence also > formally). The reason something is a tool is not because it has defined rules. A hammer does not have defined rules. Something is a tool because it serves as an instrument for somebody/something to carry out activities. A hammer allows you to drive nails into a wall. A computer allows you to carry out many kinds of information and communication processes. The definitions of the activities served by tools, and the mappings that explain how a tool exactly serves those activities can be either formal or informal. The definitions that describe how these dependencies take place, evolve, etc. are *about* the tools in context, not *part of* the tools. Cheers, Aldo ========================================================================== ---/// e-mail: ademoor@kub.nl IN|F/OLAB phone +31-13-4662914/3020, fax +31-13-4663069 |/// home page: http://infolab.kub.nl/people/ademoor Dr. Aldo de Moor Infolab, Dept. of Information Management - Tilburg University PO Box 90153, 5000 LE Tilburg, The Netherlands ========================================================================== From owner-port-peer-review@bootstrap.org Wed Jul 3 09:30:48 2002 Return-Path: Delivered-To: port-peer-review-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id DDE3356FF3; Wed, 3 Jul 2002 09:30:47 -0700 (PDT) Delivered-To: port-peer-review@bootstrap.org Received: from mxout3.cac.washington.edu (mxout3.cac.washington.edu [140.142.32.19]) by bi0.bootstrap.org (Postfix) with SMTP id 62AE356FF2 for ; Wed, 3 Jul 2002 09:30:46 -0700 (PDT) Received: from mailscan-out3.cac.washington.edu (mailscan-out3.cac.washington.edu [140.142.32.18]) by mxout3.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.06) with SMTP id g63GlfYu031835 for ; Wed, 3 Jul 2002 09:47:41 -0700 Received: FROM mead1.u.washington.edu BY mailscan-out3.cac.washington.edu ; Wed Jul 03 09:47:39 2002 -0700 Received: from localhost (mkeeler@localhost) by mead1.u.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g63GlcJm018598 for ; Wed, 3 Jul 2002 09:47:38 -0700 Date: Wed, 3 Jul 2002 09:47:38 -0700 (PDT) From: Mary Keeler To: port-peer-review@bootstrap.org Subject: [port-peer-review] Workshop proceedings! (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-port-peer-review@bootstrap.org Precedence: bulk Reply-To: port-peer-review@bootstrap.org Dear Eugene (and All), The ICCS organizers are calling for the papers to be prepared for publication, can the authors have them in "final form" by Monday? --MK ---------- Forwarded message ---------- Date: Wed, 03 Jul 2002 15:11:17 +0300 From: Albena Strupchanska To: Mary Keeler Cc: pavlin@prosyst.com, garyrichmond@rcn.com, kristina@CS.Stanford.EDU, ged@phi-science.com, ged@highstream.net, iccs2002@lml.bas.bg, eekim@eekim.com, upriss@indiana.edu, klabarre@indiana.edu, cdent@BURNINGCHROME.COM, phmartin@meganesia.int.gu.edu.au, AdeMoor@kub.nl, janos@cs.kun.nl, kokkoras@csd.auth.gr, petkov@lri.jur.uva.nl, naso@sirma.bg Subject: Workshop proceedings! Dear Mary Keeler, We would like to strart preparing the workshop dissemination early. Would you send us all the papers plus some index file (html) no later than 8 of July (Monday). Best regards, Albena Strupchanska From owner-port-peer-review@bootstrap.org Wed Jul 3 09:35:54 2002 Return-Path: Delivered-To: port-peer-review-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 1817756FF3; Wed, 3 Jul 2002 09:35:54 -0700 (PDT) Delivered-To: port-peer-review@bootstrap.org Received: from plounts.uits.indiana.edu (plounts.uits.indiana.edu [129.79.1.73]) by bi0.bootstrap.org (Postfix) with SMTP id 055B356FF2 for ; Wed, 3 Jul 2002 09:35:47 -0700 (PDT) Received: from iago.ucs.indiana.edu (iago.ucs.indiana.edu [129.79.5.207]) by plounts.uits.indiana.edu (8.12.1/8.12.1/IUPO) with ESMTP id g63Gqf1I005768 for ; Wed, 3 Jul 2002 11:52:41 -0500 (EST) Received: from localhost (klabarre@localhost) by iago.ucs.indiana.edu (8.9.3/8.9.3/1.2iago-imap) with SMTP id LAA02018 for ; Wed, 3 Jul 2002 11:52:38 -0500 (EST) Date: Wed, 3 Jul 2002 11:52:38 -0500 (EST) From: Kathryn La Barre X-Sender: klabarre@iago.ucs.indiana.edu To: port-peer-review@bootstrap.org Subject: Re: [port-peer-review] Workshop proceedings! (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-port-peer-review@bootstrap.org Precedence: bulk Reply-To: port-peer-review@bootstrap.org Mary, Chris and I will have completed our revisions by that time. How, and to whom should we submit the revised paper? Directly to Albena Strupchanska? Thanks, Kathryn From owner-port-peer-review@bootstrap.org Wed Jul 3 09:47:50 2002 Return-Path: Delivered-To: port-peer-review-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id 5705E56FF3; Wed, 3 Jul 2002 09:47:50 -0700 (PDT) Delivered-To: port-peer-review@bootstrap.org Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.5]) by bi0.bootstrap.org (Postfix) with SMTP id C9DBB56FF2 for ; Wed, 3 Jul 2002 09:47:48 -0700 (PDT) Received: from mailscan-out2.cac.washington.edu (mailscan-out2.cac.washington.edu [140.142.33.17]) by mxout1.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.06) with SMTP id g63H4iR6014463 for ; Wed, 3 Jul 2002 10:04:44 -0700 Received: FROM mead1.u.washington.edu BY mailscan-out2.cac.washington.edu ; Wed Jul 03 10:04:43 2002 -0700 Received: from localhost (mkeeler@localhost) by mead1.u.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g63H4gBP048910 for ; Wed, 3 Jul 2002 10:04:43 -0700 Date: Wed, 3 Jul 2002 10:04:42 -0700 (PDT) From: Mary Keeler To: port-peer-review@bootstrap.org Subject: Re: [port-peer-review] Workshop proceedings! (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-port-peer-review@bootstrap.org Precedence: bulk Reply-To: port-peer-review@bootstrap.org On Wed, 3 Jul 2002, Kathryn La Barre wrote: > > Chris and I will have completed our revisions by that time. How, and to > whom should we submit the revised paper? Directly to Albena Strupchanska? Good question, Kathryn, thanks. Eugene and I will settle on some procedure or deadline, but you should go ahead and send your final version to Eugene, who will manage the final edit of the volume. He will no doubt have his own remarks about the process to include. He is traveling, at the moment, but has sent me a note today, so let's see what he plan he might have. --MK From owner-port-peer-review@bootstrap.org Sun Jul 7 11:18:58 2002 Return-Path: Delivered-To: port-peer-review-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id B97FA56FF3; Sun, 7 Jul 2002 11:18:57 -0700 (PDT) Delivered-To: port-peer-review@bootstrap.org Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by bi0.bootstrap.org (Postfix) with SMTP id 6CFB356FF2 for ; Sun, 7 Jul 2002 11:18:56 -0700 (PDT) Received: from pool0132.cvx26-bradley.dialup.earthlink.net ([209.179.222.132]) by gull.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17RGsz-00001X-00 for port-peer-review@bootstrap.org; Sun, 07 Jul 2002 14:35:54 -0400 Date: Sun, 7 Jul 2002 11:14:51 -0700 (PDT) From: Eugene Eric Kim X-X-Sender: To: Subject: [port-peer-review] updated Dialog Map posted Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-port-peer-review@bootstrap.org Precedence: bulk Reply-To: port-peer-review@bootstrap.org I was very glad to see the great discussion over the past few weeks. Unfortunately, I was traveling, and could not map it regularly (which defeated part of the purpose for doing it). I have caught up with the discussion, and have posted the updated map: http://lab.bootstrap.org/port/dialogmaps/2002/index.html One metanote: The map is created graphically, but it is published as an outline. Parts of this particular map really loses something when displayed this way. I'm working on an SVG export of the map, which you'll be able to view with a browser plug-in, and will inform this list when it's complete. As always, comments and questions are encouraged. -Eugene -- +=== Eugene Eric Kim ===== eekim@eekim.com ===== http://www.eekim.com/ ===+ | "Writer's block is a fancy term made up by whiners so they | +===== can have an excuse to drink alcohol." --Steve Martin ===========+ From owner-port-peer-review@bootstrap.org Mon Jul 8 04:11:29 2002 Return-Path: Delivered-To: port-peer-review-list@bi0.bootstrap.org Received: by bi0.bootstrap.org (Postfix, from userid 2001) id E662A56FF3; Mon, 8 Jul 2002 04:11:28 -0700 (PDT) Delivered-To: port-peer-review@bootstrap.org Received: from mailone.kub.nl (mailone.kub.nl [137.56.0.62]) by bi0.bootstrap.org (Postfix) with SMTP id F1C1556FF2 for ; Mon, 8 Jul 2002 04:11:26 -0700 (PDT) Received: from magnix (magnix.kub.nl [137.56.0.215]) by mailone.kub.nl (8.12.2/8.12.2) with ESMTP id g68BSNli028710 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 8 Jul 2002 13:28:24 +0200 (MET DST) Date: Mon, 8 Jul 2002 13:28:23 +0200 (MET DST) From: Aldo de Moor X-X-Sender: ademoor@magnix To: port-peer-review@bootstrap.org Subject: Re: [port-peer-review] updated Dialog Map posted In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.9 required=5.0 tests=IN_REP_TO,DEAR_SOMEBODY version=2.20 X-Spam-Level: X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-port-peer-review@bootstrap.org Precedence: bulk Reply-To: port-peer-review@bootstrap.org Dear Eugene, > http://lab.bootstrap.org/port/dialogmaps/2002/index.html > > One metanote: The map is created graphically, but it is published as an > outline. Parts of this particular map really loses something when > displayed this way. I'm working on an SVG export of the map, which you'll > be able to view with a browser plug-in, and will inform this list when > it's complete. Thanks for providing us with the maps. They are useful, but a graphical representation may indeed be even better (same with MindManager (http://www.mindjet.com), for which the graphical layout is much more powerful than the derived RTF-file). Keep up the good work, Aldo ========================================================================== ---/// e-mail: ademoor@kub.nl IN|F/OLAB phone +31-13-4662914/3020, fax +31-13-4663069 |/// home page: http://infolab.kub.nl/people/ademoor Dr. Aldo de Moor Infolab, Dept. of Information Management - Tilburg University PO Box 90153, 5000 LE Tilburg, The Netherlands ==========================================================================