Thanks for the detailed response, Jeff. There seem to be a few
different requirements:
1) The ability to specify the rule order per rule (similar to
SPARQLMotion)
Possible solution: a new property spin:next which links two rules/
template calls.
Issues: the rule metadata would currently be hard to see (in the
UI), so I would need
to create some form infrastructure such as a warning icon
indicating that there is
more in the nested form. It will also make sense to have
context menu items to
set those values on the form.
2) The ability to specify the rule order per group (using sub-
properties of spin:rule)
Possible solution: a new property spin:nextProperty which links
two properties.
For example,
my:importRule rdfs:subPropertyOf spin:rule ;
spin:nextProperty spin:rule .
would make sure that all importRules are executed before the
other spin:rules.
Issues: none really, so I think this might be a good start as it
requires least
infrastructure.
3) SPIN Functions that return multiple values - this is a separate
topic - i.e. support for
user-defined magic predicate (property functions) in SPIN. This
is straight forward
to do, but quite some work. I'll put it on my list though. I
wish SPARQL had some
more explicit way of handling such multi-valued functions, for
example a
FOR (?x := my:function(?a, ?b)) .
similar to LET. This would make it clearer that we are talking
about a real function
and avoids the ugliness of passing in multiple arguments using
an rdf:List structure.
Holger
On Aug 12, 2009, at 8:45 AM, Schmitz, Jeffrey A wrote:
>
> Hi Holger,
> What we currently use in our system is more along the lines of the
> "executeBefore" property. We call this property "successor". For
> rules, as you say, it could be associated with the rule queries
> themselves and allow chaining of individual rule queries. Any
> specific
> class would only have the first rule associated with it, but the
> executor would would follow the chain to determine the full rule
> ordering. I don't know SPARQLMotion too well, but would this be
> analogous to specifying a SPARQLMotion chain instead of an individual
> query as a SPIN rule?
>
> In our system too, it's more than just a matter of execution order.
> We
> also have to determine IF we are going to fire certain rules based on
> the current mode of the system. E.g. we only fire importRule's when
> in
> "Import" mode, and only fire exportRule's when in Export mode. We
> implement this by, as you say, creating subproperties so that the
> rules
> can be grouped according to the mode in which they are to execute.
> These modes are built (i.e. hardcoded) into our engine, so it can
> easily
> determine which rules to execute.
>
> Another possibility for rules would be to allow adding an "if"
> property
> to each rule that links to an ASK query. The executor would first
> execute the ASK query to determine if the rule itself would be
> executed.
> This way runtime checks could be made (e.g. system mode) to
> determine if
> individual rules are to be executed.
>
> Finally, I forgot to mention we'd still like to have the ability for
> Functions to return multiple values in its return variable as
> opposed to
> just a single value which I think it is limited to right now (unless
> you
> added this capability already and I missed it).
>
> The more I write, the more I get the feeling that what I'm
> suggesting is
> pretty much summed up in the last sentence of the first paragraph
> (SPARQLMotion Rules built into SPIN). This may be stepping on some
> code
> you'd rather not incorporate into SPIN though.
>
>
>
>
>> -----Original Message-----
>> From: Holger Knublauch [mailto:[email protected]]
>> Sent: Tuesday, August 11, 2009 5:49 PM
>> To: [email protected]
>> Subject: [tbc-users] Re: ANN: TopBraid SPIN API 1.0.2
>>
>>
>> Hi Jeff,
>>
>> this is actually an interesting idea. A generic solution
>> would be to assign some numeric value to the sub-properties,
>> e.g. triples
>>
>> my:importRule spin:weight 10 .
>> my:exportRule spin:weight 20 .
>>
>> where rules using properties with smaller weight would be
>> executed before the others. Using a sub-property of spin:rule
>> would provide a natural grouping of rules into categories.
>> Alternative to a numeric value would be an explicit
>> spin:executeBefore to relate two rule properties.
>>
>> Would this be sufficient for your use case, and which
>> solution sounds cleaner?
>>
>> Thanks,
>> Holger
>>
>>
>> On Aug 11, 2009, at 1:10 PM, Schmitz, Jeffrey A wrote:
>>
>>>
>>> We certainly have added our own subclasses to spin:rule to control
>>> rule execution, but I think they may be too specific to our
>>> application to add them to the general spin model.
>>>
>>> Perhaps some kind of directional flow sub-properties (e.g.
>> importRule,
>>> exportRule) that could be used directly or could themselves
>> be further
>>> be subclassed would be helpful. But perhaps even that wouldn't be
>>> general enough.
>>>
>>> It's not too hard to add and mechanize such concepts locally, but
>>> perhaps you don't want too much fragmentation so the
>> standard SPIN API
>>> can do more of the work?
>>>
>>>
>>>> -----Original Message-----
>>>> From: Holger Knublauch [mailto:[email protected]]
>>>> Sent: Tuesday, August 11, 2009 2:53 PM
>>>> To: [email protected]
>>>> Subject: [tbc-users] ANN: TopBraid SPIN API 1.0.2
>>>>
>>>>
>>>> There is a new version of the SPIN API available from
>>>>
>>>> http://www.topquadrant.com/topbraid/spin/api/
>>>>
>>>> New features include support for Jena 2.6 and for the ARQ keywords
>>>> NOT EXISTS and SERVICE. Note that the current release of
>> TBC (3.1.1)
>>>> does not yet support these two keywords in its SPIN RDF syntax.
>>>>
>>>> BTW I would appreciate input on how to improve SPIN. For
>> example if
>>>> you have requirements for additional properties to control the
>>>> execution of rules.
>>>>
>>>> Cheers,
>>>> Holger
>>>>
>>>>
>>>>>
>>>>
>>>
>>>>
>>
>>
>>>
>>
>
> >
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
