On 27/01/2011 8:23 PM, Rich Cooper wrote:
> Hi Pat C, and Doug F,
>
> I agree with both Pat C and Doug F on your views - Doug focuses on the
> description of the class, which I view as the Type structure of a system,
> while Pat C focuses on the interactions and complexity actually encountered
> in a static Type structured application. Both of your are correct in your
> assessments, though still not quite complete in the conclusion.
>
> Re the Reuse of "Type Standard"s, the "Reusable Software" argument dates
> from the invention of software by Turing. It works to some extent, which
> turns out to be limited in practice.
>
> Ontologies will likely follow a similar path - copying ontocomponents and
> reusing them leads to further problems encountered when the components are
> individually instantiated, and then reused in an UNANTICIPATED application
> NOT KNOWN AT TIME 0. The problems you didn't forsee, and that your
> component designers hadn't anticipated by the specific use you made of them,
> will be encountered. (01)
This is not all that different from traditional software development. It
requires a testing phase to verify that the new configuration of
ontologies works as planned. (02)
> It is an excellent argument; IMHO, I'm in favor of keeping reuse of
> ontologies as a practical goal in some ontocomponents that turn out to be
> successfully reused a few times, but it still doesn't solve the ultimate
> problem of building a System entirely from specifications to meet
> requirements in every case and every situation conceivable encounterable.
>
The design has to focus on reusability since if one person can not use
another person's ontology in combination with ontologies that the
original ontologists did not consider, then they just become works of
academic interest.
As an application developer, I have to be able to take ontologies from
many sources and weave them into a functional description of my
organization's universe which will be different from most others.
> Approaching the limit of that refinement process, there are more and more
> new components to choose from. But then the time it takes to negotiate
> which one to choose will drive A's and B's negotiations.
>
> It is possible to automate capture of ontology specifications, requirements,
> and designs on a component basis, but not possible to build new, valid ones
> entirely from old ones in most practical cases. What is missing in the
> formula is the knowledge still remaining to be abstracted, IMHO.
>
> Is it possible to place a requirement on any reusable ontocomponent that
> it's design and implementation meet and exceed any application required of
> it? If so, then ontocomponent reuse is justified, otherwise maybe not.
>
> -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 Patrick Cassidy
> Sent: Thursday, January 27, 2011 3:26 PM
> To: doug@xxxxxxxxxx; '[ontolog-forum] '
> Subject: Re: [ontolog-forum] Categorical Views of a Universe
>
> Some discussion of comments posted by Doug Foxvog:
>
> [DF]>
>> I'm not sure that the "one true universal viewpoint" is useful. The
>> truly universal part would be quite small. Some fields of endeavor
>> would deal with non-physical objects such as financial accounts, while
>> others deal with anatomy or shipping of physical objects.
>>
> This is true, but skips over a very important point: one can have a
> well-structured basic foundation ontology that has **all** of the primitive
> elements used in any of the domain ontologies that use it as the foundation,
> **but** none of the domain ontologies need include all of those primitive
> elements. Thus, while the set of ontology elements used in **every**
> application may be very small (perhaps zero, or just the logical
> primitives), the set of primitives needed to support interoperability among
> **all** of those domains may be fairly substantial. I am estimating at this
> point that is will be close to 10,000, but to get a realistic estimate one
> needs experience trying to use primitives for interoperability among a
> representatively large sample of domain applications.
> To avoid the unnecessary overhead of including all primitives in every
> application, one needs is a mechanism to extract from the "Primitive
> Inventory Foundation Ontology" (PIFO) only those primitive elements needed
> to construct the domain ontology. And inversely, when two domains need to
> interoperate, there needs to be a mechanism to automatically create a
> "merged ontology" including all of the primitives of both domain ontologies,
> plus, perhaps, some additional primitives needed to translate between those
> domains (for example, if for efficiency the domains use overlapping concepts
> that have can themselves be broken into smaller primitives, rather than the
> smaller primitives). This is how I visualize getting the best of all
> worlds - the efficiency of slim domain ontologies with the ability to
> interoperate accurately and automatically with other domains when necessary.
>
> [DF]>
>> A network of interconnected ontologies on different subject matter or
>> ways of looking at the universe (e.g., 3D vs. 4D) is what John Sowa and
>> i, among others have been promoting.
>>
> And I agree, but I think it is critically important, if one is interested
> in accurate automatic interoperability, to recognize that the links
> ("connections") can be created automatically at run time when needed, rather
> than be hand crafted one-to-one for every pair of ontologies that might
> someday want to interoperate. That is where the PIFO provides a mechanism,
> and where I have not found anything even close in effectiveness in other
> approaches such as automated mapping from independently developed (non-PIFO
> based) ontologies.
I can't imagine how I would test and certify the correct operation of an
application that determined its own view of the universe at run-time.
Debugging a failed transaction would be a nightmare.
My view is that the metadata and the ontologist's description of the
ontology's features and incompatibilities will have to reviewed in the
context of the application's goals to select the correct mixture of
ontologies.
> Automated mapping using the PIFO can create the "lattice of theories"
> that John Sowa has discussed, provided that the non-primitive elements of
> each theory are constructed from elements in the PIFO.
>
> Pat
>
> 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
>
>
>
> _________________________________________________________________
> 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
>
> (03)
_________________________________________________________________
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 (04)
|