I ended up using JenaUtil.getAllSuperClasses() from SPINRDF: https://github.com/spinrdf/spinrdf/blob/a7fc9a1ca7badecb9a8d858f7a8a33bb106e629f/src/main/java/org/spinrdf/util/JenaUtil.java#L401
On Wed, Oct 25, 2017 at 1:22 PM, Martynas Jusevičius <marty...@atomgraph.com > wrote: > Dave, > > I think I get it now. As you mention, we do not include subClassOf closure > during materialization, as the size grows but most of the inferences are > irrelevant. > > So we only have direct relationships in the data but are in fact looking > for an inferred one, which is not there. > > On Wed, Oct 25, 2017 at 12:36 PM, Dave Reynolds <dave.e.reyno...@gmail.com > > wrote: > >> 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 >>>>>> >>>>>> >>>>> >>>> >
