Overview
I propose here a series of changes, with various degrees of confidence
depending on the cases, for the sumo importer. I will update this page
as measure as more changes come to my attention.
SUMO instance should be translated as Member not Inheritance
Currently expressions like
are translated as
The problem is that then the instance can be used (in SUMO) as
object, function, relationship, etc, and not generally as subclass.
For instance inverse
in file Merge.kif
(instance inverse BinaryPredicate)
(inverse husband wife)
is translated as
(InheritanceLink (stv 1.000000 1.000000)
(ConceptNode "inverse" (stv 0.010000 1.000000)) ; [7690791279017416557][1]
(ConceptNode "BinaryPredicate" (stv 0.010000 1.000000)) ; [6410280537314717277][1]
) ; [11635137124257520146][1]
(EvaluationLink (stv 1.000000 1.000000)
(PredicateNode "inverse" (stv 0.100000 1.000000)) ; [7691424597714988965][1]
(ListLink
(ConceptNode "husband" (stv 0.010000 1.000000)) ; [7336481066825120890][1]
(ConceptNode "wife" (stv 0.010000 1.000000)) ; [2015412845701781066][1]
) ; [13937302832202503127][1]
) ; [11051686663622052499][1]
creating 2 inconsistent terms for inverse
, one being a concept, the other
being a predicate. Instead it should be
(MemberLink (stv 1.000000 1.000000)
(PredicateNode "inverse" (stv 0.010000 1.000000)) ; [7690791279017416557][1]
(ConceptNode "BinaryPredicate" (stv 0.010000 1.000000)) ; [6410280537314717277][1]
) ; [11635137124257520146][1]
(EvaluationLink (stv 1.000000 1.000000)
(PredicateNode "inverse" (stv 0.100000 1.000000)) ; [7691424597714988965][1]
(ListLink
(ConceptNode "husband" (stv 0.010000 1.000000)) ; [7336481066825120890][1]
(ConceptNode "wife" (stv 0.010000 1.000000)) ; [2015412845701781066][1]
) ; [13937302832202503127][1]
) ; [11051686663622052499][1]
The link type of the instance (PredicateNode
, etc) will have to be
determined by looking at the SUMO subclass it belongs to (for instance
an instance of BinaryPredicate
will be a PredicateNode
). This is
more difficult than what is currently done but more semantically
sound.
Forall, exists, etc
[EDIT: the following is probability a bad idea and needs to be more carefully thought].
I noticed that in most cases SUMO forall
are followed by =>
which
could be translated into a mere ImplicationScopeLink
where the
variables in the forall
would become the variables in the
ImplicationScopeLink
. It could also be a ForAllLink
wrapping an
ImplicationLink
over TVs, but I'd rather avoid this because I fear
it would lead to confusions and misuses. Using the
ImplicationScopeLink
is simpler and more alligned with the usual
conditional probabilistic interpretation.
Although since SUMO is crisp, unless we start attaching probabilities
(Ben, you mentioned wordnet and word2vec, but I don't understand
specifically how that would be done), using an ImplicationScopeLink
is good enough anyway. Then for the cases when SUMO forall
is
not followed by =>
, I would suggest to use an AverageLink
or
equivalently a LambdaLink
, as a opposed to a ForAllLink
, because
the semantics of AverageLink
/LambdaLink
is closer to
ImplicationScopeLink
(it is merely an ImplicationScopeLink
with
the universe as implicant) than the semantics of ForAllLink
as
defined in the PLN book. But then to be consistent the SUMO exists
should not be translated into ExistsLink
but instead rewritten as
Not
LambdaLink
<vardecl>
Not
<body>
which is kinda messy. One might then want to define an alternative
exists link type equivalent to that, maybe called
AverageBasedExistsLink
(although it's an awkward name). Or use the
existing ExistsLink
but it should be clear that the semantics, in
the non-crisp cases anyway, is different than the one defined in the
PLN book.
Support SUMO row variables
Row variables (starting with @
) should be translated into GlobNode
or wrapped in a ListLink
, or have its type defined as such.