At 10:58 AM 4/18/2003 -0400, Patrick Cassidy wrote:
> > In a frame system, a slot simply means there's a relation that
> > may be provided between an instance of the class on which it is
> > defined, and its filler. In a first order logic system, the
> > relation means exactly what is specified by its associated axioms.
> > If you want to do the
> > axioms first, that renders the Protege modelling step irrelevant.
> If one wants to first use Protege only to define a tentative
>class hierarchy, that would be OK as a first step. But as soon
>as we start to add properties and relations, I think it is
>important to define the relations carefully. (02)
If you are proposing to use Protege to create the class hierarchy only, and
then switch to coding in KIF once we create relations and axioms, that
sounds fine to me. (03)
>used in SUMO are fine. We just have to agree on which
>ones to use. (04)
I think the question would be, are there any you would like to exclude, and
if so, why? Otherwise we can just use all of them. Every axiom that one
excludes makes the semantics of the terms weaker, so we should only exclude
an axiom for a good reason. (05)
> I think that the axioms should be included
>as soon as a relation is asserted between classes (or
>instances of classes).
> A macro predicate feature is not **needed** to define the
>axiomatic meanings of predicates (neither is Protege or
>the SUMO browser). It is **convenient** and perspicuous for
>cases where similar predicates are used to specify the meanings
>of multiple relations. I think that anything that simplifies the
>tasks of creating and understanding a complex ontology should be
>given careful consideration. The SUMO browser is valuable
>for that reason, not because it is needed. (06)
That's a puzzling answer. A near infinite set of things might be useful in
different situations. Why are you advocating rule macro predicates in this
situation? What specific problem with the UBL formalization is it
addressing? If it is relevant, do you have a formal definition of its
> I am not fully familiar with SUMO, but I do not recall seeing
>a mechanism for specifying probabilistic relations. How are they
A prior question would have to be, why are probabilities needed? Is there
a particular use case you are thinking of? The UBL models I've seen don't
seem to address this. (09)
> I will be out of contact now for a week.
>MICRA, Inc. || (908) 561-3416
>735 Belvidere Ave. || (908) 668-5252 (if no answer)
>Plainfield, NJ 07062-2054 || (908) 668-5904 (fax)
>Adam Pease wrote:
>> I'm not really sure what you're asking, nor am I clear on why Cyc's
>> macro features are relevant. They're certainly not needed for a precise
>> axiomatic definition of terms.
>> In a frame system, a slot simply means there's a relation that may be
>> provided between an instance of the class on which it is defined, and
>> its filler. In a first order logic system, the relation means exactly
>> what is specified by its associated axioms. If you want to do the
>> axioms first, that renders the Protege modelling step irrelevant.
>> I should also mention that the precise semantics of the general notion
>> of a Relation is already carefully and axiomatically defined in SUMO.
>>At 10:17 PM 4/17/2003 -0400, Patrick Cassidy wrote:
>>>I have a suggestion about what I think needs to be done
>>>even before we get to Adam's step 1, creating an
>>>ontology in protege. Specifically, we need to
>>>decide how to specify what the relations between
>>>the classes (slots in Protege, predicates in SUMO)
>>>are intended to mean. The meaning of the predicate,
>>>for example (hasPart Automobile Engine) would need
>>>to be specified by axioms unless there is a default
>>>interpretation of such predicates.
>>> Cyc has one mechanism to simplify the applications
>>>of axiomatic rules, the RuleMacroPredicate. For
>>>the "part" predicate, one might use the RuleMacroPredicate
>>>"relationAllExists", and apply it thus:
>>>(relationAllExists hasPart Automobile Engine)
>>>This would mean that for every instance of an Automobile
>>>there has to be at least one object of class Engine.
>>>There would have to be additional constraints, such as
>>>that the Part must be smaller than the whole object.
>>>We also have to decide whether, e.g. an automobile is still
>>>an automobile if the engine has been removed for repair --
>>>i.e. can we say we have an 'Automobile" if it is
>>>disassembled? We also need to decide how to indicate
>>>that some objects have optional parts (chrome trim?),
>>>and I would like to have a mechanism for indicating
>>>probabilities of relations (this gets into encyclopedic
>>>knowledge, but we at least need the mechanism even if it
>>>is not often used in the earliest stages).
>>> I interpret Adam's suggested methodology to mean that
>>>we can get into such details later, in stage 2, but
>>>I think that they should be tackled at the earliest stage,
>>>since the relations are central to the interpretation of
>>>he meanings of the classes. We don't need to get into
>>>philosophical dialogues, but we do need some firm
>>>criteria for deciding whether we do or don't have an
>>>automobile in our garage at any given time.
>>> I will be away for the next week and will check
>>>back when I return.
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (012)