On 30/01/2016 5:27 PM, [email protected] wrote:
On Saturday, January 30, 2016 at 12:23:27 AM UTC+1, Irene Polikoff wrote:
James,
Constructors are usually only evaluated once, to set initial
default values to some properties of the instances. They are
triggered by a creation of a new resource. One example is when you
create a new resource in TBC, its label is automatically generated
from the qname.
Rules can be executed at any point by running TopSPIN inference
engine. They are usually evaluated multiple times (although you
can set a ‘single pass’ only) - as rules create new triples,
additional evaluations can then result in more triples and so on.
my concern is not restricted to topbraid.
i am trying to understand how these definitions are intended to act,
in general, in the course of sparql query and update processing.
given these two modes, above, is it correct that,
- when the definitions are intended to specify dynamic inferences, a
processor would execute rules first, followed by constructors.
Constructors are only supported at creation time, and only in controlled
environments such as the Create Resource dialogs of TBC. Otherwise they
are ignored, so I would not consider them consistently supported.
Also, when you run queries, SPIN rules are not evaluated on the fly
(dynamically), at least not with the current TopSPIN engine. Inferences
can only be triggered explicitly, e.g. using the run inferences button
in TBC. The former would require some kind of backward chaining which is
difficult to implement for general SPARQL.
- when performing a sparql update, a processor would execute
definitions which are intended to be materialized in the order, first
rules, followed by constructors and as the last step it would run
constraints?
The SPARQL update endpoint doesn't run any SPIN rules or constraint checks.
or, is there a distinction made between update rules and constructors,
in the the rule form would be active during dynamic inference while
the constructor form would apply when materializing?
does that cover all the intended applications?
I believe we need some information on what you are trying to achieve in
general, as the questions above only provide us with a partial picture.
A future (SPIN) engine could certainly support more than TopBraid
currently does, and the spec is pretty vague on when inferences should
be run, so there is freedom to add these capabilities.
Holger
--
You received this message because you are subscribed to the Google Group "TopBraid
Suite Users", the topics of which include Enterprise Vocabulary Network (EVN),
Reference Data Manager (RDM), TopBraid Composer, TopBraid Live, TopBraid Insight,
SPARQLMotion, SPARQL Web Pages and SPIN.
To post to this group, send email to [email protected]
---
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
