ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Ontology of Commands

To: "'[ontolog-forum] '" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "doug foxvog" <doug@xxxxxxxxxx>
Date: Thu, 3 May 2012 15:42:39 -0400
Message-id: <aafb883004599a2c3cc2f82697fbd27c.squirrel@xxxxxxxxxxxxxxxxx>
On Wed, May 2, 2012 16:26, Patrick Cassidy wrote:
> 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?    (01)

Such consequences are defined at the level or the superclass,
NormativeSpecification.  A specification defines what happens in what
cases.  The binary predicates #$necessaryForAvoidance and
#$sufficientForAvoidance specify what one types of event are necessary
in order that an event of a second type will not occur.  These predicates
are used to specify punishments for crimes, and would be used to
specify negative consequences for violating obligations in general.    (02)

They basically state that (in the context in which they are stated) that
it is necessary (sufficient) for agents to follow one specification (e.g., a
commend) in order that another specification (e.g., a punishment)
not be instantiated.    (03)

-- doug foxvog    (04)

>   (Of course, the negative consequences and the Authority determine the
> type of Obligation)
>
> Pat
>
> Patrick Cassidy
> MICRA Inc.
> cassidy@xxxxxxxxx
> 908-561-3416
>
> -----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
>
> 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.
>
>> 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?
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> An obligation has a number of properties; OpenCyc has ontologized the
> following at that level:
>
>   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
>
>   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
>
> An #$Obligation is a subclass of #$NormativeSpecification, so other
> properties are defined at that level.
>
> 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 ...
>                        * ...
>
> -- doug foxvog
>
>> 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>    (05)




_________________________________________________________________
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    (06)

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