|
Having just reviewed multiple sources of descriptions of Capability, I believe that there is additional context knowledge required to determine feasibility of a Capability in any Situation. This context knowledge may be indicated by determining any possible constraints of a Capability in an ontology. I propose that we may think of a scope of minimally required constraint dimensions that need to be mitigated to enable a Capability instance as part of an ontology definition of a Capability.
Also having a capability does not necessarily guarantee the achievement of an outcome, even if the minimal constraints defined by the ontology are mitigated. This uncertainty of outcomes, even with knowledge of what are believed to be reasonable associations of capabilities to outcomes, occurs as a result of either elements of randomness or complexity due to predictiing final states of dynamical systems.
Thus I think there is a somewhat complex overlap of contexts that I have indicated here: - Capability - Minimal Feasibility Requirements - Mitigation of Context Constraints
-
Capability Outcome Uncertainty Context
With regard to the first we could under what circumstances would an instance of Capability be justified. Use case analysis, as suggested in previous emails, is very useful in identifying possible minimal requirements and constraints. Also scope analysis as indicated by H. Polzer could also identify elemental considerations of context constraints that may be associated with a capability.
The latter is out of the scope of this discussion but there has been interesting work about probabilistic reasoning and representation with ontologies.
Ian,
This is a great summary of the origin of the concept of capabilities in the military planning context. In the US, this led to initiatives at the Joint Staff level in Capability Based Planning, and that led directly to the capability-based acquisition – the “C” in JCIDS. One other aspect of interest here was the relationship to “Effects Based Operations” (EBO), with capabilities being the ability to achieve specific “effects” in operational space. However, my comment about scale/scope in my response to Pavithra still applies. Indeed, the US DoD often found itself trying to distinguish between “big capability” – the ability to achieve desired operational mission effects – and “little capability” – the ability of a given unit or weapon system to achieve a particular, more specific, effect . And the issue of how to quantify capabilities and aggregate “little capabilities” into “big capabilities” remains a challenge, and depends on context (e.g., what is the “air lift capability” of the US?).
While one can argue that the focus of “capabilities” is on outcomes or results (i.e., effects), and not processes, the distinction between the two is never completely clean. At different scales of scope a capability can be viewed as part of a process and vice versa.
One other observation is that capabilities are often assigned to enterprises or “virtual” enterprises to manage the aggregation of resources required to attain and execute the capability over time. US examples might be FEMA and US Cyber Command at a very macro capability level, and local fire or police departments or building departments at local government capability levels. For commercial enterprises, capabilities might be implemented through “supply chains” or “demand chains” or “engineering matrices”, or similar constructs.
Hans
From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Ian Bailey
Sent: Thursday, March 14, 2013 4:58 PM
To: Pavithra; Ontology Summit 2013 discussion
Subject: Re: [ontology-summit] Thank you.
Folks, The concept of capability as a tool for strategic planning originates in the military. I think McKinsey did the original work on this in the 90s for UK MOD and also some work in US DoD. Capability is explicitly NOT about process. The whole idea is to allow strategic thinking without resorting to design of processes. Capabilities should be expressed in terms of outcomes - what, not how. Once you've worked out your capabilities, you can think about the processes and systems needed to deliver the capability. The concept has now found much wider use in the commercial world - see http://hbr.org/2010/06/the-coherence-premium/ar/1 and it also seems to have found a home in IT for portfolio management and application rationalisation, though whether those guys stick to the process-independence rule is somewhat questionable.
It's a very tricky concept to model in an ontology. In IDEAS we take the approach that a capability is the set of all possible things that are capable of achieving a particular outcome. Capabilities can have measures of effectiveness which constrain the members of the set. This approach seems to work for military architectures and strategic acquisition planning. We then have the concept of a capability configuration (people, systems and processes) that deliver the capability (these become subtypes of the capability) and finally fielded capabilities - physical things that are instances of the capability configuration and also therefore instances of the capability. MODAF works this, and I think DoDAF does too.
Chris Partridge did a lot of work on this for us - esp. around the dispositional aspects of capability. Regards
www.modelfutures.com
www.integrated-ea.com
tel: +44 7768 892362
Model Futures Limited is a company registered in England and Wales with company number 05248454 Registered Company Address: 1 Nelson Street, Southend-On-Sea, Essex, SS1 1EG
VAT Number: 848 7357 75, D-U-N-S Number : 73-998-0352
MOD FATS 4: FATS/4/MFL, DGFM Supplier Code: 56945
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2013/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2013
Community Portal: http://ontolog.cim3.net/wiki/
--
Best regards,
John A. Yanosy Jr.Mobile: 214-336-9875
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2013/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2013
Community Portal: http://ontolog.cim3.net/wiki/ (01)
|