I am trying to use Jena API to create a hierarchy of OWL ontology, which is similar to the one created by Protege. I have tried two methods to get subclasses of owl:Thing and then recurs for next levels.:
Using the listSubClasses(true)
Using the listHierarchyRootClasses()
They both have worked for the OWL classes having rdfs:subClassOf as owl:Thing. However, for OWL complex classes (owl:unionOf, owl:intersectionOf, and owl:complementOf), the first method has not listed anything. While the result of the second method has not been as correct as Protege. It often includes more subclasses of owl:Thing than Protege does.
Someone said that is the limitation of Jena API. Is it true? Should I switch to using OWL API instead of Jena? I would like to have your advice.
What's missing is a reasoner. You cannot have complete results without using a reasoner to infer subclass relationships. this is true for both Jena and OWL API.
Related
I'm using Hermit Reasoner with OWL-API 5 as follows:
OWLOntologyManager manager= OWLManager.createOWLOntologyManager(); //create the manager
OWLOntology ontology=manager.loadOntologyFromOntologyDocument(new File("ontologies/E1G1.owl"));
OWLDataFactory datafact=manager.getOWLDataFactory();
Configuration config= new Configuration();
Reasoner reasoner= new Reasoner(config, ontology);
reasoner.classifyClasses();
reasoner.classifyDataProperties();
reasoner.classifyObjectProperties();
System.out.println(reasoner.isConsistent());
Now I would like to execute SPARQL Query in analogous way as Protégé SPARQL Plugin over the inferred ontology. I'm experimenting JENA ARQ, but it is not clear to me how to integrate them. Any suggestions?
I do not think there is existing integration between Jena and HermiT. OpenPellet, a reasoner built on top of Pellet has Jena integration.
The question is whether you indeed need an external reasoner. If not you can use the OWL reasoners provided as part of Jena. See Jena OWL Reasoners.
I use Jena's OntClass.listDeclaredProperies() functions. Even every class is supposed to have all RDFS properties (e.g. rdfs:comment), listDeclaredProperies never returns any of them. How they are associated with a class and how to get them?
Update 1
I just thought that all ontology classes have also automatically declared RDFS properties. In documentation of RDFS properties is written for comment property "The rdfs:domain of rdfs:comment is rdfs:Resource". Because ontology classes are also rdfs:Resource I thought it should have the rdfs:comment property automatically and I should get it (together with other RDFS properties) by calling listDeclaredProperies function (this function returns also properties of superclasses) Probably I'm missing something about RDFS properties...
Example
So when I call listDeclaredProperies at any class (anyClass.listDeclaredProperies()), I would like to get all RDFS properties listed together with its "normal" properties. Why it doesn't work? We can add value of RDFS properties to any class or individual (e.g. label, comment etc.) Thanks for explanation.
I'm very new to the Grails framework, so please bear with me.
Nonetheless, I am a bit confused on the functionality difference between extending a domain class and embedding objects.
From a database point of view, they both do the same thing. When embedding an object, all the properties of all the classes are stored in one table. Similarily, when extending a class (using table-per-hierarchy), all the properties of all the classes are stored in one table.
I'm sure there is a functionality difference between these two, and so I figured I ask this question.
When do you use either one?
The only technical difference is the ability to have multiple tables through the table per subclass property when extending a class. Otherwise, they are identical in use.
However, that said, by extending another class you are also modeling that within the class structure so you can make use of instanceof and polymorphic features of Java/Groovy.
In Jena I'm loading an ontology into a Model, using this code:
Model model = FileManager.get().loadModel("/path/myontology.owl");
My problem is that "myontology.owl" imports another ontology with owl:imports. In pseudo code lets just say that "Myontology.owl" imports other files to complete the ontology, since several individuals are declared in external files, e.g.:
In myontology.owl
Import → myontologywithindividuals.owl
My problem is that I can't import the ontology with its individuals into a single Model in Jena. That is,
Model model = FileManager.get().loadModel("/path/myontology.owl");
doesn't seem to work. Any idea why? How can I import this correctly?
Plain models in Jena don't do any processing of owl:imports, because plain RDF doesn't have any notion of importing other documents. Ontology imports are an OWL concept, and you'll need to use an OntModel if you want imports processing. You may need to use setDynamicImports() to enable import processing. If the imports statements refer to ontologies using their ontology IRI, but you want to retrieve them from a local file, you may also need to setup the OntModel's OntDocumentManager and FileManager to take care of the appropriate mapping from IRIs to local files.
I'm new to Jena, but when I look at the vocabularies defined with the Jena source (i.e. in directory: jena-2.10.0-Source\jena-core\src\main\java\com\hp\hpl\jena\vocabulary) I see some of the vocabularies create properties and resources using 'ResourceFactory.createProperty()' (e.g. OWL2.java, RDF.java, RDFS.java), whereas others in the same directory use 'ModelFactory.createDefaultModel().createProperty()' (e.g. DC_11.java, VCARD.java, DCTerms.java).
I understand that ResourceFactory is used to create resources and properties without reference to a 'model', but I just want to understand why some of these vocabs choose to create and use a 'model' instance while others choose not to.
Is it just personal style, or is one approach generally recommended over the other (maybe one style is an 'old approach', as I understand Jena has been around a long time)?
I'd like to use both the RDFS and DC_11 vocabs with my code, and obviously define my own app-specific resources and properties, so I'm just trying to understand which approach I should adopt for my own stuff.
That both styles are used is just historical accident. I think these days, I'd probably suggest using the ResourceFactory approach, simply because it avoids the (small) overhead of allocating a model, and the model gives you no real advantages. At some point, we'll probably go back and do some refactoring to just use a single approach in the Jena codebase.