A response to Pat Hayes's note on changes in meaning: (01)
> [PC] > > I do question
> > that users of an ontology will *want* the meanings of their already-
> > defined ontology elements to change as new elements are added.
> > But PatH has said (it seems) that this is what he wants.
> > I will be eager for clarification.
>
> [PH] > We must be at cross purposes.
>
> Suppose we are developing the ontology and we notice something
> missing. Perhaps we have introduced a distinction between occurrents
> and continuants, but had not noticed that one of our high-level
> classes now needs to be subdivided into two categories, an old axiom
> which quantifies over the union needs to be rewritten as two axioms
> using distinct styles of atomic statements involving the temporal
> parameter. This involves deleting an axiom and replacing it with two
> others. The set of entailments changes, fortunately, as the axioms
> before this change implied (inadvertently, but they did in fact imply)
> that the high-level class in question was empty. The axioms had a bug
> in them, and we have now fixed that bug.
>
> Why would anyone NOT want conceptual bugs to be fixed in this way?
> (02)
[[PC]] Yes, of course we *definitely* want to correct errors and bugs, and
when that happens the meanings of the elements changed will indeed change.
This is part of the reason we want to get the FO as accurate as possible at
an early stage. The question I had was about the effects of making *any*
change at all, where it seemed that PatH was saying that we should *want*
the meanings of *everything* to change, regardless of what specific element
was actually changed. I understand that according to the logical
interpretation of meaning, everything will change whether we want it to or
not. But if the ontologist making a change at one point in the FO cannot
foresee a change in some distantly related element, and in fact *wouldn't*
want that change if s/he had foreseen it, how can we say that that change
was wanted? If in fact the unexpected change is not wanted, then the change
made can be considered as a bug in the ontology. So, to avoid unintended
changes it would be necessary to have some suite of test programs so that
undesirable, unforeseen, and unintended changes that affect programs can be
detected. When that happens, the ontology change that causes an undesirable
change in program performance will have to be rescinded, or something else
modified to restore the desired behavior.
So yes, **when we explicitly want to** change some element's program
performance (or correct an error in the model), then it should be done. But
if we don't want to change some element's program behavior, I found it odd
to say that we do *want* to change its meaning (reflected for our purposes
in the program's behavior) when we change *anything else* in the ontology. (03)
> [PH] > Why would anyone want the meanings of terms to be fixed, regardless
of
> what axioms were written to establish or capture those meanings? If
> this were so, there would be no purpose in writing axioms at all. (04)
[[PC]] Beats me. That isn't what I said. I said that we would want the
meanings to be as stable as possible, but clearly some meanings will *have*
to change if bugs are detected. However, this is only talking about the FO
itself. When linked with a domain ontology, there is a different issue,
which PatH raises below. (05)
> [PH. > Now, I suspect that your position is that of course we want this to
be
> so as long as we are writing the FO, but that once the 'core' FO is
> done, we want it to be stable, and all the meanings of the terms in it
> fixed, while we write the penumbra of application ontologies that fill
> in all the details of application areas. (06)
[[PC]] Well, we do *want* the FO to be as stable as possible, but it should
always be open to changes to accommodate recognition of errors, or new
requirements not met by the starting FO. Changes to the FO should always be
possible, but if it works as intended they should become increasingly rare.
If that doesn't happen, the accuracy of interoperability will be reduced
across FO versions for an indefinite time. Where possible, systems may
still interoperate by using the same FO version. Since domain ontologies
may often use the smallest part of the FO required to specify the meanings
of elements in their domain (for efficiency), it may be possible for other
applications to find a common set of FO elements. In those cases, the
systems posting information to the internet would also need to list the FO
elements that they actually used as well as the version number, if they use
a subset. I would expect application developers using a subset to test
their applications using the whole FO, to be sure that the elements not used
locally do not caused undesirable changes in the behavior of their programs,
other than slow it down. (07)
> [PH] > And here we get into a more
> technical matter, which is how to define 'meaning' so that this will
> be possible. The issue, it seems to me, is that the only available
> precise sense of "meaning" that we have, simply does not provide any
> way to say that the meanings of some terms are fixed by some of the
> assertions they occur in, but not by others. So if a term, say
> 'Human" (the class name for the set of human beings) occurs in the FO
> and also in some application module, call it M, then when those two
> are used together , there is nothing in the semantic theory of the
> underlying language which distinguishes the occurrences in FO from
> those in M, when we consider interpretations of the combination (FO
> +M). This larger set of axioms is simply a set of sentences, and they
> all 'contribute' in exactly the same way to the constraints of truth
> that the semantics establishes. SO I simply cannot understand what is
> meant by the claim that just the sentences in the FO part of (FO+M)
> 'fix' the meanings of the terms in this theory, while the other
> sentences.... do what? use those meanings without contributing to
> them? I am simply at a loss to know what is being claimed here.
> (08)
[[PC]] > I will take for simplicity at this point the case where the
additional sentences in M do not contradict anything in the FO. Yes, the
application ontology M will have assertions that are not in the FO about
some things, or about subtypes of some types. If one considers this a
change in the meanings of the FO elements, then each application ontology
will change the meanings of the terms inherited from the FO. But they will
not be contradictory to anything in the FO. So the FO provides a core set
of meanings that can be supplemented but not contradicted. However, this
will not defeat the purpose of the FO for supporting interoperability (more
after the following segment). (09)
> [PH] > Take the example of "Human". The FO might establish that Humans are
a
> subclass of Mammals and of Rational Agents and general stuff like
> that. But maybe M is all about sociobiology, and it tells us that
> human beings are descended from a race of early hominids hailing from
> Africa. Surely this tells us more about what Human means, changes the
> meaning of 'human'. Everything we learn involving the term tells us
> something new about the term and changes, if only slightly or subtly,
> its meaning. Where do we draw a line around the essential core of
> things we know about humanity, that constitutes the single, eternally
> fixed, universally accepted, single *definition* of the term "human"?
> I don't believe this can be done. All our intended meanings are
> embedded in, and take their authority from, some accepted theory of
> the world. And those theories are far too big, too extensive, to be
> something like a FO.
>
> Pat H
> (010)
[[PC]] There is no " single, eternally fixed, universally accepted, single
*definition*" of any term outside of a mathematical theory, but the ontology
elements in the FO can support accurate semantic interoperability even when
the meanings of domain terms are made more specific than those in the FO.
Assume that two ontologies accept the logical assertions in the FO. These
form a common base meaning that can be made more detailed, but not
contradicted, by domain ontologies that need to use the FO for
interoperability. (011)
For the given case, the sociobiology domain ontology would in effect be
defining a subtype of human that is descended from early hominids
"HumansDescendedFromAfricanHominids", and the assertions in that ontology
would be about that subtype, whatever term is used to label it in the
sociobiology ontology. The FO would be agnostic about that assertion, and
other ontologies using the FO would not contradict anything in the
sociobiology domain ontology, if they don't contradict that assertion. But
in general, if any domain D asserts properties of an FO type that is not
contradicted by other domains, and the creators of domain D (who understand
the intended meaning of the FO type) assert that property as necessary, the
default usage strategy would seem to be to use those properties when using
data from D, under the assumption that the creators of domain D are not
making a mistake. No logical contradictions will be generated, and the
using system will be able to generate the inferences generated by the
posting system. A system that has contradictory assertions will have
different issues, but they won't be discussed here. And one would hope that
the creators of domain D would send their specialized knowledge about the FO
type to the FO technical committee, to be included if there are no
objections. Once again, we try to get all of these necessary relations into
the Fo as soon as possible. (012)
But, let us accept that adding assertions about things in the FO ontology
(which gives the FO+M considered as one ontology) does change the meaning of
those things that *directly* appear in the added assertions, such as humans
in the above example. The issue I am concerned with is whether this will
defeat the purpose of the FO in an interoperability scenario. I believe
that the answer is no, that accurate interoperability is still supported,
and this will require that more specifics for the interoperability scenario
be described (I did try to go through this in a previous email, and in the
online ppt, but perhaps in inadequate detail. Here I will try harder). For
this scenario let us assume that two systems have both specified the
meanings of their elements using the same FO (same version, no differences).
Simpler yet, no new primitives exist in either domain ontology. (013)
Receiving system S1 wants to use information INF that system S2 has placed
on the internet. Since posting system S2 group wants its knowledge to be
reused, they place not only the information expressed using their ontology
FO+M, but also place the logical specification of all new ontology elements
in M that were not in the FO. System S1 already has the FO, and now, to
properly interpret information that is based on FO+M and relate that to its
own information, receiving system S1 has to create a merged ontology that
includes the FO, M, and S1's own domain ontology DO1. Developing a merging
engine will be one of the tasks for the FO project. The merging process will
have several performance requirements:
(1) The merging engine will have to be able to recognize logical
contradictions between M and DO1. If there are contradictions, this will
raise additional issues, but for the simple case assume that there are no
logical contradictions. Since both M and DO1 are specified using only
elements in the FO, this should be possible.
(2) The merging engine will have to recognize elements in M and DO1 that are
identical, and de-replicate. This is true even if M and DO1 use different
logically compatible views of the same entity: the views will need to be
normalized.
(3) Then there is a more difficult step: domain ontologies M and DO1 may
have representations of the same intended meaning (same set of reference
objects in the real world), but they may have different sets of necessary
conditions for the instance types. (This is a consequence of allowing only
necessary conditions rather than only necessary and sufficient in the domain
ontologies). For a subtype DO1C of some class FOC in the FO that exists in
DO1 but not in M, it may not be possible to be certain that any given
instance of FOC referenced in M is or is not an instance of DO1C; it will
only be recognizable as an instance of FOC. This may limit the usability of
the information in INF for system S1, but that is the best we can hope for.
We can only use information that we have. As mentioned above, the default
assumption cold be that, if one system asserts a property of some type in
the FO, then that property is assumed to be true unless it generates a
contradiction. Some users may not want to make that assumption, it can be a
local user option.
(4) At this point system S1 will be able to derive the same inferences from
the posted data INF as can system S2. System S1 may also be able to derive
additional inferences that are not derived in FO+M, because it has
additional axioms in DO1. This is normal for human-human information
transfer as well, and does not impair what I consider to be "accurate
interoperability". This type of ambiguity may be mitigated (but not
eliminated) by maintaining a database (in the same location as the FO) of
unique well-known or well-described instances of types in the FO and public
extensions. It is also anticipated that, in addition to the FO itself, the
FO site will maintain a collection of mid-level and domain extension
ontologies that are specified using the FO, which will form a lattice of
theories. Ideally, a natural-language interface will ease search for
particular elements within this set of ontologies, to avoid duplicated
effort.
(5) If the two systems S1 and S2 can communicate, and want to transfer
information as accurately as possible, both of them can do the merger
process, and then both will derive the same inferences from the same data,
using the automatically merged FO+M+DO1. They will both check that the
merged ontology does not alter the intended usage of the data in their
applications. (014)
So, when two systems using the FO as a basis for their ontologies want to
communicate, there is an automatic process that can support accurate
interoperability, via a common merged ontology. If there is only one-way
communication (eg via internet posting), the posted information will be
interpreted correctly (the inferences will contain all of those inferred by
FO+M, and none of those will contradict inferences drawn by FO+DO1), but may
not be fully integrated with existing information held by S1 because of
potential ambiguity of the information in INF. (015)
I do not doubt that everyone on this list can think of some additional
*potential* problems with this process. But the first question to be
answered is: is there a better process to support very broad semantic
interoperability with the same accuracy? (016)
The above comments distinguish two different issues that can be discussed
separately: (Issue1) do we actually *want* every meaning in the FO itself to
change when a new element is added, or do we have criteria of performance
for the FO that guard against unintended changes? (I would use a test
application suite to detect and avoid unintended changes) And
(Issue2) given that the meanings of domain types will differ when different
specialized types are created in domain ontologies, how will this affect the
performance of the FO as a support for interoperability? (There will be no
contradictions, but less certainly as to whether inferences about a given
subtype in one domain do or do not apply to the parent type or a different
subtype in another domain). (017)
PatC (018)
Patrick Cassidy
MICRA, Inc.
908-561-3416
cell: 908-565-4053
cassidy@xxxxxxxxx (019)
_________________________________________________________________
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
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (020)
|