One misstatement in my last post: <<To answer one of your questions, if you want to view the changes in an Ensemble session, you will need to insert into http://tb-session regardless of how you do the script. >>
Live/Ensemble will now propagate changes made to a graph to any graph importing it. In this case it means that if you open, let's say http://topbraid.org/examples/kennedys in Ensemble, and run a script with an INSERT INTO <http://topbraid.org/examples/kennedys>, the changes will be propagated to http://tb-session. Hence you do not always need to have a script module that explicitly inserts into http://tb-session -- Scott On Apr 28, 7:59 pm, Scott Henninger <[email protected]> wrote: > Arthur; What you seem to be indicating is that you want data to be > created in real-time, such as creating a label from first and last > name when one of those values changes. Is it the case that you always > need to generate labels, ala doing an inference in Composer? > > If I'm understanding your scenario right, what you want is the > following: > a) An Ensemble user edits a field > b) The field is associated with rules that generates some data > c) That data is displayed in Ensemble > > What I would suggest is to view your model (kennedys in the example) > as a data back-end. When the user edits data, use a relay to invoke a > script that edits that model. When the model is opened again, the > data will be there without the need to run inferences again. The > complication is that you also need to make this information available > to the current session in Ensemble -http://tb-session. > > To answer one of your questions, if you want to view the changes in an > Ensemble session, you will need to insert intohttp://tb-session > regardless of how you do the script. > > Internally, the rules from b) are encoded as SPIN rules. There are > drawbacks and advantages to this. The big win is that the rules are > stored in your model. This is an important feature of SPIN. The > drawback is that it uses an inference model. I.e. triples are > created, then you need to figure out what to do with them. And yes, > it is monotonic reasoning, so you can't retract anything - as in your > label example in item 3. > > Particularly if removing triples is an issue for you inference alone > won't get you all the way there. This is where SPARQLMotion and > PerformUpdate (SPARQL MODIFY) come into play. In the end, the best > way to do item 3, remove old labels and create a new one, is to use > SPARQL MODIFY/INSERT/DELETE where the WHERE clause defines the > resource being modified for both insert and delete. > > <...I assume this would run any spin:Construct attached to Person as > well.> > > If you mean spin:constructor, then no, this is not the case. However, > you can run TopSPIN on any sub-property of spin:query, including > spin:constructor, by specifying the property in the sml:predicate of > sml:ApplyTopSPIN. > > -- Scott > > On Apr 28, 5:53 pm, Arthur Keen <[email protected]> wrote: > > > Thanks, that clears up the mystery of where Sparql motion scripts actually > > run and what tb-session really is. > > > Armed with a new mental model of the architecture that you have given me, > > this is what I understand that I would need to do using the Kennedy's > > example: > > > 1) If I would like to open the Kennedy's model in Ensemble and would like > > to see the inferred labels, then I need to trigger inference on the server > > with an SMS; the inference occurs on the server, the triples are updated > > on the server, and added to <http://tb-session>, so they are visible on > > Ensemble. > > > 2) If I would like see an inferred label when I add a Person from Ensemble, > > then I should create an SMS to create e.g., Joe Blow on the server, run > > inferences and insert the inferred triples into <http://tb-session> so that > > the label (Blow, Joe) will be available in Ensemble. I assume this would > > run any spin:Construct attached to Person as well. > > > 3)If I would like to change change the name of a Person and would like to > > see the inferred label updated in Ensemble, e.g., change Joe Bow to Jan > > Blauw, then I would need to create an SMS to change the first name and last > > name on the server, run inferences (possibly remove the triple for the old > > label as I have seen a lot of duplicate labels when I change Person Names) > > so that the label (Blauw, Jan) would update in Ensemble for the person > > formerly known as Joe Blow and insert into <http://tb-session> > > > Or would it be better to hit save after making changes in Ensemble and then > > run an SMS that triggers inferencing on the server and inserts into > > <http://tb-session> so the results are made available to Ensemble? > > > Is this how one would have to approach this? > > > Arthur > > > On Apr 28, 2010, at 1:28 PM, Scott Henninger wrote: > > > > A few follow-ups ;-) A key to this is understanding that Ensemble is > > > a client only. All actions are on cached data and all processing > > > occurs on the server. > > > > <...when using the local live server...> > > > > aka Personal Server - seehttp://www.topquadrant.com/products/TB_Live.html > > > > <Is the incremental reasoning happening in the client or server?> > > > > All scripts are executed server-side. This is where the SPARQLMotion > > > engine resides. SPIN inferences are executed through the TopSPIN > > > module in the script. To view the results client-side you need to > > > insert values into thehttp://tb-sessiongraph. > > > > <how does incremental reasoning work in Ensemble?> > > > > There is no incremental reasoning from a SPARQLMotion script. The > > > script module executes TopSPIN, running all rules. It may appear > > > "incremental" because new inferences will be included. Incremental > > > inferencing is a Composer feature that triggers off of an edit (in > > > Composer) and runs only the rules applicable to that property. This > > > is not currently available from Ensemble. > > > > <I also noticed that the local live using jetty does an immediate > > > write through to the server every time you enter a new value in > > > ensemble> > > > > No, this isn't the case. What happens is almost like TBL Enterprise > > > Server (TBL-ES). TBC-ME acts like the server in that it makes changes > > > to a cached copy. That's the file that opens in Composer that > > > displays the dirty bit (the * in the file tab). All of the changes > > > will be in the cached copy, but if you close the file without saving, > > > you will notice that the changes are not written to the disk copy. > > > > The only current difference between TBL Personal Server (TBC-ME > > > localhost) and TBL Enterprise Server (TBL) is that "Save Data" does > > > nothing in TBL Personal Server. That will be fixed in a subsequent > > > release so that TBL-PS will save the cached copy just as is done in > > > TBL-ES. > > > > <How does the latter behavior impact incremental reasoning?> > > > > The key to understanding the relationship is that the TopSPIN engine > > > is being called from a SPARQLMotion script, not from Composer's UI. > > > Hence the real question is "How does the latter behavior affect my > > > script?" And that is basically the previous question. > > > > Hopefully that helps clarify things a bit... > > > -- Scott > > > > On Apr 28, 12:52 pm, Arthur Keen <[email protected]> wrote: > > >> Scott, > > > >> Thanks very much for the example. It shows that triggering reasoning in > > >> ensemble is really easy. A follow up question: how does incremental > > >> reasoning work in Ensemble? I have noticed that if you set topspin to > > >> perform incremental reasoning in topbraid composer, then when using the > > >> local live server, the incremental changes show up in Ensemble client > > >> whenever you enter a values in ensemble that trigger inferencing. Is > > >> the incremental reasoning happening in the client or server? I also > > >> noticed that the local live using jetty does an immediate write through > > >> to the server every time you enter a new value in ensemble, so you see > > >> changes in the server whenever you make changes from an ensemble client, > > >> whereas our live server running in tomcat keeps changes local till you > > >> click "save data" - How does the latter behavior impact incremental > > >> reasoning? > > > >> Thanks > > >> Arthur > > > >> On Apr 27, 2010, at 2:24 PM, Scott Henninger wrote: > > > >>> It may be the case that you only need to run inferences some of the > > >>> time. For example, you may want to leave it to the user to choose > > >>> when inferences and scripts are executed, as it is done in Composer. > > >>> We can do that with a couple of changes to the previous examples. > > > >>> In this case, we'll leave the relay out and have the user choose to > > >>> execute inferences on items displayed in the grid. Do the following: > > > >>> 1) Remove the relay or re-start with the Default Application. Close > > >>> the example files without saving any changes, > > > >>> 2) In Composer, open the CreateKennedys SPIN function (spin:Modules/ > > >>> spin:Functions/CreateKennedys) in CreateKennedysLabels.sms.ttl. > > > >>> 3) In the spin:constraint property, use the context button to choose > > >>> "Create From SPIN Template" > > > >>> 4) Choose sml:SelectedResourceArgument in the upper-left. > > > >>> 5) We want this function to be available when an instance of > > >>> kennedys:Person is chosen. This is controlled by the valueType > > >>> property. Add kennedys:Person to this - since the script does not > > >>> import the data file, use the full URL: <http://topbraid.org/examples/ > > >>> kennedysEnsembleExample#Person> > > > >>> 6) Perform a Scripts > Refresh/Display SPARQLMotion functions… to > > >>> register the SPIN function changes > > > >>> 7) Open the kennedysEnsembleExample with the default app in Ensemble. > > >>> Choose an instance of Person in the Grid. > > > >>> 8) Click on the SPARQLMotion icon ("cog" icon) and choose "Create > > >>> Kennedys labels". The script described in the previous post will be > > >>> executed and the labels will appear in the Grid. > > > >>> This kind of behavior can be done in a number of contexts and give you > > >>> full control over when inferences are executed. Since it is done > > >>> through scripts, there is much more flexibility, as you can control > > >>> which triples inferences are executed against, which inference pieces > > >>> are displayed in Ensemble, combinations of inference engines can be > > >>> executed, etc. > > > >>> Hopefully this is enough to get some people started. If there are > > >>> questions or this isn't quite meeting your needs, please let us know. > > > >>> -- Scott > > > >>> On Apr 27, 2:05 pm, Scott Henninger <[email protected]> > > >>> wrote: > > >>>> I am > > ... > > read more » -- You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include TopBraid Composer, TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/topbraid-users?hl=en
