ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Universal and categories in BFO & DOLCE

To: "'[ontolog-forum] '" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Rich Cooper" <rich@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 9 Sep 2011 11:20:21 -0700
Message-id: <5156A6E0083E416DA58B4C8C15E403EE@Gateway>
Dear Matthew,    (01)

Comments below,
-Rich    (02)

Sincerely,
Rich Cooper
EnglishLogicKernel.com
Rich AT EnglishLogicKernel DOT com
9 4 9 \ 5 2 5 - 5 7 1 2    (03)

-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On
Behalf Of Matthew West
Sent: Friday, September 09, 2011 12:01 AM
To: '[ontolog-forum] '; 'Rich Cooper'
Subject: Re: [ontolog-forum] Universal and
categories in BFO & DOLCE    (04)

        Dear Rich,    (05)

        I'll give you some guidelines:    (06)

        1. Stop thinking of inheritance and
specialisation as being synonymous.
        Inheritance of properties can happen
through other relationships as well.    (07)

Interesting thought, thanks.    (08)

        2. Think in set theoretic terms. So each
member of a subset is a member of
        the superset. If a method belongs to the
superset, it is not "inherited" by
        the subset, but it applies to each member
of the subset because it is also a
        member of the superset.    (09)

Yes, inheritance is simply an organization method.
But sets are organized around elements that have a
consistent organization.  I am thinking in terms
somewhat like Beth Levin's idea which she called
verb alternations.  In those cases, sentences
(elements of the set) have different structures,
so that what Roger Shank called a PTrans (physical
transfer) is about a distinct concept that is
different from a MTrans (mental transfer, i.e.
information).  Also, the representation of an
MTrans is inherently different - both subject and
object end up with a copy of the information,
while in a PTrans, the subject no longer has the
physical object which has been moved to the direct
object's location or control.  Such differences
are logical situations, and have much less
consistent representations of before and after
situation expressions.      (010)

        3. Do not override methods in a subset.
This is an indication that the
        method did not apply to the superset in
the first place (because if it did,
        it would apply to all members of the
subset necessarily).    (011)

But the English word Put would apply to both
MTrans and PTrans meanings, as well as many
others.  It could be transitive with a direct
object, or intransitive; modulated by adverbs,
qualifications, elaborated wh* phrases, and so on.
Each such signature class is different, and using
a Link Grammar parser to set up the signatures
given a corpus, there are lots of such potential
signature classes.      (012)

So by definition, the partitioning of Put
sentences into those subcategorized partitions
(among the hundreds of Put interpretations) is
very complex and hard to match against that
advice.  Do you have some more specific advice
given the sentential nature of the problem?  That
advice is very useful for typical programming
situations, but those situations are dealt with
manually, one at a time, by a programmer.  I am
trying to find a way to automate the conversion of
a corpus of sentences, through parsing into
signature classes, to construct a case base which
is consistent, in some sense of that word, with
English meanings.      (013)

        4. Be careful to separate out methods that
apply to the object represented
        from those that operate on the
representation. The representation objects
        are objects in their own right. A method
that parses the VIN for a car to
        find the engine size does not operate on a
car, but on an identifier.    (014)

        Not necessarily complete or sufficient,
but a start in being able to use
        multiple superset structures without
creating inconsistencies.    (015)

        Regards    (016)

        Matthew West                            
        Information  Junction
        Tel: +44 1489 880185
        Mobile: +44 750 3385279
        Skype: dr.matthew.west
        matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx
        http://www.informationjunction.co.uk/
        http://www.matthew-west.org.uk/    (017)

Thanks so much!  This gives me more dimension on
the problem to think about and could be very
helpful - only time will tell.      (018)

-Rich    (019)

        This email originates from Information
Junction Ltd. Registered in England
        and Wales No. 6632177.
        Registered office: 2 Brookside, Meadow
Way, Letchworth Garden City,
        Hertfordshire, SG6 3JE.    (020)



        > -----Original Message-----
        > From:
ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-
        > bounces@xxxxxxxxxxxxxxxx] On Behalf Of
Rich Cooper
        > Sent: 07 September 2011 17:31
        > To: '[ontolog-forum] '
        > Subject: Re: [ontolog-forum] Universal
and categories in BFO & DOLCE
        > 
        > Dear John,
        > 
        > Generalization removes a property or
method from
        > the old type to create a new type, while
        > specialization adds a property or method
to the
        > old type to create the new type, by
definition.
        > As a result of strict application of
these
        > definitions, the result is a hierarchy
by
        > construction.
        > 
        > Perhaps INFO and DOLCE only offer such
well formed
        > instances (I am not familiar with
either), as many
        > programming languages (Delphi) also
restrict type
        > constructors to only have singular
inheritance
        > which avoids the very possibility of
introducing
        > consistency errors.
        > 
        > But what about languages with multiple
inheritance
        > (C++ etc) where the new type is a
combination of
        > old type properties and methods, given
that the
        > specific new type definition ALSO leaves
out some
        > of the properties and methods of the old
types?
        > That would make a lattice rather than a
hierarchy.
        > The problem is that the constructors
might
        > introduce inconsistencies that are based
on
        > combining properties and methods of an
old type
        > with contradictory properties and
methods of
        > another old type.
        > 
        > Can you expound on such constructions?
They
        > certainly can lead to some very ugly new
types,
        > yet serendipitously produce interesting
