Frank,
We use triplets
(subject, relation, object) where the relation is a concept of the
same kind as subject and object, just as you describe in your
plan.
It has a lot of advantages.
Not being tied to a
fixed set of relations is the biggest.
When you work with
this, in the way we ended up, you can isolate categories of
relations. We built code extensively around these categories and
it
can be exploited to generate/suggest relations.
Categories we
isolated so far:
Syntactical
We compose complex
concepts using a 'syntactical' category with the concepts: head,
modifier (variations), pre-postpositions, … Some of this might not
make sense for you, but we actually generate the concept
descriptions
automatically by parsing the semantic network of a concept and
generate the language translation for it.
A side note here,
the head-relation defaults as the type-of, but can be overwritten
is
need be.
Semantic
While all these
relations are somewhat semantic there is a category that fits the
name best. The classic type-of and part-of are in here but also
e.g
'for the purpose of' which is a composite. Prepositions and
postpositions play a big role here and are optional on their
respective ends of the relation. Sometimes the preposition is the
only relation, it might have a semantic net attached that
specified
exactly how it is meant to be interpreted.
Type defining
We do have
currently
a set of relations that are specifically used to define types but
I
suspect they will disappear in the future because they can be
automatically derived. We use them to some extent for modelling
and to
generate code (e.g. xsd schemas) to import structured data. The
relations here are the typical optional/mandatory single/multiple
value/feature combinations.
Our composites can
inherit both values and features from their types, and the type by
default is the head of a phrase.
Watch out for
knowledge definition loops!
They are most likely the reason your system has a 'headache'.
Tom Knorr
The NeuroCollective