Concerning the use of Protege, axioms, macro predicates, and probability: (01)
[Adam Pease]:
>> > 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.
>>
[Pat Cassidy]
>> 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.
[Adam Pease]:
>
> 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.
> (02)
No, I think that Protege can also be used to record many of the
relations, but I think we should have an accurate translation of the
relations between KIF and Protege. The axioms could also be
recorded in Protege as "PAL-constraints", but I am not sure
if there is good reason to do it that way. For me, Protege is
merely a useful tool to visualize hierarchies and the inherited
relations among the classes of an ontology. I don't think of it
as the only tool one should use. It's a matter of taste. If some
users don't find it convenient, they can ignore it. The definitive
statement of the ontology can be in KIF or some other logical
language. (03)
---------------------------------------
[PC]
>> Axioms as used in SUMO are fine. We just have to agree on which
>> ones to use.
>
[AP]
> 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.
>
The point I was trying to make is **not** that there are axioms in
SUMO that need to be excluded (I haven't checked them for consistency)
but that whenever we create a relation, it should be carefully
axiomatized and we should be quite clear what is intended. For
example, just creating a relation "father-of" and leaving it to the
user to understand the implications would not, in my opinion, be a
useful procedure. There is some axiomatization of the relation
"father" in SUMO, but more would be needed (e.g. the implication of
an impregnation event, a birth event, and relative ages of the
participants) to capture what is understood by people. This doesn't
mean that what is in SUMO is in any sense incorrect, but that it may
not be enough to enable the inferences that are important for the
tasks that we can envision. (04)
-----------------------------------
[PC]
>> 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.
>
[AP]
> 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 semantics?
> (05)
One of the useful rule macro predicates in OpenCyc is
#$relationAllExists, which specifies the necessary existence of
some instance of an argument for each instance of another argument
in binary predicates. There are over 600 uses of this macro
predicate in OpenCyc. I think it is useful because it is
the necessary relations that create what I think of as the
"definitions" of classes -- the necessary conditions for what
constitutes membership. This rule macro predicate merely
provides a shorthand way of asserting the relation; the
axioms specifying the necessary relations could all be written out
in full, but given the number of times it is used, this particular
rule macro predicate will, I believe, help to make understanding
and use of an ontology easier. I believe that this macro predicate
is equivalent in Protege to specifying the "cardinality" facet of a
slot as "at least 1". (06)
The OpenCyc documentation states: (07)
(#$comment #$relationAllExists "(#$relationAllExists PRED COL1 COL2)
means that for any instance INST1 of COL1, there exists some instance
INST2 of COL2 such that (PRED INST1 INST2) holds.
(#$relationAllExists PRED COL1 COL2) is thus redundant with a
commonly-encountered form of rule. So #$relationAllExists (and its
defining axiom; see #$expansion) enables this common type of rule to
be stated more tersely. Moreover, (forthcoming) code support will
enable type-level inferencing with #$relationAllExists.") (08)
The macro is defined as below:
Given a legal sentence: (Arg1 Arg2 Arg3)
where Arg1 is a binary predicate
the assertion (relationAllExists Arg1 Arg2 Arg3) has
the expansion: (09)
(implies (isa ?TERM :ARG2)
(thereExists ?OTHER
(and
(isa ?OTHER :ARG3)
(:ARG1 ?TERM ?OTHER)))) (010)
----------------------------------
[PC]
>> I am not fully familiar with SUMO, but I do not recall seeing
>> a mechanism for specifying probabilistic relations. How are they
>> represented?
>
[AP]
> 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.
>
There are many times when one might want to represent probabilistic
information. In the business context, an umbrella manufacturer
might know, for example, that 50% of the umbrellas sold are red, 20%
green, and 30% blue -- and would want to adjust manufacturing ratios
to avoid wasted inventory. Or, it could be useful to know that
over 95% of automobiles built after 1990 have radios in them, or
that if a customer has a home phone number and business phone number
one is more likely to contact him/her at the business number during
business hours and at the home number in the evenings and weekends.
What would be the best way to represent such knowledge in SUMO? If a
representation of probabilistic information is not yet in the UBL
specification, it might very well be an important addition. (011)
Pat (012)
=============================================
Patrick Cassidy (013)
MICRA, Inc. || (908) 561-3416
735 Belvidere Ave. || (908) 668-5252 (if no answer)
Plainfield, NJ 07062-2054 || (908) 668-5904 (fax) (014)
internet: cassidy@xxxxxxxxx
============================================= (015)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Unsubscribe/Config:
http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (016)
|