reasoner takes long time

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

reasoner takes long time

Tran Binh
Hi all,
I use protege 4.1 and HerMit. Almost the step of reasoning is quite fast except the step "computing instances for all classes".

I have all the individuals within a class are different, and some classes are disjoin to each other.

Do anyone has experience to improve speed of reasoner?

Thank in advances
Binh
Reply | Threaded
Open this post in threaded view
|

Re: reasoner takes long time

Siddharth Taduri
Hi Binh,

I had a similar problem. Basically, the owl:differentFrom, owl:AllDifferent axioms do not scale very well and over 95% of the program execution time is spent in garbage collection and causes serious memroy issues. You may want to look into that if your ontology contains a lot of individuals. I am pasting the reply from Timothy below. I hope this helps:

-- Sid

1. When I remove the owl:AllDifferent statement, the Jess rule engine runs in very reasonable time and memory. How is this related to the AllDifferent clause? If so, is there an alternative for me to use?

I have noticed that the all different axiom doesn't scale well.  You want to use it because OWL 2 does not make the unique name assumption.  But the all different axiom can't handle large numbers of individuals.  A single axiom that references 30000 individuals is crazy.

An alternative - OWL 2 only - is to use the hasKey axiom [1].  Give all your individuals unique names or identifiers and this is fixed.  If you use (meaningless) identifiers and the individuals are created or updated programatically, you can guarantee that the identifiers are unique by using unique ids.  I believe unique ids are a standard (but oracle's links don't seem right?) and there is a java implementation in java.util.UUID.  

2. I'm using a triple store like Virtuoso for the application which uses the ontology. I am storing the inferred version in the triple store. Protege/Jena/Pellet etc. are all in-memory reasoners. Since I am working with a very large number of instances, are there any other reasoners I can use? In general, what should my considerations be?

I am sure that Jena has some reasoners that don't pull everything into memory - but you would have to ask their group.   I know also that Pellet has OWLGres which should be able to do what you want.  I have never used this so again you should probably go to their group [2].   I suspect that there are others.  I believe that KAoN 2 had such things but I think it is pretty much dead now because it took too long to go to open source.  

My instinct is that this is a very important problem.  You don't really have that many individuals yet but it wouldn't surprise me if memory based reasoners (and even Protege) have lots of trouble with this already.

-Timothy


[1] http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Keys
[2] http://lists.owldl.com/mailman/listinfo/pellet-users

On Wed, May 11, 2011 at 7:27 AM, Tran Binh <[hidden email]> wrote:
Hi all,
I use protege 4.1 and HerMit. Almost the step of reasoning is quite fast
except the step "computing instances for all classes".

I have all the individuals within a class are different, and some classes
are disjoin to each other.

Do anyone has experience to improve speed of reasoner?

Thank in advances
Binh

--
View this message in context: http://protege-ontology-editor-knowledge-acquisition-system.136.n4.nabble.com/reasoner-takes-long-time-tp3514862p3514862.html
Sent from the Protege OWL mailing list archive at Nabble.com.
_______________________________________________
protege-owl mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-owl

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03


_______________________________________________
protege-owl mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-owl

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03
Reply | Threaded
Open this post in threaded view
|

Re: reasoner takes long time

Tran Binh
Dear Sid,

Thank you very much,
Did you use "key" to set individuals differentiate? How is result?

Cheers,
Binh

On Wed, May 11, 2011 at 6:57 PM, Siddharth Taduri <[hidden email]> wrote:
Hi Binh,

I had a similar problem. Basically, the owl:differentFrom, owl:AllDifferent axioms do not scale very well and over 95% of the program execution time is spent in garbage collection and causes serious memroy issues. You may want to look into that if your ontology contains a lot of individuals. I am pasting the reply from Timothy below. I hope this helps:

-- Sid

1. When I remove the owl:AllDifferent statement, the Jess rule engine runs in very reasonable time and memory. How is this related to the AllDifferent clause? If so, is there an alternative for me to use?

I have noticed that the all different axiom doesn't scale well.  You want to use it because OWL 2 does not make the unique name assumption.  But the all different axiom can't handle large numbers of individuals.  A single axiom that references 30000 individuals is crazy.

An alternative - OWL 2 only - is to use the hasKey axiom [1].  Give all your individuals unique names or identifiers and this is fixed.  If you use (meaningless) identifiers and the individuals are created or updated programatically, you can guarantee that the identifiers are unique by using unique ids.  I believe unique ids are a standard (but oracle's links don't seem right?) and there is a java implementation in java.util.UUID.  

2. I'm using a triple store like Virtuoso for the application which uses the ontology. I am storing the inferred version in the triple store. Protege/Jena/Pellet etc. are all in-memory reasoners. Since I am working with a very large number of instances, are there any other reasoners I can use? In general, what should my considerations be?

