Thursday, January 26, 2006
Generative Methodology Glass Bead Games
Communicated to part of the SOA Blueprint Technical Committee (at OASIS),
First replies à [145]
Discussion…
When I first came across the concept of a SOA Blueprint Technical Committee (at OASIS), I was curious. I thought to myself, if this is done conceptually and behaviorally without getting into implementation details, then one can do the similarities and differences over invariances seen across the set of Blueprints. (I have material prepared that explains what "analysis of similarities and differences over invariances" means. It is not a hard methodology to use.)
The key is to not formalize too soon, and get the conceptual and behavioral models developed first. Formalization is either incomplete or inconsistent, as is well known from the foundations of logic and also from our current experience.
In looking at the current discussions of the TC, we find
"I find it hard to see at the level of a blueprint, what
agricultural and financial business problem statements have in common. You
cannot come up with a generalized set of semantics. I agree that there are
common problems that need addressing and you list some of them. It would be
worthwhile to pursue these. But I have trouble seeing how this fits into our
charter. According to our charter an adoption blueprint must supply: a business
problem statement a set of business requirements a normative set of functions
to be fulfilled, on a vendor- and specification-neutral basis. The only way I
know how to proceed under these circumstances it to decide who we want to
address our end product to and what problems they have we want to help them
with. The charter's "Anyone involved in the design, documentation or
implementation of Service Oriented Architectures (SOAs) or components
thereof." is just too general. I think your suggestion of common problems
has merit and is worth pursuing. "
Michael
<end quote>
Which is the type of discussion we see in the ONTAC working group (US Federal sponsored). A number of hard problems are recognized, but a path forward is not seen. The impasse results in new standards, and "reference models", that entrench the misunderstanding of the problem at hand. It is a three steps forward two steps backward kind of thing. It is the opinion of the Second School of Semantic Science that the core difficulty lies in our trust that "logic" can be imposed on definitions of concepts to produce realistic inference - in the general case.
The SOA (Service Oriented Architecture) Blueprints charter is correct and any attempt to narrow the charter moves one away from the solution that the concept of Blueprints is designed to address (in my opinion). Re-creating a new systems of non-communicating silos is not what the SOA community is looking for.
The three steps forward is in advancing the notion of blueprints, the two steps back is in wanting to immediately formalize the first several proposed blueprints.
The notion of stratification, when understood properly (which means when not being misunderstood in the common way of misunderstanding stratification), provides a methodology for mapping the "formative layer" or "substructural layer" of a two layer conceptual ontology (semi-formal ontology). The common misunderstanding is to create class-subclass hierarchy such as we find in OWL type ontology. The upper layer is the set of blueprints.
The two layers of ontology are separated "epistemically" (ie not only is there no subsumption relationship between elements of the top layer and elements of the lower layer there is no "meaningful" relationship what so ever.) (This follows the notion of double articulation (sometimes called 'duality of patterning')
http://www.google.com/search?hl=en&lr=&q=double+articulation
A methodology exists to create a doubly articulated (stratified) ontology for web services (in general). One first has to have a large (50 - 100?) set of conceptual descriptions of the form:
a business problem statement
a set of business requirements
a normative set of functions to be fulfilled, on a vendor- and specification-neutral basis.
which is consistent with the TC's charter.
Once this resource is at least partially complete, ( updating can occur later ) , then the elements of the set of blueprints is examined (pairwise) for invariance. One can create a set of triples < a, r, b > where a and b are blueprints and r is an invariance between the two.
Example: "raw materials" is in invariant in many business requirements.
Example: "knowledge evocation" is an invariant in "knowledge management technology deployments"
Suppose that after human work on extracting invariances one has a set of 100 "invariances" , one then develops a QSAR analysis (qualitative structure activity relationship) analysis; focusing on the similarities and differences between invariances.
The QSAR analysis leads to a conceptual ontology (a semi-formal ontology without deductive mechanisms) about the formative, or substructural, layer under all of the blueprints. This formative ontology is then used to aggregate "reified invariance" into a service-component based representation for each of the original blueprints.
{ reified invariances } sameAs { service-components }
If there is a blueprint that does not get properly represented, then the invariances are changed slightly and new analysis developed so that again we have a single set of invariance (embedded in the formative ontology), and which has the property that any blueprint can be described by some aggregated subset of the formative ontology.
Observation: The formative ontology will exhibit what appears to be plausible reasoning; when given a partial blueprint, not in the original set of blueprints, and asked to reproduce a full blueprint. This is then a discovery process.
So, as specified in the OASIS WSML, OASIS WSMO, and in the SOA IM; we have "orchestration of web service responses", "discovery" and mediation of data and process definitions.
The various "semantic" primitives of Zackman, Sowa, Ballard, Adi etc are largely "self evident" and not developed through methodology... except for Adi's work.
QAT did propose (before the USSR scientific community collapsed) that a set of primitives be developed using the method that I have generalized above.