JENA, NCI Thesaurus, inference and materializing inferred triples

[hu...@aol.com]

Hi,

I am already using Jena and the NCI Thesaurus (http://ncit.nci.nih.gov/) in my project in a very basic fashion. I am extending it with my custom ontology where required. I am mostly interested in querying for ancestors and descendants of concepts.

I am currently using custom SparQL queries and a TDB store to retrieve the required info. But this approach is slow, not very straight-forwarded and needs to be maintained over time, especially since the thesaurus uses "subclassof" as well as "owl:equivalentclass" in conjunction with intersections of other classes and restrictions on properties to define hierarchy and relationships between concepts.

I would either like to materialize the inferred triples during import into TDB or use a memory-backed OntModel with inference. I have been playing around with the in-memory OntModel. I can load the thesaurus using OntModelSpec.OWL_DL_MEM_RULE_INF, but when I try to retrieve an OntClass, the process just stalls/hangs/works, but does not run out of memory or anything like that and there is no significant activity in the windows task manager. I let it run for 45 minutes and then killed it. The code is below.

When I load the thesaurus using OntModelSpec.OWL_DL_MEM, I can retrieve the OntClass within milliseconds without problems.

My questions are: 
- Why is it taking so long to get an OntClass from the version with inference turned on? 
- Is this the right approach or what is the best way to increase querying speed? The ontology does not change once it is imported.

Thanks for any help,
Wolfgang
 

 

 

Re: JENA, NCI Thesaurus, inference and materializing inferred triples

[Dave Reynolds <da...@gmail.com>]

On 22/01/13 13:19, hueyl16@aol.com wrote:
> Hi,
>
> I am already using Jena and the NCI Thesaurus (http://ncit.nci.nih.gov/) in my project in a very basic fashion. I am extending it with my custom ontology where required. I am mostly interested in querying for ancestors and descendants of concepts.
>
> I am currently using custom SparQL queries and a TDB store to retrieve the required info. But this approach is slow, not very straight-forwarded and needs to be maintained over time, especially since the thesaurus uses "subclassof" as well as "owl:equivalentclass" in conjunction with intersections of other classes and restrictions on properties to define hierarchy and relationships between concepts.
>
> I would either like to materialize the inferred triples during import into TDB or use a memory-backed OntModel with inference. I have been playing around with the in-memory OntModel. I can load the thesaurus using OntModelSpec.OWL_DL_MEM_RULE_INF, but when I try to retrieve an OntClass, the process just stalls/hangs/works, but does not run out of memory or anything like that and there is no significant activity in the windows task manager. I let it run for 45 minutes and then killed it. The code is below.
>
> When I load the thesaurus using OntModelSpec.OWL_DL_MEM, I can retrieve the OntClass within milliseconds without problems.
>
> My questions are:
> - Why is it taking so long to get an OntClass from the version with inference turned on?

The inferences engine uses a mix of forward and backward inference. The 
first time you make a query then the forward inference part is run to 
completion, independent of what actual query is made. Then the backward 
inferences needed to satisfy the query goal are run.

It's likely that you are seeing the forward inference take too long.

Try with the OWL_MICRO configuration (which is much more practical that 
the OWL_RULE one) and give it some extra heap to avoid GC thrashing.

> - Is this the right approach or what is the best way to increase querying speed? The ontology does not change once it is imported.

The best approach for that sort of situation is to materialize all the 
inferences you'll need and then store those in the TDB store so at run 
time you only need simple queries.

For basic RDFS inference then the TDB loader has some built in support.

For more complex inference you might be able to use something like 
OWL_MICRO in memory to compute them, then store the ones you need. Or 
you might use a set of SPARQL CONSTRUCT queries.

Dave