Difference between revisions of "Inverse Relations"

From Developer Documents
Jump to navigation Jump to search
Line 1: Line 1:
 
According to [[Layer0_ontology|Layer0]] semantics, relations <em>can</em> have inverse relations. For the database and client this means that when claiming new statements <code>(s, p, o)</code> using
 
According to [[Layer0_ontology|Layer0]] semantics, relations <em>can</em> have inverse relations. For the database and client this means that when claiming new statements <code>(s, p, o)</code> using
 
  WriteGraph.claim(Resource subject, Resource predicate, Resource object)
 
  WriteGraph.claim(Resource subject, Resource predicate, Resource object)
an inverse statement <code>(o, inv(p), s)</code> will be automatically claimed into the database. Some statements are such that they tend to raise the degree of the resource (amount of incoming/outgoing relations) to very large numbers. The database is not built to efficiently handle such resources. One such relation is <code>InstanceOf</code> which is a statement that pretty much each and every resource in the database has. It does not have an inverse relation, but considering it had one, here's what would happen. For example, for each <code>L0.String</code> instance created an inverse statement would be added <code>(L0.String, L0.HasInstance, :L0.String)</code> statement into the database, thereby enlarging the degree of statements of <code>L0.String</code>. When working with larger databases this would most likely become a problem.
+
an inverse statement <code>(o, inv(p), s)</code> will be automatically claimed into the database. Some statements are such that they tend to raise the degree of the resource (amount of incoming/outgoing relations) to very large numbers. The database is not built to efficiently handle such resources. One such relation is ''InstanceOf'' which is a statement that pretty much each and every resource in the database has. It does not have an inverse relation, but considering it had one like ''HasInstance'', here's what would happen. For example, for each ''L0.String'' instance created an inverse statement would be added <code>(L0.String, L0.HasInstance, :L0.String)</code> statement into the database, thereby enlarging the degree of statements of ''L0.String''. When working with larger databases this would most likely become a problem.
  
 
To make it possible to optimize this situation we provide the possibility to skip adding of inverse relations when claiming statements into the database by using
 
To make it possible to optimize this situation we provide the possibility to skip adding of inverse relations when claiming statements into the database by using
 
  WriteGraph.claim(Resource subject, Resource predicate, Resource inverse, Resource object)
 
  WriteGraph.claim(Resource subject, Resource predicate, Resource inverse, Resource object)
with a <code>null</code> inverse relation argument to create the sensitive statements such as InstanceOf-relations.
+
with a <code>null</code> inverse relation argument to create the sensitive statements such as ''InstanceOf''-relations.

Revision as of 12:40, 29 September 2010

According to Layer0 semantics, relations can have inverse relations. For the database and client this means that when claiming new statements (s, p, o) using

WriteGraph.claim(Resource subject, Resource predicate, Resource object)

an inverse statement (o, inv(p), s) will be automatically claimed into the database. Some statements are such that they tend to raise the degree of the resource (amount of incoming/outgoing relations) to very large numbers. The database is not built to efficiently handle such resources. One such relation is InstanceOf which is a statement that pretty much each and every resource in the database has. It does not have an inverse relation, but considering it had one like HasInstance, here's what would happen. For example, for each L0.String instance created an inverse statement would be added (L0.String, L0.HasInstance, :L0.String) statement into the database, thereby enlarging the degree of statements of L0.String. When working with larger databases this would most likely become a problem.

To make it possible to optimize this situation we provide the possibility to skip adding of inverse relations when claiming statements into the database by using

WriteGraph.claim(Resource subject, Resource predicate, Resource inverse, Resource object)

with a null inverse relation argument to create the sensitive statements such as InstanceOf-relations.