Difference between revisions of "Inverse Relations"
| 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 | + | 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.
