Mike,
Re:
> [PC] > 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.
>
>
> [Mike Bennet] Why would anyone want the resulting ontology to assert that,
in the
> real world there are humans and there is a special subtype of humans who
> happen to be descended from early hominids in Africa? Aren't we all?
> Who are these others? (01)
What I said was that the **logical** effect of adding a necessary
condition to some class is to create a subtype of that original class:
whether or not there are instances not belonging to that subtype or whether
the subtype is intended to replace the existing class are questions of fact
and options of usage. The logical effect holds regardless of what we decide
to do with that new subtype. (02)
Perhaps a different way of looking at this case will make the point
clearer:
If domain ontology M asserts some new necessary condition about a class
in the FO (say, in effect creating class CM), and if that condition is
specified using existing elements in the FO, then any user ontology system U
using the FO will be able to properly *interpret* assertions about that
class CM. And, if the using system merges its own ontology with domain
ontology M, it will also be able to reason to see how the assertions in
ontology M affect entities of interest to the developers of U.
Now, being able to properly *interpret* an assertion does not mean that
any system is forced to *believe* it. When a system uses an external M
(specified using the FO) to interpret data modeled by that ontology M, all
it is doing is saying (03)
"**IF** the assertions in M are true,
**THEN** this is what the implications are for things of interest to me". (04)
This is what I do when I read new information, and what the computers can
do if all the ontologies are specified using a common FO. The question of
whether to trust or believe information received is a totally different
question from whether it can be properly interpreted. It is the ability to
interpret that I am concerned about. (05)
The developers of user ontology U have the option of adding the assertions
of M to its own ontology, or rejecting them completely. No matter, ontology
U will be able to interpret the information that was posted and determine
its relevance to their purposes. (06)
For the example case, the reasoning would be of the sort "If all humans are
descended from African Hominids, then the information INF implies that . .
." (07)
Pat (08)
Patrick Cassidy
MICRA, Inc.
908-561-3416
cell: 908-565-4053
cassidy@xxxxxxxxx (09)
> -----Original Message-----
> From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-
> bounces@xxxxxxxxxxxxxxxx] On Behalf Of Mike Bennett
> Sent: Thursday, March 04, 2010 8:05 AM
> To: [ontolog-forum]
> Subject: Re: [ontolog-forum] Foundation ontology, CYC, and Mapping
>
> Just one comment:
>
> PC> 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.
>
>
> Why would anyone want the resulting ontology to assert that, in the
> real
> world there are humans and there is a special subtype of humans who
> happen to be descended from early hominids in Africa? Aren't we all?
> Who
> are these others?
>
> What worries me is that this results in something which appears to make
> an assertion about the real world which is at variance with the real
> world, namely that the new class of humans are a sub-type in reality,
> which they are not.
>
> Perhaps some other model relationship, other than generalization /
> specialization, is needed for ontology interoperation. If one creates
> something the result of which is at variance with reality, how is one
> to
> explain to a business user (the real people who we hope will see some
> benefit in ontologies and review them for business accuracy), that the
> ontology now has some special meaning for this relationship.
>
> Perhaps the answer is some kind of formal notation of context or
> perspective. I don't know. But (ab)using existing model relationships
> which have a well understood meaning, surely can't be the answer?
>
> Mike
>
> Patrick Cassidy wrote:
> > A response to Pat Hayes's note on changes in meaning:
> >
> >
> >> [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?
> >>
> >>
> >
> > [[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.
> >
> >
> >> [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.
> >>
> >
> > [[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.
> >
> >
> >
> >> [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.
> >>
> >
> > [[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.
> >
> >
> >> [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.
> >>
> >>
> >
> > [[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).
> >
> >
> >> [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
> >>
> >>
> >
> > [[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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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?
> >
> > 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).
> >
> > PatC
> >
> > Patrick Cassidy
> > MICRA, Inc.
> > 908-561-3416
> > cell: 908-565-4053
> > cassidy@xxxxxxxxx
> >
> >
> >
> >
> >
> > _________________________________________________________________
> > 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
> >
> >
> >
> >
>
>
> --
> Mike Bennett
> Director
> Hypercube Ltd.
> 89 Worship Street
> London EC2A 2BF
> Tel: +44 (0) 20 7917 9522
> Mob: +44 (0) 7721 420 730
> www.hypercube.co.uk
> Registered in England and Wales No. 2461068
>
>
> _________________________________________________________________
> 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
> (010)
_________________________________________________________________
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 (011)
|