Pat, (01)
I'm delighted that we have found an area of agreement. (02)
PC> John makes a point clear that I don't recall being explicitly
> discussed previously.
> Good point: (03)
JFS>> 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. (04)
Yes. This shows some ways of using the hierarchy in methodologies
for developing and relating ontologies. (05)
PC> 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. (06)
I agree. In fact, the same theory in the hierarchy might be part
of packages with different "brand names": SUMO 9.6 and Dolce 7.3. (07)
PC> 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.... (08)
I agree. But this is a practice that must be integrated with
the methodologies for using ontologies in various fields.
The hierarchy doesn't automatically solve the problems, but it
provides a framework in which they can be discussed. (09)
PC> 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. (010)
That is indeed an important approach, and it is one of the reasons
for using a generalization/specialization hierarchy. (011)
PC> 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... (012)
There are many such issues to be discussed. I'd like to make the
following observations: (013)
1. The hierarchy of theories doesn't automatically solve all
the problems. (014)
2. But by showing the interdependencies among theories, it can
delimit the area (subhierarchy) that is affected by any change. (015)
3. And by showing all siblings of any given theory, it can help
designers evaluate the alternatives. (016)
In short, it can't hurt, and it may be very helpful. (017)
John (018)
_________________________________________________________________
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 (019)
|