There are many types of capability with relations among them. One
needs to be capable along all appropriate dimensions in order to be
capable of doing something. The dimensions depend upon both the
activity type and the actor type. Biological cells have capabilities,
just as terrorist cells do, however, the scope and generic types of
capabilities differ. (01)
Military capability is a relatively narrow aspect of the concept as
a whole (although broad in its own right). (02)
It's useful to look at what others have done. (03)
The Cyc predicate, #$capbableOf (created in 1993) considers multiple
types of capability. In its comment (last edited in 2001) one finds:
"(#$capableOf AGENT SITTYPE ROLE) means that AGENT is able to
perform ROLE in Situations of the type SITTYPE. This entails that
AGENT is qualified in all the relevant ways to fill that ROLE; i.e.
AGENT is #$physicallyCapableOf playing that ROLE in instances of
SITTYPE -- and, given that AGENT is the appropriate sort of agent --
is also #$anatomicallyCapableOf, #$fiscallyCapableOf,
#$legallyCapableOf, and #$skillCapableOf playing that ROLE in
instances of SITTYPE. (04)
Contrast this predicate with the more general #$behaviorCapable:
(#$behaviorCapable OBJ SITTYPE ROLE) does not imply that OBJ
can unquestionably play ROLE in instances of SITTYPE since extrinsic
factors may prevent it from doing so; for example, (#$behaviorCapable
#$RonaldReagan #$Reading #$performedBy) may be true at a
time when (#$capableOf #$RonaldReagan Reading #$performedBy)
is not (e.g. at a time when Reagan is literate but blindfolded)." (05)
There are thousands of assertions in ResearchCyc about capability
which have probably been well vetted since Cycorp has had a number
of projects funded by the military. (06)
It wouldn't hurt to look at what they have done on this issue. (07)
-- doug foxvog (08)
On Fri, March 15, 2013 15:04, John Yanosy Jr. wrote:
> 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:
>
>
> 1. Capability - Minimal Feasibility Requirements - Mitigation of
> Context Constraints
> 2. 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.
>
> On Thu, Mar 14, 2013 at 8:56 PM, Hans Polzer <hpolzer@xxxxxxxxxxx> wrote:
>
>> 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
>> ****
>>
>> --****
>>
>> Ian Bailey****
>>
>>
>@MonkeyChap<https://twitter.com/intent/follow?original_referer=https%3A%2F%2Ftwitter.com%2Fabout%2Fresources%2Fbuttons®ion=follow_link&screen_name=MonkeyChap&tw_p=followbutton&variant=2.0>
>> ****
>>
>> 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****
>>
>> ** **
>>
>> On 14 March 2013 19:44, Pavithra <pavithra_kenjige@xxxxxxxxx> wrote:****
>>
>> Hello,
>>
>> Thank you again.
>> Regarding the discussion about "Capability", I would like to add my two
>> sense to it here.
>> A capability can be translated as a function or service that meets
>> certain set of requirements as defined by stake
>> holders/organization/interested parties . If it is accomplished or
>> performed by an "actor" or another "system" it can be written as use
>> case
>> or multiple use cases. Scenarios can be used to handle multiple
>> dimension
>> of the capability. Even tho use cases look simplistic, they are not
>> necessarily that simple, the scenarios can handle complexities to
>> certain
>> level..
>> Thanks,
>> Pavithra ****
>>
>> ** **
>>
>> ** **
>> ------------------------------
>>
>> *From:* Joanne Luciano <jluciano@xxxxxxxxx>
>> *To:* Ontology Summit 2013 Organizing Committee <
>> ontology-summit-org@xxxxxxxxxxxxxxxx>; Ontology Summit 2011 discussion <
>> ontology-summit@xxxxxxxxxxxxxxxx>
>> *Cc:* David F Andersen <david.andersen@xxxxxxxxxx>; Jana Hrdinova <
>> jhrdinova@xxxxxxxxxxxxxx>; Nicolau F Depaula <ndepaula@xxxxxxxxxx>;
>> "James Michaelis (michaj6@xxxxxxx)" <michaj6@xxxxxxx>
>> *Sent:* Thursday, March 14, 2013 2:32 PM
>> *Subject:* [ontology-summit] Thank you.****
>>
>> ** **
>>
>> RE:
>> http://ontolog.cim3.net/cgi-bin/wiki.pl?ConferenceCall_2013_03_14****
>>
>> ** **
>>
>> THANKS:****
>>
>> ** **
>>
>> to the organizers for the opportunity to present (which gave the the
>> opportunity to develop the ideas a bit further).****
>>
>> ** **
>>
>> to the participants for their questions, they will help make the next
>> communication better.****
>>
>> ** **
>>
>> And THANK YOU to ****
>>
>> ** **
>>
>> RPI Tetherless World Constellation ****
>>
>> "James Michaelis (michaj6@xxxxxxx)" <michaj6 AT rpi.edu>****
>>
>> ** **
>>
>> Center for Technology in Government iChoose Ontology Development
>> team****
>>
>> ** **
>>
>> Nicolau F Depaula <ndepaula AT albany.edu>, ****
>>
>> Djoko Sigit Sayogo <dsayogo AT ctg.albany.edu>, ****
>>
>> Jana Hrdinova <jhrdinova AT ctg.albany.edu>, ****
>>
>> David F Andersen <david.andersen AT albany.edu>****
>>
>> ** **
>>
>> for being great collaborators and for the opportunity to work on IChoose
>> (CTG)****
>>
>> ** **
>>
>> happy to answer questions, and happier to guide and develop the GOEF
>> framework if you think you would find it useful.****
>>
>> ** **
>>
>> ** **
>>
>> Kind regards,****
>>
>> Joanne****
>>
>> ** **
>>
>> ** **
>>
>> http://webconf.soaphub.org/conf/room/summit_20130314****
>>
>> ** **
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~****
>>
>> Joanne S. Luciano, PhD Tetherless
>> World Constellation ****
>>
>> Research Associate Professor Rensselaer Polytechnic Institute****
>>
>> Deputy Director, Web Science Research Center 110 8th Street, Winslow
>> 2143
>> ****
>>
>> Email: jluciano@xxxxxxx Troy, NY 12180, USA ****
>>
>> Office Tel. +1.518.276.4939 Global Tel.
>> +1.617.440.4364 (skypeIn)****
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~****
>>
>> ** **
>>
>>
>>
>> _________________________________________________________________
>> 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/
>> **
>> ******
>>
>>
>>
>> _________________________________________________________________
>> 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/****
>>
>> ** **
>>
>>
>> _________________________________________________________________
>> 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
> eMail: jyanosyjr@xxxxxxxxx
> LinkedIn: www.linkedin.com/in/jyanosyjr
>
> _________________________________________________________________
> 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/
> (09)
_________________________________________________________________
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/ (010)
|