ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Ontology of Commands

To: "'[ontolog-forum] '" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Hans Polzer" <hpolzer@xxxxxxxxxxx>
Date: Wed, 02 May 2012 20:00:50 -0400
Message-id: <022701cd28bf$cd8a9b50$689fd1f0$@verizon.net>
Patrick,    (01)

Thanks for making this point. It's precisely what I had intended to bring up
with my earlier email regarding the issue of the relationship between a
command issuer and the recipient/responder to the command when I mentioned
consequence and reputation management (reputation being a particular type of
consequence that doesn't entail "authority"). This is also why the US
military spends a significant amount of time in its training on the issue of
"lawful" orders and the issue of subordinate personnel/units initiative.
Just because someone in authority issues an order doesn't necessarily mean
you should or have to obey it. You will probably be held accountable for not
doing so, but if you make your case for why you should not have obeyed the
order, you might avoid major negative consequences (and maybe even be a
hero).  The consequence management aspects of the relationship between the
command issuer and recipient, along with the operational context perceived
by the parties at the time the command is issued, determine the likelihood
of the command being executed as issued, or in some modified form (e.g.,
slower than expected, ignoring some parameter, at a higher price than
previously agreed, etc.).    (02)

If the desire is to eliminate these considerations and simply assume that
the relationship between the command issuer and whatever is being commanded
is static and absolute, such that issuing the command is tantamount to
execution of the command by the recipient, barring some transmission/media
failure, fine. Let's just be explicit about that context scope constraint.
Of course, there could be intermediate positions as well, with some limited
variability in the relationship between command issuer and responder and
some incentives for obeying a command and some constraints on which commands
are to be obeyed and under what contexts.    (03)

Hans    (04)

-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Patrick Cassidy
Sent: Wednesday, May 02, 2012 4:27 PM
To: doug@xxxxxxxxxx; '[ontolog-forum] '
Subject: Re: [ontolog-forum] Ontology of Commands    (05)

Doug -
   The Cyc representation of 'Order' (command) as you present it makes
sense, particularly regarding the point that an Order creates an Obligation
only if the Ordering agent has authority to create an Obligation.
   But I am curious about one facet of 'Obligation' -
     As I have interpreted it, nothing is an 'obligation' unless there is
some negative consequence for not fulfilling the obligation - which also
implies some Authority that can create the Obligation and enforce it.  But I
don't see any negative consequences in the list of aspects of Obligation
that you list.  Are there any in the Cyc representation?    (06)

  (Of course, the negative consequences and the Authority determine the type
of Obligation)    (07)

Pat    (08)

Patrick Cassidy
MICRA Inc.
cassidy@xxxxxxxxx
908-561-3416    (09)

-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of doug foxvog
Sent: Monday, April 30, 2012 3:01 PM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] Ontology of Commands    (010)

On Fri, April 27, 2012 18:17, Burkett, William [USA] wrote:
> Hello, Ontologists - I've got a question that's been ping-ponging 
> around my brain lately and thought I'd solicit your input.    (011)

> What is a "command" in an ontological sense?   I can certainly envision a
> hierarchical part-of structure of commands, but is it accurate to 
> interpret this as a kind of process decomposition (e.g., a Script in 
> the sense of http://www.jfsowa.com/ontology/toplevel.htm)?  While a 
> process connotes a "do", it doesn't necessary connote "go do", as a
> command/imperative would.   What is a "command" in the real world?    (012)

The word "command" denotes two classes of thing (that i will discuss):
a speech act, and an obligation implicit in the speech act.  Instead of
starting from scratch to answer what each of these is, we can look at work
that has already been done.    (013)

In OpenCyc, the speech act is a subclass of Requesting, which is a subclass
of CommunicationAct.  It is distinguished from Demanding (for which the
requester has no authority to require the action) and other sorts of request
for which no obligation is implied.  Commanding is a subclass of Ordering,
but OpenCyc does not make clear the distinction clear.    (014)

Requests directly have the properties
  actAccededTo -- agent does what the request requests
  typeOfThingRequested -- [obvious]
Other properties (communicator, communication target, timing properties,
...) are inherited from more general categories.    (015)

In OpenCyc, more interesting things can be said about the obligation than
about the speech act, which details the mechanics of the speech act and
assigns the obligation to the communication target.    (016)

An obligation has a number of properties; OpenCyc has ontologized the
following at that level:    (017)

  obligingAgents -- who imposed the obligation
  obligatedAgents -- who is obligated
  obligationParticipants -- either of the above
  obligationPeriod -- the time period for which the obligation holds
  subObligations -- parts of the obligation which are themselves obligations
  obligationOwedTo -- the party to whom the obligation is owed
  obligationHasPriorityOverObligationForAgent -- a ranking of obligations    (018)

  cocObligations -- a code of conduct has this as an obligation
  moratoriumOn -- a moratorium suspends this obligation
  derivedObligation -- a specification has this as a derived obligation
  resultingTermInOffice -- an event has created an obligation (to serve a
term)
  obligationsCreated -- an event has created this obligation
  agentViolatesObligation --  [obvious]
  agentFulfillsObligation --  [obvious]
  obligationsViolated -- an action has violated an obligation
  agentObligationInSituation -- an agent is obligated within a situation
  obligationFulfilled -- an action fulfills an obligation
  agentBelievesInObligation -- agent believes it is obligated by an
obligation    (019)

An #$Obligation is a subclass of #$NormativeSpecification, so other
properties are defined at that level.    (020)

Below is OpenCyc's subcategories of Requesting:
       ... CommunicationAct-Single
                 *Requesting-CommunicationAct
                       *Demanding-CommunicationAct
                             *Demanding-Threatening ...
                             *DemandingApology
                             *...
                             *Ultimatum
                       *DiplomaticRequest
                       *GettingBids
                       *OfferingABribe
                       *Ordering-CommunicationAct
                             *AssigningAgentToRole
                             *AssigningATask
                             * ...
                             *Ordering-MilitaryCommunicationAct
                             *SettingUpADirectDebit
                             *SettingUpAStandingOrder
                       *RequestingAction ...
                       *RequestingInformation ...
                       *RequestingItems ...
                       * ...    (021)

-- doug foxvog    (022)

> Context of question:  In a SOA-based software development effort, how 
> would ontological principles help with naming/function of services and 
> commands offered through the service interface?
>
> What do you think?  (Is that a dangerous question to ask this crowd?  
> ;-))
>
> Bill
>
> _________________
> William C. Burkett   Associate
> Booz | Allen | Hamilton
> 121 S Tejon St # 900 | Suite 900 South Tower | Colorado Springs, CO, 
> 80903
> T: 719-387-6452 | M: 310-318-5500 | F: 719-387-2020 
> burkett_william@xxxxxxx<mailto:burkett_william@xxxxxxx>
>
> _________________________________________________________________
> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
> Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
> Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
> Shared Files: http://ontolog.cim3.net/file/ Community Wiki: 
> http://ontolog.cim3.net/wiki/ To join: 
> http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
>    (023)



_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/ Community Wiki:
http://ontolog.cim3.net/wiki/ To join:
http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J    (024)



_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/ Community Wiki:
http://ontolog.cim3.net/wiki/ To join:
http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J    (025)



_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J    (026)

<Prev in Thread] Current Thread [Next in Thread>