I like that solution 3. This is something i had in mind before as
well. I get it now.
1-However, how exactly can one add the information back into the
ontology ? Do you have some example code ? From what i understood, you
query the ontology, and then …… “I don’t understand”. Cause the result
that you get, could very well contain both asserted triple and
inferred triples. I come from the OWL-API. With it, there is clearly
something called axiom generator, along with a clear procedure to add
the inferred triple in the original ontology or any other ontology. Is
there something similar in Jena ? Or simply how is it done, what is
the best practice ?
From your explanation it seems that you want only to generate those
triples that are inferred out of the query, that’s interesting.
In any case i would need some pointer for that procedure. Is there
some code or example somewhere ?
Many thanks,
-M-
--
Daniel Maatari Okouya
Sent with Airmail
From: Dave Reynolds Dave Reynolds
Reply: [email protected] [email protected]
Date: December 11, 2013 at 1:29:48 PM
To: [email protected] [email protected]
Subject: Re: Jena TDB and Jena Inference cooperation underlying
mechanics
On 11/12/13 10:23, Daniel Maatari Okouya wrote:
> Many thanks for taking the time to provide such a precise answer.
>
> Meanwhile, I’m afraid i would require some clarification.
>
>
> 1- Could you explain the different between 1 and 2. To me the
solution are exactly the same. With my current knowledge of Jena. I
don’t see 2 different code coming out of "Construct an Infmodel over
a TDB" and “Load The TDB model into memory”. In both case i would go
with dataset.getNamedModel or getdefaultmodel, which to me would
result in an in-memory model, that will be a parameter of a
createInfModel…..
No, a call like getNamedModel doesn't load the model into memory, it
gives you an interface onto the TDB store. When you query that model
the
queries are sent to TDB.
To create an in memory copy you would do something like:
Model memCopy = ModelFactory.createDefaultModel();
memCopy.add( tdbModel );
> 2-In (3) I’m not familiar with the term "inference closure”. My
guess would be that you mean ontology schema… is there another term
for that, could you please clarify in easier jargon.
Maybe a trivial example would help:
Suppose you have an ontology, in a TDB model or a file, which states:
foaf:knows rdfs:domain foaf:Person; rdfs:range foaf:Person .
This is a small fragment of the FOAF vocabulary specification [1].
Now suppose you have some instance data, again a TDB model or file,
which only states:
:dave foaf:knows :bob .
The a query to list the types of :dave and :bob on that instance data
will of itself return empty.
However, if you construct an RDFS inference model which combines the
ontology and the instance data with a knowledge of RDFS semantics
then a
query to that for type statements would yeild, among other things:
:dave rdf:type foaf:Person .
:bob rdf:type foaf:Person .
These plus the ontology plus the instance data are the inference
closure. I.e. the closure is what you get by adding back in all the new
statements you can derive as a result of inference [2].
The inference engine has had to do work to generate those additional
inferred statements. All the internal reasoner state for doing so is in
memory. So if you kill your application and ask the same query again
the
inference engine has to do that work over again. For more complex
examples that work can be expensive, particularly over a persistent
store.
So in option 3 you take those inferred triples and store them, along
with the original triples. If you list the rdf:type statements on that
model now you see the same answers you would have seen if you queried
via an inference engine but didn't have to do inference to get them
(you
did it ahead of time).
Dave
[1] http://xmlns.com/foaf/spec/#term_knows
[2] Sometimes that complete closure can be infinite, so you can't infer
and store everything. But in practice the fragments implemented by the
rule engine are generally finite.
> Moreover, I’m not sure to understand the full logic here. Why would
i store the result of some query and then query them again. Is this
the way to store all the inferredTriple back in the store? Do you
mean that you take every triple that is returned and assert them back
in the Infmodel or the base model ? By the way does that mean that in
general, in jena, there is noway, to generate a model that is the
combination of the asserted and all the inferred triple (or a
selected set of inferred triple, e.g. all class axioms).
>
> As you can see i’m quite confuse ;) . I would much appreciate if
you could clarified and detailed a bit further (3)
>
> Also if u have good pointers for me to read, please do not
hesitate ;)
>
>
> Many thanks,
>
> -M-
>
> --
> Daniel Maatari Okouya
> Sent with Airmail
> From: Dave Reynolds Dave Reynolds
> Reply: [email protected] [email protected]
> Date: December 11, 2013 at 9:47:51 AM
> To: [email protected] [email protected]
> Subject: Re: Jena TDB and Jena Inference cooperation underlying
mechanics
> There's no specific integration of TDB and inference.
>
> The rule-based inference engines themselves run in memory but can
> operate over any model, however it is stored. So there are several
options.
>
> 1. Construct an InfModel over a TDB based model. When you query the
> InfModel you will see both the TDB model and any inferences.
>
> 2. Load the TDB model into memory then construct an InfModel over
that.
> Then query the InfModel.
>
> 3. Prepare an inference closure and store that. Load the data, e.g.
into
> memory, construct the InfModel, query the InfModel for the patterns
you
> are interested in (which might be every triple) store all those
results
> in a TDB model. Then at run time open the closure TDB as a plain
model
> and query it.
>
> 4. As 3 but use TDB's high performance RDFS-subset closure.
>
> #1 is easy to do but the inference results are stored in memory so it
> doesn't enable you to scale to models that wouldn't fit in memory
anyway.
>
> #2 can be faster. Inference involves a lot of queries and query to
an in
> memory model is naturally faster than querying TDB. Whether the
cost of
> the initial load outweighs the speed of inference depends on how
caching
> works out, your data and your queries.
>
> #3 gives you good query performance at the cost of an expensive slow
> cycle to prepare the data. It's not suited to mutating data and
requires
> the preparation phase to be run on a machine with enough memory to
> compute the closure, or closure subset, that you want.
>
> #4 can cope with much larger data sets than #3 at the expense of a
more
> limited range of inference.
>
> Dave
>
>
>
> On 10/12/13 21:58, Daniel Maatari Okouya wrote:
>> Dear All,
>>
>> If they can work together, I would like to understand a bit better
the underlying mechanics of making Jena TDB and the Jena Inference
infrastructure work together.
>>
>>
>> Hence, I have the following question:
>>
>>
>> 1-Can someone have the Jena TDB act like Stardog, in the sense
that if one make a query that would include inferred triple as well ?
>>
>> If that is possible, can someone explain to me the underlying
mechanics that it would imply, knowing that i understood the
following from the documentation.
>>
>> Inferred triples are situated in an InfGraph/InfModel(warper),
which is obtained by binding a reasoner to a base Graph/Model
(understood as the one containing the asserted triples). One can
query that infGraph using the Querry engine ( However this is
happening on an InMemory models).
>>
>> My guess here is that if a model is in the TDB, then for our query
to include the inferred triple, this would requires that, the querry
to the model is actually run against the InfModel/Infgraph. However i
don’t know if that is possible and how exactly TDB would do that?
Indeed, that would mean choosing a reasoner, creating the infmodel,
and exposing it in lieu of the base model.
>>
>> Can someone explain a bit that mechanics, that is how it works
with Jena TDB, if one wants some inference. For instance, if the
actual model is RDFS or OWL ? how to query it and obtain answer that
include the inferred knowledge. Many thanks
>>
>> Best,
>>
>> -M-
>>
>>
>>
>> --
>> Daniel Maatari Okouya
>> Sent with Airmail
>>
>
>
