update inferences???

[s.c...@ucl.ac.uk]

Hi, all.

I am using TopBraid Composer Free Edition 3.4 to build an ontology
model for my study.
I use a modify query to update some properties of instances.
After executing a MODIFY query, I need to update inference relating to
the instances.

Suppose following example (using spinsquare.owl in the example
folder).
I put 20 instances of Rectangle class and made a spin rule for the
Rectangle class like below.

CONSTRUCT {
?this :isBiggerThan ?other .
}
WHERE {
?this :area ?area1 .
?other :area ?area2 .
FILTER (?area1 > ?area2) .
}

Then, change the area of rectangles using a modify query based on
width and height properties.
Finally, I'm using Reset Inferences menu and Run Inferences menu to
update inferences.
It seems like deleting all inferred triples and inserting all inferred
triples again.
That's the only way that I know to keep consistency.

Is there any way to update inferences partially? or delete inferred
triples that can't display the explanation of why they have been
inferred anymore.

I want to update inferences just relating to the instances I modified.

Thanks in advance.

Best regards,
Seong

[Scott Henninger]

Seong; If you turn on incremental inferencing, then SPIN queries are
executed for only the modified property. To turn on incremental
inferencing, go to Inference > Configure Inferencing, double-click on
the TopSPIN box and check "Incremental inferencing at edit time".

This feature is intended specifically for editing in TopBraid Composer
forms. For more automated approaches to running inferences after
changes, you would need to look into SPARQLMotion.

Also note how SPARQL CONSTRUCT and SPARQL 1.1 Update are applied very
differently. A SPARQL CONSTRUCT query returns a set of triples.
Running SPIN will create all triples created in the CONSTRUCT queries
and place them in the inferred graph. When you reset inferences, the
inferred graph is cleared. Also note that changes are not saved, as
the inferred graph is discarded when the model is closed.

Update works differently, as it directly modifies the specified
graph. This means the changes are applied to the asserted graph.
Resetting inferences will have no effect and if you save the model,
the changes will be saved.

-- Scott

On Feb 21, 3:27 pm, "seongkyu.c...@googlemail.com" <s.c...@ucl.ac.uk>
wrote:

[s.c...@ucl.ac.uk]

Dear Scott,

Thanks for your kind answer. But, maybe my question was not clear.
So, I tried to clarify my question again with more detail.

Please read following A, B, C, and D what I did.

A. add a spin:rule and some instances (from spinsquare.owl example)

- delete already existing two instances of Rectangle class
- add an objectProperty isBiggerthan
- add spin:rule in the Rectangle class like below.

CONSTRUCT {
?this :isBiggerThan ?other .
}
WHERE {
?this :area ?area1 .
?other :area ?area2 .
FILTER (?area1 > ?area2) .
}

- then add three instances of Rectangle class and their properties
(assertions)
. r1 (height 1, width 1)
. r2 (height 2, width 2)
. r3 (height 3, width 3)

- then turn on incremental inferencing and run Inferences
- get six inferred triples
. r1 area 1
. r2 area 4
. r3 area 9
. r2 isBiggerThan r1
. r3 isBiggerThan r1
. r3 isBiggerThan r2


B. Modify assertions

- change r1's height and width
. r1 (height: 4, width 4)

- run Inferences again and get eight inferred triples
. r1 area 16 (updated, true)
. r2 area 4 (old, true)
. r3 area 9 (old, true)
. r1 isBiggerThan r2 (new, true)
. r1 isBiggerThan r3 (new, true)
. r2 isBiggerThan r1 (old, not true any more)
. r3 isBiggerThan r1 (old, not true any more)
. r3 isBiggerThan r2 (old, still true)


C. Reset Inferences and run Inferences again.
- get six inferred triples (all true)
. r1 area 16
. r2 area 4
. r3 area 9
. r1 isBiggerThan r2
. r1 isBiggerThan r3
. r3 isBiggerThan r2

D. Modify assertions again
- change r1's height and width back to previous values
. r1 (height: 1, width 1)
- Automatically inferred triples relating to r1 are deleted
. two triples deleted, four triples remain (all true)
- run Inferences (without Reset Inferences)
. two triples added, now six triples are all true

------------------

When I change r1's property, if r1 is the subject of inferred triples,
these inferred triples are deleted automatically (like D above).
But, if r1 is the object of inferred triples, these inferred triples
remain and they are not true anymore in this case (like B above).
To keep consistency (to keep all inferred triples true), I had to
reset and run inferences again (like C above).

