You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Martynas Jusevičius <ma...@atomgraph.com> on 2017/10/24 22:51:53 UTC
[3.0.1] listSuperClasses() does not traverse?
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
Martynas
Re: [3.0.1] listSuperClasses() does not traverse?
Posted by George News <ge...@gmx.net>.
Hi,
I prefer not to use another library and use SPARQL directly, which at the end is more scalable and less prone to changes.
Model schema =
FileManager.get().loadModel("file:myontology.owl");
Model data = FileManager.get()
.loadModel("file:mydata.jsonld");
String myClass = "http://purl.org/MyClass";
String individual = "http://myindividual";
String queryString =
"PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>\n"
+ "PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>\n"
+ "CONSTRUCT { <" + individual + "> "
+ " rdf:type ?superClass .} " + "WHERE { <"
+ myClass
+ "> rdfs:subClassOf+ ?superClass . FILTER (!isBlank(?superClass))}";
Query query = QueryFactory.create(queryString);
try (QueryExecution qexec =
QueryExecutionFactory.create(query, schema)) {
Model model = qexec.execConstruct();
data.add(model);
}
Does anybody know how to include classes that are related based on the equivalentClass?
Regards,
Jorge
On 2017-10-25 16:27, Martynas Jusevičius wrote:
> 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 <martynas@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.reynolds@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
>>>>>> <da...@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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>
>
Re: [3.0.1] listSuperClasses() does not traverse?
Posted by Martynas Jusevičius <ma...@atomgraph.com>.
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 <martynas@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.reynolds@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
>>>>> <da...@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
>>>>>>
>>>>>>
>>>>>
>>>>
>
Re: [3.0.1] listSuperClasses() does not traverse?
Posted by Martynas Jusevičius <ma...@atomgraph.com>.
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 <da...@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
>>>> <da...@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
>>>>>
>>>>>
>>>>
>>>
Re: [3.0.1] listSuperClasses() does not traverse?
Posted by Dave Reynolds <da...@gmail.com>.
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
>>> <da...@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
>>>>
>>>
>>
Re: [3.0.1] listSuperClasses() does not traverse?
Posted by Dave Reynolds <da...@gmail.com>.
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.
Dave
> On Wed, Oct 25, 2017 at 9:33 AM, Dave Reynolds <da...@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
>>
>
Re: [3.0.1] listSuperClasses() does not traverse?
Posted by Martynas Jusevičius <ma...@atomgraph.com>.
Thanks Dave.
We are materializing inferences during ontology initialization to avoid
using reasoner subsequently (as it impacts performance).
So in that case I need to traverse the chain myself, correct?
On Wed, Oct 25, 2017 at 9:33 AM, Dave Reynolds <da...@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
>
Re: [3.0.1] listSuperClasses() does not traverse?
Posted by Dave Reynolds <da...@gmail.com>.
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