I am sure that Jena has some reasoners that don't pull everything into memory - but you would have to ask their group.   I know also that Pellet has OWLGres which should be able to do what you want.  I have never used this so again you should probably go to their group [2].   I suspect that there are others.  I believe that KAoN 2 had such things but I think it is pretty much dead now because it took too long to go to open source.  

My instinct is that this is a very important problem.  You don't really have that many individuals yet but it wouldn't surprise me if memory based reasoners (and even Protege) have lots of trouble with this already.

-Timothy


[1] http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Keys
[2] http://lists.owldl.com/mailman/listinfo/pellet-users

On Wed, May 11, 2011 at 7:27 AM, Tran Binh <[hidden email]> wrote:
Hi all,
I use protege 4.1 and HerMit. Almost the step of reasoning is quite fast
except the step "computing instances for all classes".

I have all the individuals within a class are different, and some classes
are disjoin to each other.

Do anyone has experience to improve speed of reasoner?

Thank in advances
Binh

--
View this message in context: http://protege-ontology-editor-knowledge-acquisition-system.136.n4.nabble.com/reasoner-takes-long-time-tp3514862p3514862.html
Sent from the Protege OWL mailing list archive at Nabble.com.
_______________________________________________
protege-owl mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-owl

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03


_______________________________________________
protege-owl mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-owl

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03




--
Trần Thái Bình
GIS and Remote Sensing
[hidden email]
[hidden email]
Phone: (848) 38247360
mobile: 0913 194 917
- Việt Nam -

_______________________________________________
protege-owl mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-owl

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03
Reply | Threaded
Open this post in threaded view
|

Re: reasoner takes long time

Thomas Russ
In reply to this post by Siddharth Taduri

On May 11, 2011, at 9:57 AM, Siddharth Taduri wrote:

> over 95% of the program execution time is spent in garbage  
> collection and causes serious memroy issues

Generally when Java spends this much time in garbage collection, it is  
a sign that the Java process needs to have more memory allocated to  
it.  Naturally, if the allDifferent axioms require large amounts of  
memory this will make the problem worse.

It is also possible that the allDifferent axioms contribute  
algorithmically to the slowing of the reasoning process, but that  
would affect non-GC running times.
_______________________________________________
protege-owl mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-owl

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03
Reply | Threaded
Open this post in threaded view
|

Re: reasoner takes long time

Timothy Redmond
In reply to this post by Tran Binh

I don't have a good sense of what makes a reasoner fast or slow.  But
Protege does allow you to reduce steps done during the initialization of
the reasoner or during the process of displaying inferences.  The
reasoner configuration can be found by following the menu
Reasoner->Configure.  It is best to make changes in the "Displayed
Inferences" tab.  This will indirectly influence what steps need to
occur to initialize the reasoner.  The obvious things to uncheck in your
case are the "Class Members" under "Class Inferences" and the "Types"
under "Individual Inferences".

It is true that the Initialization tab gives you direct control over the
initialization of the reasoner.  But it is possible that turning off an
initialization step will make subsequent inference slow.  If you go this
route then when you find that Protege is slow you can come back to
Reasoner->Configure->Displayed Inferences to find out which inferences
have been slowed down because of your changes the initialization tab.

-Timothy



On 05/11/2011 07:27 AM, Tran Binh wrote:

> Hi all,
> I use protege 4.1 and HerMit. Almost the step of reasoning is quite fast
> except the step "computing instances for all classes".
>
> I have all the individuals within a class are different, and some classes
> are disjoin to each other.
>
> Do anyone has experience to improve speed of reasoner?
>
> Thank in advances
> Binh
>
> --
> View this message in context: http://protege-ontology-editor-knowledge-acquisition-system.136.n4.nabble.com/reasoner-takes-long-time-tp3514862p3514862.html
> Sent from the Protege OWL mailing list archive at Nabble.com.
> _______________________________________________
> protege-owl mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/protege-owl
>
> Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03

_______________________________________________
protege-owl mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-owl

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03
Reply | Threaded
Open this post in threaded view
|

using keys to make individuals different

Martin Kuba
In reply to this post by Siddharth Taduri
Hi all,

I am trying to state that all my individuals are different. I have tried to use unique keys as suggested
in one post some time ago:

Dne 11.5.2011 18:57, Siddharth Taduri napsal(a):
 > I am pasting the reply from Timothy below. I hope this helps:
>> I have noticed that the all different axiom doesn't scale well.  You want to use it because OWL 2 does not make the unique name assumption.  But the all different axiom can't handle large numbers of
>> individuals.  A single axiom that references 30000 individuals is crazy.
>>
>> An alternative - OWL 2 only - is to use the hasKey axiom [1].  Give all your individuals unique names or identifiers and this is fixed.  If you use (meaningless) identifiers and the individuals are
>> created or updated programatically, you can guarantee that the identifiers are unique by using unique ids.  I believe unique ids are a standard (but oracle's links don't seem right?) and there is a
>> java implementation in java.util.UUID.
>>
>> [1]http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Keys

