On 25/10/17 11:10, George News wrote:
On 2017-10-25 11:54, Dave Reynolds wrote:
Hi Martynas,
On 25/10/17 10:33, Martynas Jusevičius wrote:
Thanks Dave.
We are materializing inferences during ontology initialization to avoid
using reasoner subsequently (as it impacts performance).
Makes sense.
So in that case I need to traverse the chain myself, correct?
Not if you've materialized the inferences. If you have constructed the
superClass closure as part of this materialization then the closure
should be visible through the OntAPI.
If you haven't included that in your materialization then indeed you
would need to traverse the chain yourself - either in the API or via
SPARQL property paths.
What do you mean by materialize the inferences of subClass?
That's not quite the way I phrased it.
All I meant was that the reasoners will in effect compute
(?a rdfs:subClassOf ?b) (?b rdfs:subClassOf ?c)
-> (?a rdfs:subClassOf ?c)
[Though technically the builtin reasoners don't use rules for that.]
So if Martynas wants the OntClass.listSuperClasses query to work as he
expected then he would need to include that in the materialization.
So, as you say, it would include things like:
ClassChild rdf:subClassOf ClassParent
ClassChildChild rdf:subClassOf ClassParent
ClassChildChild rdf:subClassOf ClassChild
It is clear
that you include the inferences for the individuals, like:
individual rdf:type ClassParent
individual rdf:type ClassChild
individual rdf:type ClassChildChild
But if I also include the materialization for the class definition, at
the end, I'm including the "full" ontology model.
ClassChild rdf:subClassOf ClassParent
ClassChildChild rdf:subClassOf ClassParent
ClassChildChild rdf:subClassOf ClassChild
Do you recommend to also include the second step?
To use the standard refrain "it depends what you are specifically trying
to do".
The benefit is that you can get all superclasses with a simple query.
The cost, apart from some size growth, is that finding direct
superclasses becomes very painful. Which is why the built in reasoners
have the support for "direct" versions which is then exposed in the
OntAPI via all the "direct" flags. That distinction can get lost in the
materialization.
Personally I would not include the subClassOf closure if materializing
but would rely on query rewriting to such questions on demand. YMMV
Dave
I'm involved in a similar procedure as Martynas.
Thanks
Jorge
Dave
On Wed, Oct 25, 2017 at 9:33 AM, Dave Reynolds
<dave.e.reyno...@gmail.com>
wrote:
On 24/10/17 23:51, Martynas Jusevičius wrote:
Hi,
I thought I understood how OntClass.listSuperClasses() works, but
maybe I
don't.
I have such a class structure in my ontology (superclass is at the
top):
3. https://www.w3.org/ns/ldt/document-hierarchy/domain#Item
2. http://atomgraph.com/ns/platform/domain#Item
1. https://localhost/admin/ns#AgentItem
Yet when I'm debugging, I can see the pair-wise relationships, but
not the
chain all the way up from 1 to 3:
1. getOntology().getOntModel().getOntClass("
https://localhost/admin/ns#AgentItem
").listSuperClasses(false).toList().toString()
[https://localhost/admin/ns#ItemOfAgentContainer,
http://atomgraph.com/ns/platform/domain#Item]
2. getOntology().getOntModel().getOntClass("
http://atomgraph.com/ns/platform/domain#Item
").listSuperClasses(false).toList().toString()
[https://www.w3.org/ns/ldt/document-hierarchy/domain#Item]
I can see that within the method hasPropertyValue(
getProfile().SUB_CLASS_OF(), "SUB_CLASS_OF", cls ) returns false.
Why is that so? Is my usage wrong?
Additional info:
getOntology().getOntModel().getSpecification().getProfile() ==
OWLProfile
getOntology().getOntModel().getSpecification().getReasoner() == null
If I recall correctly the OntModel API is designed to retrieve
whatever is
stated within the underlying model. The notion was that there was no
point
in having the OntModel API replicate what reasoning does.
So to see the subclass closure you need to have a sufficient reasoner
configured.
Dave