ones.  Is
        > there any rule you can give that would
make the
        > new type ALWAYS be a valid one (whatever
valid
        > means) by construction, or must every
new type so
        > formed be checked individually for
consistency?
        > 
        > Curiously,
        > -Rich
        > 
        > Sincerely,
        > Rich Cooper
        > EnglishLogicKernel.com
        > Rich AT EnglishLogicKernel DOT com
        > 9 4 9 \ 5 2 5 - 5 7 1 2
        > 
        > -----Original Message-----
        > From:
ontolog-forum-bounces@xxxxxxxxxxxxxxxx
        >
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On
        > Behalf Of John F. Sowa
        > Sent: Wednesday, September 07, 2011 7:16
AM
        > To: ontolog-forum@xxxxxxxxxxxxxxxx
        > Subject: Re: [ontolog-forum] Universal
and
        > categories in BFO & DOLCE
        > 
        > Since there was some recent discussion
about
        > generalization
        > and specialization in this thread, I
decided to
        > check Google
        > for the phrase "generalization
specialization
        > hierarchy".
        > There were 3,520 hits, of which the
first one was
        > 
        > 
        >
http://people.cs.vt.edu/~kafura/cs2704/generalizat
        > ion.html
        > 
        > This is Section 1.6 of the class notes
for a
        > course at
        > Virginia Tech.  (Excerpts below.)
        > 
        > It has a clear definition of the terms
with good
        > examples
        > that apply to both ontology and software
design.
        > 
        > John
        >
__________________________________________________
        > ____________
        > 
        > The following notes are based on
preprints for the
        > book
        > _Object Oriented Software Design and
Construction_
        > by Dennis Kafura, Prentice-Hall, 2000.
        > 
        > 1.6 Generalization
        > 
        > Generalization identifies commonalities
among a
        > set of entities.
        > The commonality may be of attributes,
behavior, or
        > both. For example,
        > a statement such as "All windows have a
title"
        > expresses a common
        > attribute among all entities that are
considered
        > windows. Similarly,
        > the statement, "All windows can be
resized."
        > expresses a common
        > behavior that all windows provide.
Generalizations
        > are usually easy
        > to recognize as they contain words like
"all" and
        > "every".
        > 
        > Generalization may be defined as:
        > 
        > Generalization -- the identification,
and possible
        > organization,
        > of common properties of abstractions.
        > 
        > This definition shows that
generalization is not
        > abstraction although
        > the two are often confused. Abstraction
aims at
        > simplifying the
        > description of an entity while
generalization
        > looks for common
        > properties among these abstractions...
        > 
        > One of the four forms of generalization
is
        > hierarchy. In the case of
        > hierarchy, the commonalities are
organized into a
        > tree structured form.
        > At the root of any subtree are found all
the
        > attributes and behavior
        > common to all of the descendants of that
root.
        > This particular kind of
        > tree structure is referred to as a
        > generalization/specialization
        > hierarchy because the root provides more
general
        > properties shared by
        > all its descendants while the
descendants
        > typically add specializing
        > properties which make them distinct
among their
        > siblings and their
        > siblings' descendants.
        > 
        > The second form of generalization is
genericity.
        > In the case of
        > genericity, the commonality is expressed
with the
        > aid of a parameter.
        > Various specializations are
distinguished by what
        > they provide for the
        > parameter. For example, using genericity
it is
        > possible to represent the
        > common properties of a "stack" through
the
        > generalization of a "stack of
        > anything", where "anything" represents
the
        > parameter. Specialized forms
        > of this generalization are "stack of
integers" and
        > "stack of characters".
        > 
        > The third form of generalization is
polymorphism.
        > Polymorphism captures
        > commonality in algorithms. An algorithm
may have a
        > nested if-then-else
        > (or case statement) logic which tests
for the
        > exact type of an object
        > which it is manipulating. the algorithm
performs
        > some operations on the
        > object based on the exact type of the
object.
        > However, in many algorithm
        > the operations to be performed are the
same, only
        > the type of the object
        > on which they are performed varies.
Polymorphism
        > allows this nested
        > logic (or case statement) to be
collapsed to a
        > single case in which the
        > different object types are treated in a
uniform
        > manner. Through a
        > mechanism called dynamic binding, the
algorithm
        > allows the object to
        > determine which of its operations to
perform in
        > response to the
        > algorithms invocation...
        > 
        > The fourth form of generalization is
patterns. A
        > pattern expresses a
        > general solution (the key components and
        > relationships) to a commonly
        > occurring design problem. The attributes
and
        > behavior of the individual
        > components are only partially defined to
allow the
        > pattern to be
        > interpreted and applied to a wide range
of
        > situations. For example, a
        > "wheeled vehicle" pattern might be
defined in
        > terms of the components
        > "wheel", "axle", "frame", "body" and
"power
        > source". The pattern would
        > also show how these components would be
arranged
        > in relation to each
        > other (e.g., the axle must connect two
wheels).
        > The pattern could be
        > interpreted in many different ways to
solve
        > particular problems that
        > differ in their requirements for speed,
        > durability, payload, fuel
        > source, available materials, and other
factors.
        > Example of the wheeled
        > vehicle pattern are "automobile",
"horse-drawn
        > carriage", "ox cart",
        > "moon buggy" and many others...
        > 
        > _____________________________     (021)

<<attachment: winmail.dat>>


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

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