[Top] [All Lists]

Re: [ontolog-forum] Requesting Opinions on the Benefits of Predicates as

To: Frank Guerino <Frank.Guerino@xxxxxxxxx>, "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: tknorr <tknorr@xxxxxxxxxxxxxxxxxxx>
Date: Thu, 12 Jun 2014 13:46:14 -0700
Message-id: <539A1196.2020108@xxxxxxxxxxxxxxxxxxx>


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....


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 Guerino, Chairman
The International Foundation for Information Technology (IF4IT)
1.908.294.5191 (M)

From: tknorr <tknorr@xxxxxxxxxxxxxxxxxxx>
Reply-To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
Date: Wednesday, June 11, 2014 1:09 PM
To: <ontolog-forum@xxxxxxxxxxxxxxxx>
Subject: Re: [ontolog-forum] Requesting Opinions on the Benefits of Predicates as Nodes


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:


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.


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

Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J    (01)

<Prev in Thread] Current Thread [Next in Thread>