comments on SAF V1

SAF is at my knowledge the only model that decouples (1) events (symptoms), (2) meaning at a larger level (syndromes) and (3) remedial process (Protocol) itself evaluated on the basis of new Symptoms. It closes the observation+analysis+remedial loop although not in a hardwired, rigid way: the model leaves the association between “syndromes” and “protocols” as something that can be evaluated, revised and improved.

Such a feature is overwhelmingly ignored in other action-focused knowledge models such as rule-based (e.g. ECA rules) or AI-inspired decision systems, where the association analysis/action is often considered as a “given”. SAF appears to be a pragmatic approach to model the troubleshooting process of any kind, and to handle the evolution of this process over time.

One technical comments:

- The definition of Signature could have been more generic, and worded so that it is not tied to a particular technology (XQuery). Couldn’t just XPath be used as well? (or XSLT, if the generation of a document is important?)

- Several attributes have just “labels” (enums) as values, e.g. Likelihood, Impact, Urgency in Syndrome. The spec could have made it clearer to users that the meaning of these values has to be defined by end-users in their particular domain and must be part of a SAF “profile” for this domain.

- In Symptoms, the “RelatedSymptoms” field is immutable, assuming that this correlation set is known at the time the Symptom is created. This is a rather bold assumption… I personally would only use RelatedSymptoms for the most obvious dependencies (repetitions…), as “causality” and “supersedes” often imply some analysis that I am not sure can be done at Symptom creation time. If some “smart” Symptom dependencies have to be recorded, couldn’t some (basic) Syndromes do the job instead?

Cheers,

Jacques Durand

FAI

saf-comment message