On 9/7/2011 12:31 PM, Rich Cooper wrote:
> 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. (01)
Those two operations can be expressed in logic. For example,
the property P could be defined as a conjunction of other properties
(or attributes or features or facets or whatever you want to call them): (02)
P = p1 & p2 & ... & pN (03)
If you remove a property from P, you get a more general property Q
that is implied by P: If P, then Q. (04)
If you add another property to P, you get a more specialized
property R that implies P: If R, the P. (05)
Basic principle: More general properties are true of a larger
number of cases, and more specialized properties are true of
a smaller number of cases. (06)
The more special case implies the more general case. But you
can use logics with more operators than just conjunction. (07)
> ... many programming languages (Delphi) also restrict type
> constructors to only have singular inheritance which avoids
> the very possibility of introducing consistency errors. (08)
That is a brute-force method. It's better to use development
tools that are guaranteed to ensure all and only the valid
generalizations. There are many such tools. (09)
> 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... (010)
What you need are better development tools that don't introduce
inconsistencies *and* can detect and eliminate any inconsistencies
that may be lurking. (011)
If you recall the earlier discussions with Rick Murphy, he was
recommending methods based on intuitionistic logic that generate
combinations that are computationally efficient to check. (012)
Description logics use a different choice of operators that
also generate combinations that can be checked automatically. (013)
Another computational method, which uses a logic that is a subset
of both DLs and intuitionistic logic, is Formal Concept Analysis
(FCA). The only operator that FCA methods use for defining
properties is conjunction. That creates a very a simple logic
that supports highly efficient tools. (014)
In fact, many people use FCA tools to verify that ontologies
defined in OWL are consistent. But you can also use FCA tools
to *generate* the definitions automatically. See (015)
http://www.upriss.org.uk/fca/fca.html (016)
You can find more info about using FCA to check consistency
of OWL ontologies by typing three keywords to Google: (017)
FCA OWL concept (018)
You need the word 'concept' to avoid many extraneous hits. (019)
Important caveat: these logics (DLs, intuitionistic logic, and FCA)
are *subsets* of FOL. They are useful for defining the hierarchy
(whether you call it type, concept, generalization, or subsumption).
But they are *not* general purpose knowledge representation languages.
You need more general logics in order to specify everything you need
to say (or to program). (020)
John (021)
_________________________________________________________________
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 (022)
|