I wish that real systems matched some of the mathematical elegance
that John Sowa's
detailed note displayed. (01)
To elaborate a little on the real world interoperability issues, I
have addressed, please look at a single property of a Person to denote
the status of marriage for an individual. (02)
On one system (let's call it ACME), there is a property named MARRIAGE
STATUS with the following values:
MARRIED
SINGLE (03)
on another system (let's call it ENTERPRISE), there is a property
named MARITAL STATUS with the following values:
DIVORCED
MARRIED
NEVER MARRIED
SEPARATED
UNKNOWN
WIDOWED (04)
On the face of it, these are both compatible, but in actuality there
is only easy interoperability in one direction, from ENTERPRISE to
ACME, but not from ACME to ENTERPRISE. (05)
ENTERPRISE > ACME (06)
DIVORCED > SINGLE
MARRIED > MARRIED
NEVER MARRIED > SINGLE
SEPARATED > MARRIED
UNKNOWN > ????
WIDOWED > SINGLE (07)
If the ACME system can not store an answer to this property, the
UNKNOWN case can just be ignored by not storing any answer. (08)
The opposite direction (from ACME to ENTERPRISE) is fraught with
arbitrary solutions. (09)
Perhaps the real problem is that even with this (real) example, there
is the builtin 3D mind set that says what is stored in the system
right now is true since the last change. This formulation doesn't have
the idea of a date of transition (Wedding Date, Death Date of Spouse,
Divorce Date, Separation Date) or that this concept of
Status_of_Marriage is actually not static at all but is fluid. (010)
David Whitten
7138703834 (011)
On Fri, Sep 19, 2014 at 10:15 AM, John F Sowa <sowa@xxxxxxxxxxx> wrote:
> In another forum, I sent a note about using the terms 'generalization'
> and 'specialization' as a way to clarify relationships among ontologies
> (or any theories of any kind).
>
> In particular, they provide a convenient way to specify the conditions
> for interoperability among theories and the systems they describe:
>
> 1. Definition. A theory A is a generalization of a theory B iff B
> entails A: every model for which B is true is also a model for A.
> If A is a generalization of B, then B is a specialization of A.
>
> 2. Even when those two words aren't used, the concept is implicit.
> In Cyc, for example, they are the basis for the partial ordering
> of microtheories: every microtheory is a specialization of
> (entails) the theories above it in the hierarchy.
>
> 3. As another example, Schema.org is a very general (underspecified)
> collection of types (or classes) that many developers adopted for
> applications that are inconsistent with one another. But the
> theories that specify those applications (explicitly or implicitly)
> are all specializations of Schema.org.
>
> 4. If data d is specified in a general theory, such as Schema.org, and
> used a more specialized theory X, all properties of d specified in
> the general theory may be assumed in X. But any property P that
> is not specified in the general theory may be used in X only after
> a test such as "If P(d), then ..."
>
> 5. With these two terms, the conditions for interoperability among
> two theories A and B (or any systems that are specified by or
> described by A and B) can be stated:
>
> a) If two theories A and B are inconsistent in their details,
> they can interoperate on shared data that is specified by
> a common generalization C.
>
> b) To use data specified in C, neither A nor B may assume any
> properties of that data not specified in C. But they can use
> the details in conditionals that begin "If x has property P ..."
>
> c) Points 5a and 5b are implicit in the way interoperable systems
> work. The spec's for the data on which interoperability is
> required are the common generalization C. Any property not
> specified in C can only be used in A or B after an appropriate
> test.
>
> The generalization/specialization distinction can also clarify other
> relationships, practical and theoretical. For example, we have often
> discussed issues about defaults, open worlds vs close worlds, and
> related problems in nonmonotonic reasoning.
>
> But every proof in a nonmonotonic logic can be converted to a proof
> in a monotonic (classical) logic from a suitably revised theory 
> because each nonmon step adds, deletes, or modifies a monotonic axiom.
>
> After the nonmon proof has finished, it's possible to gather up all
> the monotonic axioms into one purely classical theory, from which an
> equivalent proof can be carried out with classical rules of inference.
>
> In terms of generalization/specialization, every nonmon proof
> corresponds to a walk in a lattice of classical theories. The full
> lattice may be infinite, but only a finite set of nodes are used
> for any application: The number of nodes is equal to the number
> of steps in the nonmon proof.
>
> Summary: The terms 'generalization' and 'specialization' can be
> used to explain and clarify a wide range of issues, both practical
> and theoretical.
>
> John
>
> _________________________________________________________________
> Message Archives: http://ontolog.cim3.net/forum/ontologforum/
> Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontologforum/
> Unsubscribe: mailto:ontologforumleave@xxxxxxxxxxxxxxxx
> Shared Files: http://ontolog.cim3.net/file/
> Community Wiki: http://ontolog.cim3.net/wiki/
> To join: http://ontolog.cim3.net/cgibin/wiki.pl?WikiHomePage#nid1J
> (012)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontologforum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontologforum/
Unsubscribe: mailto:ontologforumleave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgibin/wiki.pl?WikiHomePage#nid1J (013)
