Jack, both properties in your two examples are calculated. It doesn't seem like ranges change, but rather the values change. This is certainly covered by SPIN
Sent from my iPhone > On Jun 18, 2014, at 4:22 PM, Jack Hodges <jhodgesa...@gmail.com> wrote: > > Irene and Holger, > > Thank you for the replies. That would certainly match one of the contexts of > my question very well. That context is where the value of one property is > dependent on the value of another property (in your example, the value for > ex:country determines the choices for the values of ex:state). > > A second scenario is where a numeric value of one property is dependent on an > expression involving the value of another property: > > - there is a class ex:Object > - there is another property ex:velocity > - there is another property ex:mass > - there is a property ex:momentum = ex:velocity x ex:mass > > The values of these properties might be classes (e.g., Velocity or Mass) but > at least we could require that they be Velocity or Mass of the same Object. > > My original question (a third scenario), however, was even broader > (inter-class rather than intra-class dependencies): > > - there is a class ex:MomentumConservationOfEnergyStaticCollision > - with a property ex:object1 (range ex:Object) > - with a property ex:object2 (range ex:Object) > - with a property ex:newVelocity = ex:object1 :momentum / ex:object2 :mass > > Now we have a situation where, given instances of Object o1 and o2, with > their respective masses and velocities, we could calculate a new velocity > given a static collision. This is obviously a fictitious example but the idea > is to determine the value of a property based on the values of another > class'es property. Would the same mechanism you described apply in this case > as well? > > Jack > >> On Tuesday, June 17, 2014 3:33:23 PM UTC-7, Jack Hodges wrote: >> I was wondering if TBC supports the notion of value dependencies. For >> example, I might want to say the following: >> >> if <someClass>.<someProperty> has a value, then >> <thisClass>.<someOtherProperty> must be in this range >> otherwise <thisClass>.<someOtherProperty> must be in this other range. >> >> I have written it as a rule because dependencies generally look like rules. >> Does SPIN allow us to capture these kinds of dependencies? >> >> Jack > > -- > -- You received this message because you are subscribed to the Google > Group "TopBraid Suite Users", the topics of which include Enterprise > Vocabulary Network (EVN), TopBraid Composer, TopBraid Live, TopBraid Insight, > SPARQLMotion, SPARQL Web Pages and SPIN. > To post to this group, send email to > topbraid-users@googlegroups.com > To unsubscribe from this group, send email to > topbraid-users+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/topbraid-users?hl=en > --- > You received this message because you are subscribed to the Google Groups > "TopBraid Suite Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to topbraid-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- -- You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary Network (EVN), TopBraid Composer, TopBraid Live, TopBraid Insight, SPARQLMotion, SPARQL Web Pages and SPIN. To post to this group, send email to topbraid-users@googlegroups.com To unsubscribe from this group, send email to topbraid-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/topbraid-users?hl=en --- You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
