[Pellet-users] A lot of descendant queries

[Alan Ruttenberg]

I'm using 1.4 right now.
I also tried to clean up those nodes - grabbed the classes at the  
beginning and periodically called removeNode on all the ones that  
were new. Didn't help, so that confirms.
What about abox caches? I think I did printStats or something like  
that and there were several thousand sat tests per query.
-Alan

On May 4, 2007, at 11:01 AM, Evren Sirin wrote:

> On 5/3/07 2:34 PM, Alan Ruttenberg wrote:
>> Can you direct me to the line of code that does that so I can  
>> comment it out in the short run?
>> Or give me an invocation that lets me remove it from the taxonomy  
>> right after I do the query?
> Thinking a little more about this and doing an experiment shows it  
> is probably not the taxonomy builder that causes the memory grow.  
> For each concept C, you have one anon concept some(part_of, C)  
> which means there will be only ~23K nodes in the taxonomy and that  
> shouldn't take up so much memory. I've made the change I thought  
> was the problem but it did not really solve the issue with the  
> following code snippet (which I assume is similar to what you are  
> doing):
>
>        for( ATermAppl c : kb.getClasses() ) {
>            ATermAppl partOfC = ATermUtils.makeSomeValues( part_of,  
> c );
>            Set subParts = kb.getSubClasses( partOfC );
>            // do nothing with subParts yet
>        }
>
> The memory problem is probably somewhere else but it is hard to  
> tell where. Just to make sure, which version of Pellet are you using?
>
> Cheers,
> Evren
>> Might be good to add another method that just says: get me the  
>> subclasses just this once, I  won't be asking about this class  
>> ever again.
>> -Alan
>>
>>
>> On May 3, 2007, at 2:28 PM, Evren Sirin wrote:
>>
>>> On 5/3/07 11:59 AM, Alan Ruttenberg wrote:
>>>> One problem with doing it the slow way is that memory  
>>>> consistently grows. Is there a reason that the call to  
>>>> getSubClasses need to allocate any long lived memory?
>>> The getSubClasses function will insert the given concept into the  
>>> class taxonomy and doing many calls to getSubClasses will  
>>> probably eat up all the memory. It would be a good idea for us to  
>>> put some kind of limit on how many (anonymous) concepts will be  
>>> cached inside the taxonomy.
>>>
>>> Cheers,
>>> Evren
>>>> So when doing this the way I suggest on the GO biological  
>>>> process ontology I eventually run out of memory when I don't  
>>>> think I should.
>>>>
>>>> -Alan
>>>>
>>>>
>>>> On May 3, 2007, at 7:46 AM, Evren Sirin wrote:
>>>>
>>>>> On 5/1/07 3:44 PM, Alan Ruttenberg wrote:
>>>>>> Hi,
>>>>>> I'm using pellet to compute inferred class level part_of  
>>>>>> relations  between classes in GO.
>>>>>> The way I do this is to load the ontology and then iterate  
>>>>>> over all  classes c asking for descendants of
>>>>>> (restriction part_of (some-values-from c))
>>>>>>
>>>>>> This takes quite a while. Is there a fast way to do this?
>>>>>>
>>>>> I cannot think of any straightforward way that is faster. So  
>>>>> you want to compute the mereological hierarchy similar to  
>>>>> subsumption hierarchy. I think the same strategy (and similar  
>>>>> optimizations) for computing the subsumption hierarchy would  
>>>>> apply here. That is you compute told part_of relations, do a  
>>>>> top search for each concept to find what it is part of and do a  
>>>>> bottom search to find what parts it has.  This strategy avoids  
>>>>> many unnecessary tests and reuses the previously found  
>>>>> information effectively. A lot of the code inside Pellet  
>>>>> classifier could be reused but there is still a fair amount of  
>>>>> work that needs to be done to customize the classification code  
>>>>> for this purpose.
>>>>>
>>>>> Cheers,
>>>>> Evren
>>>>>> -Alan
>>>>>>
>>>>>> _______________________________________________
>>>>>> Pellet-users mailing list
>>>>>> Pellet-users at lists.owldl.com
>>>>>> http://lists.owldl.com/mailman/listinfo/pellet-users
>>>>>> _______________________________________________
>>>>>>
>>>>>> Sponsored by Clark & Parsia, LLC http://clarkparsia.com/
>>>>>>
>>>>>
>>>>
>>>
>>
>