My question was whether there is a way to avoid a case like B above
without resetting inferences.

I tried a delete query to delete inferred triples that r1 is the
object like below.
But all inferred triples that have isBiggerThan as predicate were
deleted.

DELETE {
?subject :isBiggerThan ?r1 .
}
WHERE {
?r1 rdfs:label "r1" .
?subject :isBiggerThan ?r1 .
}

You mentioned SPARQLMotion before. With this, can I avoid a case like
B above without resetting inferences?

Actually, I'm trying to model moving cars and their locational
relations (e.g. isInFrontOf) if they are on the same road using
inferences.
Their locations are changing and I need to update their relative
location by updating inferred triples.
If assertions and properties are changing often, can I still use
ontology and its inference power?

I hope I described my problem this time better.

Thanks in advance.

Best regards,
Seong

On Feb 21, 10:42 pm, Scott Henninger <shennin...@topquadrant.com>
wrote:

[Scott Henninger]

Seong; Thank you for the detailed scenario. The way SPIN incremental
inference works is that it will recompute the rules associated with
all resources that are explicitly mentioned as subject, predicate or
object of any changed triple. In your case this means that only some
rectangles are updated, but not those that have not been directly
mentioned in the change (see Change History after running the update).

Incremental inferencing is generally a difficult problem and the first-
order inferences, as described above, is what we are currently
supporting. As you note, you will need to run inferences each time a
change is made. It should not be necessary to reset inferences each
time.

This step can be automated with a SPARQLMotion script that executes
the TopSPIN module. You can use Ensemble to create a UI that uses a
SPARQLMotion relay to invoke a server-side script that runs the
TopSPIN module each time a value is changed.

-- Scott

On Feb 22, 8:08 pm, "seongkyu.c...@googlemail.com" <s.c...@ucl.ac.uk>
wrote:

[s.c...@ucl.ac.uk]

On Feb 23, 6:09 am, Scott Henninger <shennin...@topquadrant.com>

[s.c...@ucl.ac.uk]

Thanks again. But in the B section of my scenario, first inferred
triple was recomputed correctly as you said.

B. Modify assertions
- change r1's height and width
. r1 (height: 4, width 4)
- run Inferences again and get eight inferred triples

1. r1 area 16 (updated, true)
2. r2 area 4 (old, true)
3. r3 area 9 (old, true)
4. r1 isBiggerThan r2 (new, true)
5. r1 isBiggerThan r3 (new, true)
6. r2 isBiggerThan r1 (old, not true any more)
7. r3 isBiggerThan r1 (old, not true any more)
8. r3 isBiggerThan r2 (old, still true)

But, 6th and 7th inferred triples remain and never updated (I checked
the Change History). They are not true and conflict with 4th and 5th
triples.

I think it is because ?this parameter used as subject of the spin rule
and SPIN incremental inference only delete inferred triples that has ?
this as subject.
That's why 6th and 7th triples above remain and not deleted. I
understand correctly???

CONSTRUCT {
?this :isBiggerThan ?other .
}
WHERE {
?this :area ?area1 .
?other :area ?area2 .
FILTER (?area1 > ?area2) .
}

To delete 6th and 7th triples automatically, I had to make another
rule using ?this as object like below.
CONSTRUCT {
?other :isBiggerThan ?this .

}
WHERE {
?this :area ?area1 .
?other :area ?area2 .
FILTER (?area1 < ?area2) .
}

now, 6th and 7th triples are removed automatically, when I change r1's
properties.
you said that the way SPIN incremental inference works is that it will

recompute the rules associated with
all resources that are explicitly mentioned as subject, predicate or
object of any changed triple.

It sounds okay when handling data properties (like # Computes area :=
width * height)

But, in my case, I had to make another rule using ?this as object.
That's only way I found in order to delete false inferred triples
automatically, but looks strange and not a good solution.
If I understand correctly, for object properties, SPIN incremental
inference just recompute the rules associated with all resources that
are explicitly mentioned as subject of any changed triple if ?this
parameter is used as subject. If ?this parameter is used as object of
the spin rule, SPIN incremental inference will recompute the rules
associated with all resources that are explicitly mentioned as object
only.

I hope you understand why I used reset inferences and why now I made
another spin rule using ?this as object of the construct statement.
When r1's property is changed, inferred triples need to be removed if
r1 is their subject or object in my case. That's what I want.
If not, I have false inferred triples and they conflict with new
inferred triples (like 6th and 7th triples of B).

