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 <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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>
>
