I think so.
“owner” is a
bad example since I would represent it as a role of a instance of
is somewhat reversible. I would write it as
X (type system) has
owner (human role) A (who is a person) .
There were reasons
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
You could 'index'
'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
My 'type defining'
relations would come into play when defining 'system'
multiple mandatory inherited property, owner)
You would not be
able to add System X without entering also an owner, in this case.
relations are more in the direction of:
dinner table ::=
(table, for the purpose of, eating dinner)
of the relation here is:
(noun | verb/gerund) → (postposition)
is optional, except relation != <empty> must be true
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
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
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
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....
On 06/12/2014 12:34 PM, Frank Guerino
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
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?
The International Foundation
for Information Technology (IF4IT)
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.
tied to a fixed set of relations is the biggest.
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
we isolated so far:
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.
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.
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.
composites can inherit both values and features from their
types, and the type by default is the head of a phrase.
for knowledge definition loops! They are most likely the
reason your system has a 'headache'.