Re: [port-peer-review] reviews
Dear Philippe, (01)
On Wed, 19 Jun 2002, Philippe Martin wrote: (02)
> 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. (03)
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. (04)
> 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? (05)
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. (06)
> 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). (07)
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. (08)
> 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? (09)
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. (010)
> 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 (011)
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. (012)
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. (013)
Aldo (014)
==========================================================================
---/// 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 (015)
Dr. Aldo de Moor
Infolab, Dept. of Information Management - Tilburg University
PO Box 90153, 5000 LE Tilburg, The Netherlands
========================================================================== (016)