Good morning, Catrina; Some responses below > Question #3 was: > 3) When a SPIN function is created in order to set a > SPARQLMotion script available for use by Ensemble, > is it possible to have a spin:body value on this > SPIN function? > > And your answer was: > No, you need to use sml:returnModule to link a the > SPIN function to a SPARQLMotion script. Ensemble > uses the name of the function to call the > SPARQLMotion script. > > Is that included in any of the documentation that shows how to create > published scripts for Ensemble (SPARQLMotion scripts that are attached > to SPIN functions to enable them to be called from Ensemble)?
It is in the Developing TBE Applications document you refer to below. See the Advanced Topics section on page 19. > > I couldn't find anything about what you can or can't do with spin:body > on these types of SPIN functions, but my source was mainly TopBraid's > Developing TBE Applications document. I found the documentation about > creating and executing other SPIN functions such as the Kennedys > examples, but didn't really find anything more on SPIN functions > attached to SPARQLMotion scripts. The purpose of the spin:body property is for defining SPARQL queries that define a SPIN function. Currently, the main sources of documentation for SPIN are: http://spinrdf.org/ http://composing-the-semantic-web.blogspot.com/2009/01/understanding-spin-functions.html We can work to get more of this information into the Help pages. > > My question #4 was: > 4) Is is possible to have a SPARQLMotion file > publish as both .sms and .spin? > > For example, if I have a SPARQLMotion script > that contains a script that is to be executed > from Ensemble and the script itself needs to > call a SPIN function local to the current > SPARQLMotion script file, how can I have both > the sms and spin published and available from > Ensemble? > > Your answer: > If the SPIN function is registered, I.e. defined > as a SPIN function, placed in a .spin file, and > the file read into the workspace, then the function > will be available to all models in the workspace. > This works in Ensemble as well as Composer. > > I think the answer to my question with my desired example use is > 'No'. Am I understanding that correctly? I believe the answer is 'yes' as you have the options to: 1) Define the SPIN functions in the .sms file 2) Import the SPIN functions into the .sms file 3) Define the SPIN functions in a .spin file That covers all possibilities, I believe. If there is a case in which this is not working for you, please let us know. > > It sounds like that if I need to call other SPIN functions (where the > return module is not set and my function needs to return something > like an instance of a class or a property value) from a published > SPARQLMotion script, then the other SPIN functions must be put into a > separate file. Just to be clear on how this works; you have a SPARQLMotion script that you want to run from Ensemble. There needs to be some way for Ensemble (or Web services) to call that script. The mechanism Composer-ME/Live uses is the SPIN function. SPIN functions act like a function call. Arguments can be passed to the function call, the function performs some processing, and returns a value. When Ensemble calls a SPIN function, the function definition (type of spin:Function - hence the subclassing of spin:Functions) is invoked. If the definition has a spin:body, then that is called. If the definition has a sm:returnModule, then that is called. (If the definition has a spinx:javaScriptCpde or a spinx:javaScriptFile, then the defined JavaScript is called.) Any combination of these can be defined and used in a model. The only definition is defining what the function does - processes a SPARQL query, invoke a SM script, call a JavaScript function, etc. > > In the end I will need at least 2 files: > One file will be an '.sms' file and contain my SPARQLMotion > script attached to a SPIN function that has a sm:returnModule set to a > script module such as an sml:ReturnText module. > The second file will be a '.spin' file and will have to house > some or all of the other SPIN functions that are needed and are not > attached to the script itself via a sm:returnModule (I understand I > can choose to put these in one or more '.spin' files). These types of > functions that I'm referring to are something like the :getCurrentYear > or :getFather SPIN functions. The functions that need to return > something like an instance or literal. Not necessarily two files (see above),. This depend on whether or not you need to reuse the SPIN functions in other models. If you need to do this, then it would be a good idea to separate the files. If the SPIN functions are used exclusively by the scripts, then it may be better to define the SPIN functions in the same file (the .sms file). -- Scott --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TopBraid Composer Users" group. 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-composer-users?hl=en -~----------~----~----~----~------~----~------~--~---
