[Top] [All Lists]

[ontology-summit] Fwd: Summit Engineering Tracks, function

To: Ontology Summit 2012 discussion <ontology-summit@xxxxxxxxxxxxxxxx>
From: Jack Ring <jring7@xxxxxxxxx>
Date: Sun, 22 Jan 2012 00:16:50 -0700
Message-id: <1AD4BEFE-9227-4798-A7BD-8ADBF9B1B950@xxxxxxxxx>
Patrick, Let's agree that in the next sports event we will note whether points are awarded for goals or objectives.
Jack Ring (not Jack Park)

Begin forwarded message:

From: "Patrick Cassidy" <pat@xxxxxxxxx>
Date: January 21, 2012 7:23:17 PM MST
To: "'Jack Ring'" <jring7@xxxxxxxxx>
Subject: RE: [ontology-summit] Summit Engineering Tracks, function

Jack -
  I tried sending this note below to the Ontolog forum, but their
overactive spam filter is now rejecting mail from one of the intermediate
forwarding sites for my server.  This has happened before, a real pain in
the butt.  No easy solution.
  Perhaps if you think it worthwhile, you can delete this header and
respond .  I think your point is worth pursuing.


Re:  Jack's comment:
[JP] > An alternative is to become semantically clear about the meaning(s)
of function, capability, role, purpose, objective, goal, etc., because each
signifies distinct concepts.

I agree, except for the suggested distinction between 'goal' and
'objective'. The WordNet has 'goal' as a supertype of 'objective', but (as
WordNet often does) with no clear semantic distinction between them.
Perhaps JP has a distinction in mind, in which case I would like to learn it
and represent it in the COSMO ontology.

WordNet: 'objective' and its parent concept 'goal':
aim, object, objective, target -- (the goal intended to be attained (and
which is believed to be attainable); "the sole object of her trip was to see
her children")
      => goal, end -- (the state of affairs that a plan is intended to
achieve and that 
           (when achieved) terminates behavior  intended to achieve it;
"the ends justify the means")

In trying to represent such concepts, I find that one needs a fairly large
(several thousand concepts) , multiply interrelated ontology to express the
meanings.  But without giving every last detail, what would one say the
difference is?

I have been particularly concerned with the details of semantics of the
basic concepts for the past few years, because I believe that the
primitives-based foundation ontology (PIFO) is not, as is commonly supposed,
arbitrary.  Domain ontologies, of course, can and usually do make special
assumptions and distinctions which may contradict other domain ontologies;
but all of those assumptions and distinctions can be logically expressed (as
far as I can determine) using the same set of PIFO concepts.  As far as I
have been able to determine, it is possible to discover the basic set of
concepts people use to express ideas, and to represent those logically in a
PIFO that can itself be firmly grounded in the real world through defined
sensor and robotic procedures.  For the near future, of course, in practical
ontologies it will be necessary to just describe such procedures rather than
implement them in hardware, but I have seen no theoretical barrier to having
machines fully 'understand' concepts in the same sense as people do.  It is
certainly true that there may be different logically equivalent ways to
express some of the basic concepts, but such different expressions can be
logically translated into each other.  One of the problems with CYC, SUMO,
and DOLCE was that (for very practical reasons) the developers chose to
focus on one way of representing the basic concepts, and not be concerned
with translation into different logically equivalent ways - leaving the
impression that the basic ontology *must* be arbitrarily chosen.  But that
limitation is not necessary, and I am convinced that a common PIFO can be
found that will logically express anything one wants to represent, and can
be used to translate among all the different local terminologies and
ontologies.  Unfortunately, proving that will take a very large project, to
demonstrate the point in multiple non-trivial applications.  All I can do at
present is to suggest that, if anyone is skeptical of this principle, they
send me a case that they believe would not fit the PIFO-translation
scenario, so I can determine if additional primitives beyond those already
in the COSMO are needed.

Meanwhile, any suggestions about the difference (in logical expressions)
between 'goal' and 'objective'?  (I would exclude the military 'objective'
which can be a place to capture - a specialized meaning).


Patrick Cassidy

-----Original Message-----
From: ontology-summit-bounces@xxxxxxxxxxxxxxxx
[mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Jack Ring
Sent: Saturday, January 21, 2012 9:43 AM
To: Ontology Summit 2012 discussion
Subject: Re: [ontology-summit] Summit Engineering Tracks, function

An alternative is to become semantically clear about the meaning(s) of
function, capability, role, purpose, objective, goal, etc., because each
signifies distinct concepts.
In recent years the distinctions between these have become quite blurred so
perhaps it would be better to sort them out rather than to delete one. The
deletion solution will never end. After function you will have to delete
another one until we are reduced to grunts.
The difference between what a system is designed to do and what it does do
can be clearly established if engineering stops ignoring [independent and
objective test and evaluation of the likelihood of system readiness].
This mini-issue clearly warns of the challenge ahead as precision-oriented
ontologists wade into the sinkhole of babble that has evolved around
On Jan 21, 2012, at 4:22 AM, henson graves wrote:

To be provocative, as an engineer I have come to find the concept of
function unsuitable for engineering discourse. I generally prefer to have
replaced with "role" or "capability". When we are talking about purpose,
e.g., his purpose is to be a target or to attack targets, role works
Function is often used in engineering in requirements to describe what
system is supposed to do. However, in recent years the distinction between
what a system is designed to do and what it can do gets blurred. So now
requirements development often starts with what capability one wants. Also
much engineering analysis concerns can a system perform a capability
it was designed for that or not. Capability also has the advantage in
requirements development that it is often easier to decompose it into
activities and implementations which can perform the activities. Of course
these implementations can be viewed as operations (functions) in a precise

Perhaps some ontologist would like to respond to this on Feb 2. I can give
more info if needed

- Henson

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/OntologySummit2012/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2012  
Community Portal: http://ontolog.cim3.net/wiki/     (01)
<Prev in Thread] Current Thread [Next in Thread>
  • [ontology-summit] Fwd: Summit Engineering Tracks, function, Jack Ring <=