Inserting new instances using SPIN rules
Gerrit
seems to work in the Query Editor:
CONSTRUCT {
?mp a sc:MediaPath .
?x3 sc:hasMediaPath ?mp .
?mp bonding:mediaSourceSO ?x2 .
?mp bonding:mediaOriginator ?x1 .
}
WHERE {
?x1 sc:connectedTo ?x3 .
LET (?mp := smf:buildUniqueURI("sc:mediapath")) .
}
But adding it as a SPIN ruie seems to have either no effect, or causes
TopSPIN to continue iterating.
Regards,
Gerrit
Scott Henninger
triples constructed. In your case, each time you call
smf:buildUniqueURI(), a new uri is created by the {?mp a sc:MediaPath}
triple pattern in the CONSTRUCT statement. There are two potential
solutions to the problem:
1) Set the TopSPIN engine to single-pass in Configure Inferencing
2) use smf:buildURI with a known pattern, such as
smf:buildURI("sc:mediapath{?x1}_to_{?x2}")
Some background may also be helpful. SPIN rules are defined in a
class definition an applied to all members of a class (including
subClassOf entailments). Therefore, any SPIN rule without reference
to ?this is suspect because the scope of the query is misaligned with
how it is being applied. That's not to say that SPIN rules can't have
a wider scope than the member it is being applied to, but that this
should be seen as a rare case.
I suspect you want to look at all resources in your model for the
connectedTo property. If that's the case, a better SPIN rule would be
to define the following in owl:Thing:
CONSTRUCT {
?mp a sc:MediaPath .
?x3 sc:hasMediaPath ?mp .
?mp bonding:mediaSourceSO ?x2 .
?mp bonding:mediaOriginator ?x1 .
}
WHERE {
}
the semantic of your rule clearer. You want to apply the rule all
entailed instances of owl:Thing.
-- Scott
Holger Knublauch
On Apr 8, 2011, at 1:45 AM, Scott Henninger wrote:
> Gerrit; By default the SPIN engine iterates until there are no new
> triples constructed. In your case, each time you call
> smf:buildUniqueURI(), a new uri is created by the {?mp a sc:MediaPath}
> triple pattern in the CONSTRUCT statement. There are two potential
> solutions to the problem:
> 1) Set the TopSPIN engine to single-pass in Configure Inferencing
> 2) use smf:buildURI with a known pattern, such as
> smf:buildURI("sc:mediapath{?x1}_to_{?x2}")
Just for the sake of completeness (in the archive), there also is
3) Create a sub-property of spin:rule and set its spin:rulePropertyMaxIterationCount to 1.
Then move those rules that should not iterate under your new property.
The advantage of this solution over 1) is that it is independent of the TopSPIN settings, which may only be local to your machine (and stored in the .tbc files). The disadvantage is that setting this up is a bit of more work.
Holger
Gerrit
of ?this after reading the SPIN tutorial, but Scott's explanation
makes sense. I was wondering which class to attach the SPIN rule to -
should have realized to attach it to OWL:Thing if the scope is the
entire model.
I first tried approach 2, but {?x1} adds the qname to the URI as well,
and I couldn't figure out how to remove the qnames. The specified
qname (sc:) is also expanded, resulting in:
<http://sofia.gotdns.com/ontologies/
SemanticConnections.owl#mediapath_bonding:testDevice1_to_bonding:testDevice2>
where I wanted
<sc:mediaPath_testDevice1_to_testDevice2>
and afn:localname() only works on full URIs.
Approach 3 seems to work fine. In reality my SPIN rule is also
dependent on two property chain axioms that need to be inferred first
(not shown in my example below). This means that I had to change the
spin:rulePropertyMaxIterationCount to 2. Now I'm just wondering if it
is guaranteed that the property chain axioms will fire on the first
pass.
I'm really starting to like working with SPIN - the flexibility is
great and the built-in functions are very useful, thanks guys.
Regards,
Gerrit
Holger Knublauch
On Apr 8, 2011, at 6:32 PM, Gerrit wrote:
> In reality my SPIN rule is also
> dependent on two property chain axioms that need to be inferred first
> (not shown in my example below). This means that I had to change the
> spin:rulePropertyMaxIterationCount to 2. Now I'm just wondering if it
> is guaranteed that the property chain axioms will fire on the first
> pass.
You can specify the order of rules in SPIN as well. The cleanest way is to define different sub-properties of spin:rule, and then link them together using spin:nextRuleProperty. For example, define my:prepRule and my:postRule and use them to group your rules that depend on each other. Otherwise, SPIN will use the "alphabetical" ordering of rules, and you can specify this by putting comments such as # Rule1 above the CONSTRUCT clauses. But the latter option is rather fragile, even if it's tempting for quick hacks.
Holger
Gerrit
API? I'm getting the following warning:
11:20:06 WARN (ALog.java:48) - URI <http://topbraid.org/
sparqlmotionfunctions#buildURI> has no registered function factory
Only when I replace it with a fixed URI does it infer the expected
triples.
Regards,
Gerrit
Scott Henninger
(TopBraid/SPARQLMotion/sparqlmotionfunctions.rdf) is loaded.
-- Scott
Holger Knublauch
no, the smf functions are currently native to TopBraid. We have factored out most of them into another stand-alone library for 3.5, and we yet need to decide on how this will be available to customers (i.e. it may be commercial for some users at least). That extended Java library also contains functions such as smf:parseDate, and all those functions have been moved into a separate namespace called http://spinrdf.org/spif# to clarify that they will work independently of TopBraid (Composer or Live).
In the case of buildURI, you have the option of using fn:concat in your own function, but even then you may need to wait for 3.5 which has better SPARQL 1.1 support - I am not sure whether the function IRI that turns strings into URI resources was already in 3.4. Also, to emulate buildURI you will need to do string functions that escape special characters.
As usual you seem to catch us at the bleeding edge, just in time for the next release :)
Regards,
Holger
> --
> 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
> topbrai...@googlegroups.com
> To unsubscribe from this group, send email to
> topbraid-user...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/topbraid-users?hl=en
Gerrit
LET (?mp := IRI(fn:concat("http://sofia.gotdns.com/ontologies/
SemanticConnections.owl#mediaPath_", afn:localname(?this), "_to_",
afn:localname(?x2)))) .
with both SPIN API 1.1.2 and TBC FE 3.4 (but not in the SPARQL Tab)
Regards,
Gerrit
> no, the smf functions are currently native to TopBraid. We have factored out most of them into another stand-alone library for 3.5, and we yet need to decide on how this will be available to customers (i.e. it may be commercial for some users at least). That extended Java library also contains functions such as smf:parseDate, and all those functions have been moved into a separate namespace calledhttp://spinrdf.org/spif#to clarify that they will work independently of TopBraid (Composer or Live).
Holger Knublauch
On Apr 12, 2011, at 7:10 PM, Gerrit wrote:
> The following seems to work:
>
> LET (?mp := IRI(fn:concat("http://sofia.gotdns.com/ontologies/
> SemanticConnections.owl#mediaPath_", afn:localname(?this), "_to_",
> afn:localname(?x2)))) .
>
> with both SPIN API 1.1.2 and TBC FE 3.4 (but not in the SPARQL Tab)
That's good. What happens when you run this in the SPARQL tab?
Holger
Gerrit
When do you expect the next version of the SPIN API to be available?
Holger Knublauch
the final release of the SPIN API will likely be synchronized with 3.5, in a couple of weeks. This is because I would like to benefit from the fact that we are doing a full QA on the TopBraid product line for 3.5, and this may also reveal bugs in the SPIN API. But I'll send you a link to a beta snapshot in a private email (any other beta testers may contact me as well).
As promised elsewhere, I have prepared a new example that demonstrates how to do OWL RL inferencing with the open source API. This also demonstrates optimized access to the rules so that only the domain model is queried - not the OWL RL model itself. The online versions of the OWL RL namespace now no longer rely on any native SMF function, so they will work with bare Jena.
Regards,
Holger