comments on Rob Hanna's white paper

Here are a few comments that I noted while reading 
Rob's white paper. First his diagram, for reference, slightly edited (the image 
is also attached). Might consider making more of the arrows bidirectional; the 
loop from Result to Objective is omitted (comment below).

 

 

1 
Objective

 

The label on 
the "Objective" node was 
missing.

 

2 
Resource, 3 Task, 4 Skill -- No 
comments.

 

5 Concept
"The 
concepts object defines the complete set of
terminology used within the 
environment. Terms defined
here can be used throughout the 
environment."

 

This is merely a 
glossary of terms. The notion seems to be that the definitions of terms that 
are essential to the domain are statements of (all the?) concepts that are essential to the 
domain. However, 
this perhaps debatable contention is not explicitly stated.

 

Certainly, it is necessary to master the terminology and 
the definitions of objects and relations of a field. Many a glib shyster has 
"passed" on no more substantial skill than that--until they have to actually do 
or produce something. Typically, a definition in a domain is stated in the 
sublanguage of a logically prior domain.

 

Other 
conceptual information is in the Rules, 
Requirement, Specification, and Design objects, then? What of conceptual 
information associated with a process, a procedure, or an 
action?

 

6 
Rules-- no comments.

 

7 Action 

"Actions [sic] objects include processes, procedures, instructions, and test plans." Nodes in the "human capital" and "physical capital" 
triads must correspondingly shift scope, and they must also scale insofar is a 
process is a sequence of procedures (or potentially a sequence of 
processes).

8 
Result
[...]
"While it appears as a terminal node in the model, it 
can
ultimately link back directly to a new objectives object."

 

The link back is not 
shown. This could also be represented as one such pyramidal tree atop 
another, the result of the one above linking to the objective of the one below.

 

In addition, an 
objective is a desired result. Consequently the successful result of an action 
has a substantial relationship to the objective which motivates that action. This may be so 
in a qualified way 
even when the result differs from the objective, although in a troubleshooting 
process such a "failure" result links to the objective of a different objective and task, 
possibly with a 
different resource. 

 

The example of test 
results falls here. However, the expected results or "pass 
criterion/criteria" of a test are not the objective of the test. The 
business objective of testing is to determine whether a product is ready to release and, if 
not, some indication of what specific additional work is required. (Developers often do additional 
testing to pin down a bug.)

 

This is a result in 
the sense of accomplishment. But examples also include scenarios and incident 
descriptions, and these are not accomplishments. They may be consequences of actions, but 
those actions are 
fortuitous, unplanned, not organized systematically with the marshalling of 
resources etc. to achieve an objective.

 

A scenario may give 
rise to or motivate or contextualize an action, a task, or even an objective. Does that call for a 
double-headed arrow 
between result and action? Between result and task? The consequences of an 
action or actions may be described in a scenario which may then motivate the formulation of new 
objectives. Or is 
some other definition of scenario intended?

 

An incident 
description may describe consequences of actions, but not purposefully intended 
results achieving a business objective. It may be akin to negative test results, without the 
context of a formal 
test.

 

9 
Requirement, 10 Design, 11 Specification -- no comments. (But should it not be 
"Requirements"?)

 

____________________________________________
The stated 
purposes:

 

As content developers 
"We capture information
provided by subject matter experts as it changes. 
We
then transform it into content and publish it to our users.
Yet when we 
talk about single-sourcing, most often we
are talking about managing our own 
content. If we were
able to single source information rather than content 
we
could get closer to the source and interact directly with
the agents of 
change within the organization. The
challenge is in finding a way to 
effectively manage
information as content.
[...]
"Language, format, 
media, audience, and even derivative
content are all part of the presentation 
layer. They can
all change according to the needs of our users. 
The
underlying information however stays the same
regardless of changes to 
the presentation layer.
[...]
"Experts
argue that accidental reuse is 
not practical – and this I
would agree is mostly true of content. But it is 
not
strictly true of information. Information should not
change according 
to its context.
[...]
The aim is "a model that attempts to
define the 
shape of information we use to 
create
documentation".
____________________________________________

 

This statement 
overreaches a bit. These are information types or metadata category labels for 
(like it or not) content. 

 

When Dick Kittredge's 
products (cogentex.com) generate fluent text in a variety of languages and 
output modularities, the non-language data sources are arguably information as 
distinct from content. 

 

Harrisian discourse 
analysis produces a representation of information in a constrained 
subject-matter domain.

RHannaModel.tif