Best regards,
Seong



On Feb 23, 6:09 am, Scott Henninger <shennin...@topquadrant.com>

[Scott Henninger]

Seong; The question is mixing incremental inference and running
inference, so I'll try to separate them.

<<I think it is because ?this parameter used as subject of the spin
rule
and SPIN incremental inference only delete inferred triples that has ?
this as subject. >>

In terms of incremental inference: The issue is as stated, that none
of the properties in your change appear in your :isBiggerThan rule. ?
this is not a factor because the analysis happens on the rule itself.
(an aside for understanding how SPIN works: When executing the rule,
the SPIN engine pre-binds each member of the class the rule is defined
in to ?this.

In terms of running inference: The rule creates triples and cannot
retract any. This is how monotonic reasoning works.

In terms of incremental inference: In the background a delete is
executed when a new value is computed. If you want this to remove all
previous values, you will need to make sure there are rules that will
execute on the change. Your solution is a good example of what you
need to do. (Good work!)

<<That's only way I found in order to delete false inferred triples
automatically, but looks strange and not a good solution. >>

Using monotonic reasoning, it is amongst the best solution.

-- Scott

On Feb 23, 6:14 am, "seongkyu.c...@googlemail.com" <s.c...@ucl.ac.uk>
wrote:

> ...
>
> read more »

[Holger Knublauch]

Hi Seong,

I am not a big fan of incremental inferencing. I believe in many/most cases, user-defined SPIN functions and magic properties are a better choice. Instead of keeping all inferences up to date after each change (which is a known difficult problem in computer science), it is often more efficient and more accurate to compute the values of interest on demand.

For example, assume you have a SPIN function ex:computeArea which takes a ex:Rectangle as argument. Then, you can use that function to implement ex:isBiggerThan, either as magic property or a boolean function. Whenever you need this value, you can then write a query to fetch the fresh value based on all current data. This would lead to a much simpler architecture, because it would also more cleanly separate those parts of your model that are derived from those that are asserted.

The trade-off is that keeping inferences up to date may be more efficient if data changes rarely, and is queried often. Have you considered using functions?

Hope this helps.
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

[s.c...@ucl.ac.uk]

Thanks very much, both of you!!

I started this with monotonic inference and realized that it's not
working for my case (I couldn't avoid false inferred triples).
Then, I tried incremental inferencing with two
spin:rules :isBiggerThan (same logic, but one uses ?this as subject
and the other uses ?this as object) to delete old inferred triples +
running inference to add new inferred triples. In my case, incremental
inferencing only delete inferred triples (not adding). That's why I
mixed incremental inference and running inference.

Anyway, now, I'm trying a SPIN function and a magic property like you
guys suggested, and they are working very well.

# :getArea spin:Functions
SELECT ?area
WHERE {
?arg :width ?width .
?arg :height ?height .
LET (?area := (?width * ?height)) .
}

#:isBiggerThan spin:MagicProperties
SELECT ?isBiggerThan
WHERE {
?arg1 a :Rectangle .
?isBiggerThan a :Rectangle .
LET (?area1 := :getArea(?arg1)) .
LET (?area2 := :getArea(?isBiggerThan)) .
FILTER (?area1 > ?area2) .
}

#Sparql query
SELECT *
WHERE {
?aaa :isBiggerthan ?bbb .
}


Thanks again, both of you!! Now, I can go to the next step for my
study. Your comments were very useful and helpful.

Best regards,
Seong

On Feb 23, 10:33 pm, Holger Knublauch <hol...@topquadrant.com> wrote:
> Hi Seong,
>
> I am not a big fan of incremental inferencing. I believe in many/most cases, user-defined SPIN functions and magic properties are a better choice. Instead of keeping all inferences up to date after each change (which is a known difficult problem in computer science), it is often more efficient and more accurate to compute the values of interest on demand.
>
> For example, assume you have a SPIN function ex:computeArea which takes a ex:Rectangle as argument. Then, you can use that function to implement ex:isBiggerThan, either as magic property or a boolean function. Whenever you need this value, you can then write a query to fetch the fresh value based on all current data. This would lead to a much simpler architecture, because it would also more cleanly separate those parts of your model that are derived from those that are asserted.
>
> The trade-off is that keeping inferences up to date may be more efficient if data changes rarely, and is queried often. Have you considered using functions?
>
> Hope this helps.
> Holger
>

> ...
>
> read more »