However I have found that keys cannot be used to make individuals *different*.

The key semantics at http://www.w3.org/TR/owl2-direct-semantics/#Keys
says that keys are basically a rule that makes individuals with same values
for key properties to be the *same*.

It says nothing about individuals being different when their keys are different !

Indeed, when I use a data property like "hasEmail" as a key and I declare:

Declaration(DataProperty(:hasEmail))
HasKey(:Person () (:hasEmail))
DataPropertyAssertion(:hasEmail :Peter "[hidden email]"^^xsd:string)
DataPropertyAssertion(:hasEmail :Martin "[hidden email]"^^xsd:string)
DataPropertyAssertion(:hasEmail :Martin2 "[hidden email]"^^xsd:string)

then both Pellet and Hermit reasoners entail that :Martin and :Martin2
are the *same* individual, however they do not entail that :Peter and :Martin
are different.

The problem is that a key property does not have to be functional. Because of the open world assumption,
it can happen that Peter has also the email "[hidden email]", just it is not known now.

I can declare a functional data property on Person like:

Declaration(DataProperty(:hasId))
FunctionalDataProperty(:hasId)
DataPropertyAssertion(:hasId :Peter "peter")
DataPropertyAssertion(:hasId :Martin "martin")

and then reasoners entail that :Peter and :Martin are different. No key here.


So my conclusion is that keys cannot be used to make individuals different,
for that I must use a functional property.

Am I right ?

Best regards

Martin
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CERIT-SC                               Martin Kuba
Institute of Computer Science    email: [hidden email]
Masaryk University             http://www.ics.muni.cz/~makub/
Botanicka 68a, 60200 Brno, CZ     mobil: +420-603-533775
--------------------------------------------------------------
_______________________________________________
protege-owl mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-owl

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03
Reply | Threaded
Open this post in threaded view
|

Re: using keys to make individuals different

Timothy Redmond

> So my conclusion is that keys cannot be used to make individuals
> different,
> for that I must use a functional property.
>
> Am I right ?

You are exactly right.  Thank god for reasoners (and smart people) to
tell us definitively when we are wrong.

-Timothy


On 05/19/2011 04:49 AM, Martin Kuba wrote:

> Hi all,
>
> I am trying to state that all my individuals are different. I have
> tried to use unique keys as suggested
> in one post some time ago:
>
> Dne 11.5.2011 18:57, Siddharth Taduri napsal(a):
> > I am pasting the reply from Timothy below. I hope this helps:
>>> I have noticed that the all different axiom doesn't scale well.  You
>>> want to use it because OWL 2 does not make the unique name
>>> assumption.  But the all different axiom can't handle large numbers of
>>> individuals.  A single axiom that references 30000 individuals is
>>> crazy.
>>>
>>> An alternative - OWL 2 only - is to use the hasKey axiom [1].  Give
>>> all your individuals unique names or identifiers and this is fixed.  
>>> If you use (meaningless) identifiers and the individuals are
>>> created or updated programatically, you can guarantee that the
>>> identifiers are unique by using unique ids.  I believe unique ids
>>> are a standard (but oracle's links don't seem right?) and there is a
>>> java implementation in java.util.UUID.
>>>
>>> [1]http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Keys
>
> However I have found that keys cannot be used to make individuals
> *different*.
>
> The key semantics at http://www.w3.org/TR/owl2-direct-semantics/#Keys
> says that keys are basically a rule that makes individuals with same
> values
> for key properties to be the *same*.
>
> It says nothing about individuals being different when their keys are
> different !
>
> Indeed, when I use a data property like "hasEmail" as a key and I
> declare:
>
> Declaration(DataProperty(:hasEmail))
> HasKey(:Person () (:hasEmail))
> DataPropertyAssertion(:hasEmail :Peter "[hidden email]"^^xsd:string)
> DataPropertyAssertion(:hasEmail :Martin "[hidden email]"^^xsd:string)
> DataPropertyAssertion(:hasEmail :Martin2 "[hidden email]"^^xsd:string)
>
> then both Pellet and Hermit reasoners entail that :Martin and :Martin2
> are the *same* individual, however they do not entail that :Peter and
> :Martin
> are different.
>
> The problem is that a key property does not have to be functional.
> Because of the open world assumption,
> it can happen that Peter has also the email "[hidden email]", just it
> is not known now.
>
> I can declare a functional data property on Person like:
>
> Declaration(DataProperty(:hasId))
> FunctionalDataProperty(:hasId)
> DataPropertyAssertion(:hasId :Peter "peter")
> DataPropertyAssertion(:hasId :Martin "martin")
>
> and then reasoners entail that :Peter and :Martin are different. No
> key here.
>
>
> So my conclusion is that keys cannot be used to make individuals
> different,
> for that I must use a functional property.
>
> Am I right ?
>
> Best regards
>
> Martin

_______________________________________________
protege-owl mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-owl

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03