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.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent