Hi Arthur,
incremental TopSPIN mode currently does not iterate, i.e. the
iteration flag is ignored. This is because iterating might be slow and
cause other undesirable side effects, including very long loops.
As a result of this, the order of rules matters: if the Cube rule is
executed first, then the Box rule can work with the new triples.
Otherwise, length, height and width are not available yet and the Cube
rule does nothing.
As far as I can tell, there is also no mechanism yet in incremental
TopSPIN to define the order of rules. There is a rather undocumented
property spin:ruleIndex that might be used for that purpose in the
future, or maybe a policy to execute superclass rules first, or
whatever.
I will put both issues on our list of feature requests. In the
meantime, you will only get the desired inferences after running full
inferences.
Regards,
Holger
On May 5, 2009, at 4:47 PM, Arthur Keen wrote:
> I created a toy example to better understand spin before setting it
> loose on a larger model and have a question on incremental reasoning
> with iteration. I am using TBCM3.0 and the inference engine is
> TopSpin set to incremental reasoning with iteration
>
> The example involves calculation of volume on a box and cube.
> I defined the class Polyhedron (owl:Class) with subclass Box
> (owl:Class) with owl:DatatypeProperty length, breadth, and height
> and defined a spin:rule that calculates volume - incremental
> reasoning works as expected, i.e., it calculates the volume whenever
> I change a dimension.
>
> Next I defined the RegularPolyhedron (owl:Class) as a subclass of
> Polyhedron with owl:DatatypeProperty side xsd:float
> and Defined Cube (owl:Class) to be a subclass of Box and Regular
> Polyhedron
> and created a spin:rule to populate the inherited length, width, and
> height xsd:float owl:DatatypeProperty.
>
> When I instantiate a Cube and assign a value to side, the side value
> is propagated to the length, width, and height dimensions inherited
> from Box, but the volume is not computed by the spin:rule on Box. I
> have to explicitly run the inference engine to get it to compute the
> volume. How can I avoid this situation? Is multiple inheritance
> causing the problem, or is there an execution order dependency on
> the spin:rules, e.g., least specific first, that is causing this, or
> is it simply not being triggered by the derived quantities, or...?
>
> thanks
> Arthur
>
> illustration of class lattice:
>
> Polyhedron
> / \
> RegularPolyhedron {side} Box {spin:rule area := length * width
> * height}
> \ /
> Cube {spin:rule length = side;
> width :=side; height := side}
>
>
>
> spin:rule on Box
>
> CONSTRUCT {
> ?this :volume ?volume .
> }
> WHERE {
> ?this :length ?length .
> ?this :width ?width .
> ?this :height ?height .
> LET (?volume := ((?length * ?width) * ?height)) .
> }
>
>
> spin:rule on Cube
>
> CONSTRUCT {
> ?this :width ?side .
> ?this :height ?side .
> ?this :length ?side .
> }
> WHERE {
> ?this :side ?side .
> }
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TopBraid Composer Users" group.
To post to this group, send email to topbraid-composer-users@googlegroups.com
To unsubscribe from this group, send email to
topbraid-composer-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/topbraid-composer-users?hl=en
-~----------~----~----~----~------~----~------~--~---
