Pat,
You note - below is getting very topical for me as concepts(?) like process
and role are fundamental to business architectures. We have had related
discussions in standards related efforts concerned with process modeling
(The OMG "Business Process Definition Meta Model" to be explicit)[Copied].
Terms like process, activity, role and participant are central concepts and
getting them properly aligned is, as you know, difficult, particularly in a
group.
It would be fantastic if that work and the growing ontology work could be
constant and mutually supportive. There has been a great deal of
foundational work in the ontologies that can be a good grounding for
specific needs such as business process. Likewise, the pragmatics of
specifying business processes can provide a practical test case for upper
ontologies.
The structure you are suggesting, below, fits well with the model we (DAT
and some others) have been developing for business process - this model is
somewhat influenced by ontological approaches but still a "meta model" in
the technology sense. This does tend to make it a bit abstract.
The generic treatment of role is, I think important here as is the context
of a role - which could be a process or some other kind of relation. This
also brings in "participant" as you suggest, as a kind of role. An
assertion I made (that has not been accepted) is that roles are then a kind
of type. For example, there is a set of things that may be food and then
there is the set of things that ARE food at a particular time. Once any
instance fills the role there is an extent of such instances and therefore a
type. This sounds like the role-type John Sowa was defining. A proper
unification of role and type is, in my mind, a crucial core concept. A key
unification here is that processes can have roles in other processes.
I would be interested in others opinions on which of the upper ontologies is
suited for "business process" in the usual sense. This, of course, requires
concepts of time, change, activity, behavior and state. To be fully defined
I would also suggest it requires "intention".
Thoughts?
-Cory Casanave (01)
COSMO-WG:
There are several issues raised by John Sowa that I agree are
important and fundamental and should be discussed at an early point.
Each of these probably should form a thread in itself, though they may
be closely related. I will just briefly summarize what I think some of
the different threads could be: (02)
(1) How to handle roles
(From the comments on Food) (03)
[JS] The two definitions from SUMO and Cyc are consistent with the
definition I gave, but they should clearly recognize that Food
is a role type. (04)
The issue of how to represent Roles does not, as best I can tell, have
any consensus within the ontology community and involves some complex
considerations. I think it will be a good topic to discuss as a
separate thread. I will just mention a few thoughts on that issue:
(1.1) DOLCE uses the "MetaProperty" of Rigidity to distinguish classes
(they call them 'Properties') whose instances are necessarily of a
particular type and those whose instances may be of that type at one
time and not at another. The distinguish "Rigid Properties" from
non-rigid and anti-rigid. For example, see:
http://www.loa-cnr.it/Papers/GuarinoWeltyOntoCleanv3.pdf (05)
(1.2) I am not inclined to use the DOLCE "Onto-Clean" as a formal
tool in our deliberations, but I think there are useful insights in
those papers. (06)
(1.3) In SUMO and in some other ontologies I have seen, some roles are
expressed only as relations. This will raise an issue of whether
classes like "Mother" should be reified and not left only as a
relation. (07)
(1.4) The lesson I take away is that we should have some method of
specifying when a Class is of a "Role" type. I am not sure that
"Food" actually serves a typical Role function (we could specify that
anything that *can* be used as a nutrient is necessarily a food; in Cyc
Food is necessarily organic, so minerals by themselves don't qualify),
but I agree that it does have some Role character, and in any case
needs to be defined carefully in order to be a useful class. It is
also probably useful to distinguish food objects from food substances. (08)
I think we should discuss Roles as a separate thread, and use "Food" as
one of the specific examples to be properly axiomatized using whatever
formalism we decide is best ("student" can be another prototypical
"Role" class). I will leave detailed recommendations for that thread. (09)
On one point with respect to "Food":
[JS] It [Food] need not be self connected, since many kinds of candy,
nuts, etc., are food that consists of discrete lumps. The defining
principle that characterizes the role is that food must be edible and
nourishing for some organism. (010)
[PC] That criticism does make some sense to me. For example, a
subclass of 'Food" in SUMO is "Hay", which is dried grass, which does
not conform to what I would expect from the definition of
"SelfConnectedObject". Perhaps "Food" should be disconnected from
"SelfConnectedObject" and left as a subclass of the OpenCyc
"OrganicStuff" (i.e. a Food must have some content of organic material
usable by the body. OrganicStuff is a subclass of SUMO "Object" in
TopLevel, leaving Food as a subclass of "Object", as it is in SUMO).
Perhaps Adam Pease can tell us if there is a necessary reason to keep
Food as a subclass of SelfConnectedObject. (011)
(1.5) Syntactic roles (012)
[JS] How do two or more agents mentioned in the subject of a verb
relate to the action or state expressed by that verb?
. . .
[JS] Among my concerns is the fact that the word "patient" in
linguistics
is a specialization of the more general term "participant". And
there are all kinds of processes that take place in nature (many
detectable by ordinary human senses of sight, hearing, and touch),
which can be described in multiple ways in natural languages (with
different numbers of participants, depending on which verb you choose)
and which can also be described by differential equations or other
mathematical systems that do not involve clearly distinguishable
"participants". (013)
This is an important subcategory of "Role" and may be worth a separate
thread in itself. In DOLCE "participant" and related relations (e.g.
patient, substrate, target, theme) carry much of the weight of
specifying what continuants are involved in an Event. In Cyc "actors"
and its subrelations, and "beneficiary" and "deviceUsed" serve a
similar function. In SUMO, relations 'agent' and 'patient' and
'instrument' are used to specify participant roles, without a generic
'participant' relation. In NLP much ink has been spilled discussing
how to recognize who did what to whom, when, where, why, and how (the
W6H categories), and in some cases, with what effect. Specifying
participants and other linguistic elements syntactically related to
verbs is certainly central to representing events and needs proper
discussion. This might be discussed in a "Role" thread, or in an
"Event/Process" thread, or both. there is a lot conceptually in common
among the upper ontologies regarding participants, but the terminology
differs a lot. (014)
(2) Process types
[JS] My major objection was that the four types listed under process
were a haphazard dump of miscellaneous categories that belong
to different levels of analysis for different purposes. (015)
>From what I have seen, it appears that classification of Processes
varies greatly among ontologies, and will probably need a lot of
multiple-inheritance to tease apart the different aspects that
different people consider significant. A few concepts are in common,
such as "Translation" as a kind of motion. I think this will be a
continuing thread for a while. (016)
Warning: Events and Processes are not disjoint in SUMO and Opencyc,
though appear to be - informally - in WordNet. DOLCE differs from all
three. There are probably at least three distinct meanings of
"Process" that help confuse the issue. I have some detailed proposals
for the relation between these, based in part on John Sowa's paper
"Process and Causality":
http://www.jfsowa.com/ontology/causal.htm.
Much more at a later time. (017)
(3) Organization
[JS] Is a social organization anything more than just a set or group
of two of more people? If so, what is the unifying principle that
makes it an organization rather than an accidental set? (018)
Organization is one of the important basic classes that is relevant to
many or most applications, and probably should be carefully discussed
as a separate thread.
Organization is a subclass of "Artifact" in OpenCyc
(Artifact-generic, there) and in DOLCE is a "social-object" which is
also dependent on the action of a human agent. The relations between
these two concepts are complex, but share a common sense in that an
Organization is non-physical and is created by people, not just an
ad-hoc group. In SUMO an Organization is a group of people with a
common purpose; it is a physical object and therefore differs from the
treatment in Cyc and DOLCE. These definitions differ enough that it
may take significant effort to agree on a precise specification of the
meaning of Organization, and the result may not be identical to
"Organization" in any of those three ontologies. It is an "Agent" in
all ontologies.
My own preference is to consider "Organization" as (in addition to
an IntelligentAgent) a Mental entity -("Abstract artifact") created by
one or more people and consisting of a Charter (a set of organizing
principles - that's what make it 'organized') and a membership list (or
set of members). This is closer to Opencyc and DOLCE than to SUMO.
The membership list (or set) can be empty, to reflect the theoretical
possibility that an organization may have no "members" and continue in
existence; whether that can happen will depend on the Charter
("Constitution and by-laws" for some organizations). The relation of
members to an organization is therefore somewhat different from
membership in a set or in an unorganized group.
I will be happy to participate in a separate thread discussing
this issue. (019)
(4) Interoperability, Semantic and otherwise (020)
The discussion of "Interoperability" starting at the response to 2.1
looks to me like it would make a good entry in our glossary, under
"interoperability" (I know, this stretches the meaning of "glossary",
but it's a Wiki, after all.) John, would it be OK to put it there?
You can modify it at leisure. Go to: (021)
http://colab.cim3.net/cgi-bin/wiki.pl?OntologyTaxonomyCoordinatingWG/On
tacGlossary (022)
I haven't yet figured out whether and how to respond to those comments
on interoperability. (023)
Pat (024)
Patrick Cassidy
MITRE Corporation
260 Industrial Way
Eatontown, NJ 07724
Mail Stop: MNJE
Phone: 732-578-6340
Cell: 908-565-4053
Fax: 732-578-6012
Email: pcassidy@xxxxxxxxx (025)
-----Original Message-----
From: John F. Sowa [mailto:sowa@xxxxxxxxxxx]
Sent: Tuesday, January 17, 2006 7:10 PM
To: Cassidy, Patrick J.
Cc: Adam Pease; Anne Cregan; Arsic, Antoinette; Arun Majumdar; Barry
Smith; Brand Niemann; Charles Turnitsa; Chris Menzel; Christopher
Spottiswoode; Cory Casanave; Dagobert Soergel; David Eddy; Eric
Peterson; Gary Berg-Cross; Hans Teijgeler; Harold Frisch; I.N. Sarkar;
J. P. Morgenthal; James Schoening; Jeffrey A. Schiffel; John Cabral;
John Thompson; John Young; Ken Ewell; Kurt Conrad; Obrst, Leo J.;
Lowell Vizenor; Matthew R. West; Michael Denny; Michael Gruninger;
Nicolas Rouquette; Olivier Bodenreider; Pawel Garbacz; Peter Yim;
Richard Lee; Richard Murphy; Roberto Bordogna; Roy Roebuck; Steve Ray;
Walt Truszkowski; Wu Hanxin; Arun Majumdar
Subject: Re: Shall we start? (026)
Pat, (027)
Before we can merge or revise any ontologies, we must resolve
an important issue raised in the recent discussions: what are
the types of types that are permissible in an ontology? (028)
> I have mentioned before but will reiterate that the merged
> TopLevel was extracted from much larger and richer sets
> of concepts, solely to provide a simple outline that can
> be comprehended and reviewed in the time available within
> our volunteer group. (029)
It's OK as an overview of the territory, but without a clear
distinction of the types of types, it's bound to be confusing. (030)
> If we can agree on the minimum bare taxonomy, more detail
> will be added for review. (031)
For starters, I'd be happy with a bare-bones taxonomy that
doesn't have the kinds of problems that I mentioned in my
previous note. It's always easier to add detail than to
find and remove conflicting detail. (032)
> The question of in what sense a GeopoliticalArea could act
> as an Agent may in fact be a legitimate problem. (033)
It's related to fundamental questions that create confusion
throughout many of the ontologies we have been considering:
How do two or more agents mentioned in the subject of a verb
relate to the action or state expressed by that verb? Is a
social organization anything more than just a set or group of
two of more people? If so, what is the unifying principle
that makes it an organization rather than an accidental set? (034)
> SelfConnectedObject is indeed intended to represent physical
> objects that are topologically connected. (035)
That's fine. That puts it in the category of mathematical
structures used to characterize various kinds of entities
throughout the ontology. I have no doubt that such categories
will be useful, but the three subtypes are a weird selection:
Substance, Food, and BodyOfWater. (036)
> It appears that John Sowa does not consider "Food" as a
> coherent class. (037)
I didn't say that. But what I will say is that Food is a prime
example of a role type that has no inherent characteristics
other than being some sort of physical entity. It need not be
self connected, since many kinds of candy, nuts, etc., are food
that consists of discrete lumps. The defining principle that
characterizes the role is that food must be edible and nourishing
for some organism. (038)
The two definitions from SUMO and Cyc are consistent with the
definition I gave, but they should clearly recognize that Food
is a role type. (039)
> This [DualObjectProcess] appears to me to be a coherent concept.
> The definition (SUMO) is: "Any &%Process that requires two,
> nonidentical &%patients."
>
> Some subclasses are: Attaching, Detaching, Separating, Comparing.
> I would add - Collision - a salient notion in traffic situations. (040)
I have no objection to including categories for all the verbs in
English and other languages, but it must be recognized that linguists
have done far more serious work on these issues -- but it's still
a major research area, even in linguistics. (041)
My major objection was that the four types listed under process
were a haphazard dump of miscellaneous categories that belong
to different levels of analysis for different purposes. (042)
Among my concerns is the fact that the word "patient" in linguistics
is a specialization of the more general term "participant". And
there are all kinds of processes that take place in nature (many
detectable by ordinary human senses of sight, hearing, and touch),
which can be described in multiple ways in natural languages (with
different numbers of participants, depending on which verb you choose)
and which can also be described by differential equations or other
mathematical systems that do not involve clearly distinguishable
"participants". (043)
An example would be a whirlpool. In English, you could associate
it with the verb "whirl" and one participant, namely the water.
But you could also describe it with differential equations. (044)
This is just one example of many issues that arise throughout
ontology: In English, we say "it is raining", where "it" is
not really a participant, but an empty marker used to fill the
obligatory subject slot in English grammar. In Russian, one
could say "Rain goes", where "rain" is a participant in the
act of going. Both of these languages force a natural process
into grammatical patterns that are more suitable for talking
about people relating to things. A neutral ontology should
permit such ways of talking, but it should *not* require them. (045)
> It is not necessary for sibling classes to be disjoint in order
> for them to be useful. (046)
Perhaps. But this gets to fundamental questions about how to
organize and relate the many different ways of describing the same
"chunks" of reality. This takes us back to the old vase vs.
lump of clay issue, but now with processes rather than objects. (047)
> ... it will be necessary to have a high level of tolerance for
> the peculiarities of the ways others would want to represent
> knowledge. (048)
Yes, certainly. That's the whole point of the word _neutral_.
But then we have to recognize, relate, and systematize the
enormous variety of ways of representing knowledge. (049)
> I doubt that we will ever be able to find a top-level structure
> that the majority is enthusiastic about - the experience of the
> past ten years strongly suggests just the opposite. (050)
Of course. (051)
> But I believe that it is a realistic goal to try to find a
> top-level structure that all can accept - because it has in it
> the categories one feels are necessary, or perhaps because it
> has the ones that one is most comfortable using - among others. (052)
But before we can do that, we have to analyze and understand
the source of conflicts and how to resolve them. I suggest that
we look at the most widely used organization of categories that
the world has ever seen: WordNet. (053)
What makes WN so successful is that it has very few axioms.
Axioms are necessary for detailed reasoning. But they are also
the source of inconsistencies. If you remove most of the axioms,
you remove most of the potential conflicts. (054)
> ... the mention of "reasoning" in this paragraph should make
> that clear:
>
>> 2.1 Any two systems that desire to interoperate must
>> share the definitions ("specifications") of their new local
>> concepts and the data (instances) on which their reasoning
>> is to be performed (this is not necessarily the whole of
>> either ontology). (055)
That is the definition I specifically said was unclear, and
the following clarification makes the problem more obvious: (056)
> I have described "semantic interoperability" as "the ability
> of two independent programs with reasoning capability to
> arrive at the same conclusions from the same data." (057)
Without qualifications, this would imply that it is impossible
for most systems to achieve "semantic interoperability." It
would be violated by either of the following circumstances: (058)
1. Disjoint interests: System A and System B might both access
database C and use exactly the same definitions and constraints
used to define C. Yet A and B may have additional data or
constraints that would enable them to draw different conclusions
from that data. For example, C might be a hospital database of
patients, their physicians, their medical procedures, and their
hospital stays. System A might use that information for billing,
but System B might use it to schedule nurses, orderlies, food
supplies, etc. They never draw any common inferences because
they are working on totally disjoint tasks. (059)
2. Globally inconsistent, but locally consistent: In another case,
A and B might be completely incompatible for most problems because
they have many inconsistent definitions and axioms. Yet they
might both be completely compatible with C or with any questions
related to combinations of C with any ground-level data available
to A and B. But A and B could never be used together for more
complex reasoning tasks because they're inconsistent. (060)
I stated both of these examples in terms of two systems A and B,
that both interact with a third system C. But exactly the same
issues would arise if A and B send messages directly to one
another, but only about the subject matter at the level of C
(independently of whether the third System C actually exists). (061)
That is why I emphasize the point of defining "interoperability"
(semantic or otherwise) in terms of messages, *not* entire systems.
For that matter, I cannot conceive of any kind of interoperability
that is not semantic, at least at some level. That leads us to
three kinds of interoperability of increasing levels of strength: (062)
1. Message oriented: Systems A and B agree on some minimal
definitions of the terms used in a particular message, even
though A and B might have additional information (axioms or
ground-level atomic sentences) that involve those terms. (063)
2. Task oriented: Systems A and B agree on the definitions
for all the terms used in a particular type of task, and
therefore support message-oriented interoperability on all
messages concerning tasks of that type. (064)
3. System-oriented: Systems A and B agree on all the definitions
for all the tasks they are capable of performing. Therefore,
they support full task-oriented and message-oriented
interoperability in all cases. (065)
Many people who subscribe to this list seem to be talking about
system-oriented interoperability. However, I believe that is far
too strong a requirement, and it would make it impossible to achieve
interoperability between new systems and legacy systems or even
between two new systems that are designed to handle very different
kinds of tasks, yet have some level of common interest for some
subset of messages that pass between them. (066)
In addition to the notion of multiple levels of interoperability,
we should also recognize the notion of a *broker* that establishes
the conditions for interoperability. Again there are three levels: (067)
1. A priori: The system designer is the a priori broker who
legislates the requirements (i.e., definitions and axioms)
that shall be observed. (068)
2. Dynamic: Two systems that wish to interoperate request a
third-party broker about the minimum requirements for the
messages that pass between them. The broker then sends each
of them a list of the axioms (or the modules that contain
groups of axioms) that they shall observe. (069)
3. Negotiation: Each system has a local broker module that
communicates with the local brokers of other systems about
the axioms and definitions that are assumed for any particular
task or even any particular message. (070)
The product of these three levels of brokering with the previous
three levels would provide nine kinds of interoperability. The
most rigid and inflexible version would be a-priori system-oriented
interoperability, and many people in this group talk as if there is
no other kind. But there are eight other kinds, down to the most
flexible, which would be negotiated message-level interoperability.
That flexibility, however, would come at the price of extended
negotiation at each interchange. However, it should be possible
to design systems that would support any or all of these levels
and any combination that is appropriate for the applications. (071)
Recommendation: I suggest that we draw distinctions between the
three levels of interoperability and the three levels of brokering.
Many practical systems today interoperate quite successfully at
the message-oriented or task-oriented levels, and they can continue
to interoperate successfully with new systems at those levels. For
new systems, the stronger level of system-oriented interoperability
might be useful in some cases, but I strongly suspect there will
always be a need for weaker levels and for negotiations to determine
exactly which level is needed in any particular application. (072)
There's obviously much more to say, but this is enough for now. (073)
John (074)
_________________________________________________________________
Message Archives: http://colab.cim3.net/forum/ontac-dev/
To Post: mailto:ontac-dev@xxxxxxxxxxxxxx
Subscribe/Unsubscribe/Config:
http://colab.cim3.net/mailman/listinfo/ontac-dev/
Shared Files: http://colab.cim3.net/file/work/SICoP/ontac/
Community Wiki:
http://colab.cim3.net/cgi-bin/wiki.pl?SICoP/OntologyTaxonomyCoordinatingWG (075)
_________________________________________________________________
Message Archives: http://colab.cim3.net/forum/ontac-dev/
To Post: mailto:ontac-dev@xxxxxxxxxxxxxx
Subscribe/Unsubscribe/Config: http://colab.cim3.net/mailman/listinfo/ontac-dev/
Shared Files: http://colab.cim3.net/file/work/SICoP/ontac/
Community Wiki:
http://colab.cim3.net/cgi-bin/wiki.pl?SICoP/OntologyTaxonomyCoordinatingWG (076)
|