I agree with the technical point John has made in this post, and John makes
a point clear that I don't recall being explicitly discussed previously.
Good point:
[JS]> > The solution to these issues is very simple:
>
> 1. Adopt a hierarchy of theories in which the theories *never* change.
>
> 2. Each modification of a theory by addition creates a new theory
> that is more specialized than the original.
>
> 3, Each modification by deletion creates a new theory that is more
> general than the original.
>
> 4. The URIs that point to the theories are always guaranteed to
> point to a version that *never* changes. Each modified version
> must be a different theory in the hierarchy with its own URI.
>
> This approach ensures that users can always rely on a given URI
> to point to theory that never changes. (01)
I have a little terminological addendum: those who are maintaining a
particular ontology through several changes will want to refer to it by the
same base name, plus version. This of course is purely terminological and
doesn't affect John's points, nor the logical implication. (02)
This still leaves the problem of how an FO (or any ontology that changes
over versions) can support accurate interoperability - even diachronic
interoperability for the same organization using the same base ontology
(plus or minus revisions) at different times. (03)
For those applications that want to use a common FO for interoperability
there might be an issue if different versions of the FO are used. (Since
John prefers "FO" to be more general, let us refer to the FO as I had
suggested it to be the "PIFO" - "Primitive Inventory Foundation Ontology" -
which includes some elements that are not primitives and is truly an
ontology, not just a list of elements). The same issue arises when an
application uses only a portion of the PIFO to logically specify the
meanings of its ontology elements (the remainder are not needed for the
application and are left out to improve performance). As I had envisioned
the use of the PIFO for interoperability, any two agents/applications that
want to interoperate need to first assert the actual set of ontology
elements that they use (all based on the PIFO) so that those ontologies can
be automatically merged to produce a common ontology that would produce the
same inferences from the same data. As part of that merger process, each
interoperating system would have to declare what portion of the PIFO it used
in its local application. This raises a question I haven't previously
discussed, namely the necessity, in extracting a portion of the PIFO for
purpose of efficiency, that the local system do test runs using the whole
PIFO so that the local system can verify that portions left out would have
no effects on the actual intended processing of the data elements, and that
the effects are confined to reducing the efficiency of the process. Such
test runs should provide some assurance that when two different portions of
the PIFO are merged they will still produce the same intended results as the
original portions. (04)
Another tactic for dealing with the possibly unintended results of changes
to remote ontology elements is to confine most reasoning within
"microtheories", as CYC does. Then changes to other microtheories will not
affect reasoning within a given microtheory. But since we started this
thread discussing changes to the PIFO, the issue will remain for two systems
that are using different version of the PIFO (which, as John and PatH have
explained, are in fact different theories). (05)
What I think most programmers will want is that the behavior they desire for
their programs not change due to changes in the knowledge model, unless they
specifically intend that change. Preserving that behavior is a problem that
will have to be dealt with in any change to a data model used by an
application. Perhaps we can refer to that behavior as the "relevant
meanings" of the data elements, and then we can leave the general term
"meaning" to be used as desired in other contexts. I expect that most
ontology user will want the relevant meanings of most elements to remain
constant even when later versions of an ontology are used. Changes to
computational behavior should optimally be predictable, and when not, at
least desirable. (06)
Pat (07)
Patrick Cassidy
MICRA, Inc.
908-561-3416
cell: 908-565-4053
cassidy@xxxxxxxxx (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
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (09)
|