Frank,
I think so.
“owner” is a
bad example since I would represent it as a role of a instance of
a
“system”.
The interpretation
is somewhat reversible. I would write it as
X (type system) has
owner (human role) A (who is a person) .
There were reasons
to do
this, but I have to find them. I think it was easier to process
when you access the data.
'Owner' has a type
override as 'human role'.
'Human role' is a
composite with 'role' as 'head' and 'human' as 'adjectival
modifier'.
You could 'index'
by
'human role' or 'role' or refine the role even more
We generate the
textual presentation (label) of concept both in the search and
presentation, so either component of the triplet could be a rather
complex phrase.
My 'type defining'
relations would come into play when defining 'system'
(System, has
multiple mandatory inherited property, owner)
You would not be
able to add System X without entering also an owner, in this case.
The semantic
relations are more in the direction of:
dinner table ::=
(table, for the purpose of, eating dinner)
typical composition
of the relation here is:
(preposition) →
(noun | verb/gerund) → (postposition)
but either
component
is optional, except relation != <empty> must be true
You notice
that the semantic interpretation is not reversible
you can search for
'dinner table' and get 'table for the purpose of eating dinner'
there are overrides
at
play that we do through the language interface,
'for' is an
abbreviation for 'for the purpose of' (in this case) as opposed to
the 'for' that abbreviates 'for duration of'. Our system expands
the
label of the concept to be most specific when it interfaces with
SME's. This is a bit annoying sometimes but allows to craft very
precise semantic nets. If we have it generate a 'human optimized'
output it runs an 'optimizer' just like a compiler that
detects redundancy and removes context that is obvious.
So a label could
come up as 'table for eating dinner', 'eating dinner' of course is
abbreviated as 'dining',
so 'table for dining', getting closer, but still not 'dinner
table'.
Anyway, not really
part of your question.
Any relations, no
matter what category can be a index. Also, if you allow composite
relations, the types of these provide supersets of indexes....
Tom
On 06/12/2014 12:34 PM, Frank Guerino
wrote:
Hi Tom,
You wrote: "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."
I believe this is equivalent
to what I specified in #2, which is that each Predicate acts
as a Index, which I believe would act as an isolated category.
So, for example, if I have Relationships like the following…
"Person A" is related as an
"Owner" of "System X"
"Person B" is related as an
"Owner" of "System Y"
"Person A" is related as an "Owner" of "System Z"
"Person B" is related as an "Owner" of "Animal M"
"Person B" is related as an "Owner" of "Animal N"
"Organization C is related as an "Owner" of "Service O"
The Predicate "Owner" is now a Index to all Source Nodes that
are related as owners as well as to all Target Nodes that are
owned, regardless of either side's type(s). This Index is, by
itself, seems to be a topic, even without categorizing it as
"Syntactical", "Semantic", or "Type Defining". Correct?
My Best,
Frank
--
Frank
Guerino, Chairman
The International Foundation
for Information Technology (IF4IT)
http://www.if4it.com
1.908.294.5191 (M)
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