Okay, thanks Scott.
I was referring to the spin:body in the documentation (Application
Development Guide). If you are too, then I'm must be missing where
that is in there.
You mention the following:
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.
They can't be overlapped though, can they? Meaning can a single SPIN
function used to do one or more of the following:
process a SPARQL query,
invoke a SM script,
call a JavaScript function, etc.
In your first paragraph above, you state "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."
A single SPIN function can't be used to invoke a SM script and process
a SPARQL query (the spin:body), can it?
Thanks,
Catrina
On Aug 11, 9:32 am, Scott Henninger <[email protected]>
wrote:
> 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-...
>
> 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- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---