ontolog-forum
[Top] [All Lists]

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

To: "'[ontolog-forum] '" <ontolog-forum@xxxxxxxxxxxxxxxx>, "'Rich Cooper'" <rich@xxxxxxxxxxxxxxxxxxxxxx>
From: "Matthew West" <dr.matthew.west@xxxxxxxxx>
Date: Fri, 9 Sep 2011 08:00:38 +0100
Message-id: <4e69b998.87c5e30a.061b.ffffb38d@xxxxxxxxxxxxx>
Dear Rich,    (01)

I'll give you some guidelines:    (02)

1. Stop thinking of inheritance and specialisation as being synonymous.
Inheritance of properties can happen through other relationships as well.
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.
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).
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.    (03)

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

Regards    (05)

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/    (06)

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.    (07)



> -----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...
> 
> __________________________________________________
> _______________
> Message Archives:
> http://ontolog.cim3.net/forum/ontolog-forum/
> Config Subscr:
> http://ontolog.cim3.net/mailman/listinfo/ontolog-f
> orum/
> 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?WikiHomePa
> ge#nid1J
> 
> 
> 
> _________________________________________________________________
> 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
>     (08)


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

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