SIOC Post profile for "AI3:::Adaptive Information"
type: Document
description: A SIOC profile describes the structure and contents of a weblog in a machine readable form. For more information please refer to http://sioc-project.org/.
primary topic: CWPK #17: Choosing and Installing an OWL API
generator agent: http://rdfs.org/sioc/wp-sioc.php

CWPK #17: Choosing and Installing an OWL API
type: Post
has container: weblog
has creator: Mike Bergman
maker: Mike Bergman
created: 2020-08-18T14:40:27Z
content: owlready2 Appears to be a Capable Option In the CWPK #2 and #4 installments to this Cooking with Python and KBpedia series, we noted that we would reach a decision point when we needed to determine how we will manipulate our knowledge graphs (ontologies) using the Python language. We have now reached that point. Our basic Python environment is set (at least in an initial specification) and we need to begin inputting and accessing KBpedia to develop and test our needed management and build functions. In our own efforts over the past five years or more, we have used the Java OWL API initially developed by the University of Manchester. The OWL API is an integral part of the Protégé IDE (see CWPK #5) and supports OWL2. The API is actively maintained. We have been very pleased with the API's performance and stability in our earlier KBpedia (and other ontology) efforts. In our own Clojure-based work we have used a wrapper around the OWL API. A wrapper using Python is certainly a viable (perhaps even best) approach to our current project. We still may return to this approach for reasons of performance or capabilities, but I decided to first explore a more direct approach using a Python language option. This decision is in keeping with this series' Python education objectives. I prefer for these lessons to use a consistent Python style and naming conventions, rather than those in Java. I was also curious to evaluate and test what presently exists in the marketplace. We may gain some advantages from a more direct approach; we may also discover some gotchas or deadends that initial due diligence missed. We can always return to Plan B with a wrapper around the existing OWL API. If we do need to revert and take the wrapper approach, the leading candidate for the wrapper is py4j. Initial research suggests other Python bridges to Java such as Jython or JPype are less efficient and less popular than py4j. pyJNIus had a similar objective to py4j but has seen no development activity…
encoded: owlready2 Appears to be a Capable Option In the CWPK #2 and #4 installments to this Cooking with Python and KBpedia series, we noted that we would reach a decision point when we needed to determine how we will manipulate our knowledge graphs (ontologies) using the Python language. We have now reached that point. Our basic Python environment is set (at least in an initial specification) and we need to begin inputting and accessing KBpedia to develop and test our needed management and build functions. In our own efforts over the past five years or more, we have used the Java OWL API initially developed by the University of Manchester. The OWL API is an integral part of the Protégé IDE (see CWPK #5) and supports OWL2. The API is actively maintained. We have been very pleased with the API’s performance and stability in our earlier KBpedia (and other ontology) efforts. In our own Clojure-based work we have used a wrapper around the OWL API. A wrapper using Python is certainly a viable (perhaps even best) approach to our current project. We still may return to this approach for reasons of performance or capabilities, but I decided to first explore a more direct approach using a Python language option. This decision is in keeping with this series’ Python education objectives. I prefer for these lessons to use a consistent Python style and naming conventions, rather than those in Java. I was also curious to evaluate and test what presently exists in the marketplace. We may gain some advantages from a more direct approach; we may also discover some gotchas or deadends that initial due diligence missed. We can always return to Plan B with a wrapper around the existing OWL API. If we do need to revert and take the wrapper approach, the leading candidate for the wrapper is py4j. Initial research suggests other Python bridges to Java such as Jython or JPype are less efficient and less popular than py4j. pyJNIus had a similar objective to py4j but has seen no development activity…
topic: CWPK
topic: KBpedia
topic: Semantic Web Tools
has reply: comment-507618
has reply: comment-507619
has reply: comment-507810
has reply: comment-507811
links to: CWPK #2
links to: #4
links to: Cooking with Python and KBpedia
links to: Python
links to: KBpedia
links to: Java
links to: OWL API
links to: Protégé
links to: IDE
links to: CWPK #5
links to: OWL2
links to: Clojure
links to: py4j
links to: Jython
links to: JPype
links to: pyJNIus
links to: ROBOT
links to: link through py4j
links to: RDFLib
links to: RDF
links to: FuXi
links to: SuRF
links to: rdftools
links to: owlib
links to: infixowl
links to: SETH
links to: JVM
links to: CVS repository
links to: funowl
links to: ontobio
links to: owlready2
links to: CRUD
links to: existing extension
links to: N3
links to: N-Triples
links to: download this converted file from here
links to: MyBinder
links to: GitHub
links to: file path cwd.html
links to: pathlib.html
links to: pythons-with-open-as-pattern
links to: chapter8
links to: cb1-1
links to: cb1-2
links to: cb2-1
links to: cb3-1
links to: cb3-2
links to: cb3-3
links to: cb3-4
links to: cb4-1
links to: cb4-2
links to: cb4-3
links to: cb6-1
links to: cb6-2
links to: cb6-3
links to: cb6-4
links to: cb6-5
links to: cb7-1
links to: cb7-2
links to: cb7-3
links to: cb7-4
links to: cb7-5
links to: cb8-1
links to: cb8-2
links to: cb8-3

Mike Bergman
type: User

Mike Bergman
type: Person

Cooking with Python and KBpedia
label: CWPK listing

academic paper

owlready2 documentation

PyPl project

conda-forge project

Source files

owlready2 .load() function

Mailing list

KBpedia

direct download

notify me