search

RDFLib / OWL-RL

A simple implementation of the OWL2 RL Profile on top of RDFLib: it expands the graph with all possible triples that OWL RL defines. It can be used together with RDFLib to expand an RDFLib Graph object, or as a stand alone service with its own serialization.
http://www.ivan-herman.net/Misc/2008/owlrl/
Other
138 stars 30 forks source link

Rename OWL-RL to OWLInf #35

Open nicholascar opened 4 years ago

nicholascar commented 4 years ago

OWL-RL's original goal was to perform OWL-RL reasoning so "OWL-RL" has been an appropriate name. If other reasoning profiles are added, and RDFS is already available, then the name could/should be changed.

I propose to change the name to OWLInf, for OWL Inferencer.

iherman commented 4 years ago

I understand and agree with the thought, but I am just worried that we may break something... For example, all applications may have to change their import statements, which may become a royal pain:-(

nicholascar commented 4 years ago

I am just worried that we may break something

Yes indeed, hence raising this in an issue to give a long lead time on changes!

I may have a student about to start who will implement EL & QL en route to doing a number of other things and this clearly won't be an overnight things (perhaps 6 - 12 months) so that's the sort of timeframe I had in mind.

In fact, reviewing the block diagram of RDFlib parts (see https://rdflib.dev) and the proposal to bring FunOwl into the RDFlib family (I've spoken with Harold about this), I think we might be due a whole rethink about OWL-in-Python and coordinating that a bit better with other projects too such as OwlReady2. That's a bigger task but I think a rename here would better position this toolkit to take an obvious place in a future OWL-in-Python landscape.

cknoll commented 3 years ago

Although it might get offtopic wrt. this issue here, the appraisal that

we might be due a whole rethink about OWL-in-Python and coordinating that a bit better with other projects too such as OwlReady2

seems very reasonable to me.

Background: I work with Python since 2008, mostly in engineering (numpy, scipy, sympy, ...) and web development (django) and made the experience that almost all solutions to basic problems are at most one combination of pip install ... and import ... away. However when it comes to semantic web technologies the situation seems to be much less satisfactory. E.g., it took me several hours to accept out that currently there seems to be no way of parsing OWL in Manchester syntax to owlready2 objects.

My impression is that on a broad scale semantic (web) technology has not yet really taken off – compared to the huge potential it has.

IMHO, the surprisingly thin, scattered and inconsistent Python support for these technologies contributes to this. In comparision e.g. with numerical machine learning (tensorflow, pytorch, scikit-learn, ...) the number and size of semantic-related python projects is quite small. Numerical machine learning as whole topic has benefitted significantly from good python support for its methods. I would really appriciate a similar dynamics for semantic technologies.

Establishing some kind of (self-) "coordination" or at least communication between the existing semantic-related python projects seems therefore very promising to reduce friction and spawn more activity.

The following things I would consider worthwile:

  1. Establishing a mailing list or similar communication platform for people interested in python and semantics (but not project-specific).
  2. Gathering the knowledge which kind of problems are already solveable via python and which are not.
  3. Raising awareness for a broader audience (and maybe contributions/funding) to improve the feature set and interoperability of the respective tools.

Regarding point 2.: This repository is my first a attempt in that direction. Feel free to open issues or pull requests.

Suggestsion to prevent derailing this issues: If you have comments on theses thoughts please consider posting them to this discussion.

cknoll commented 2 years ago

Just as a followup on my previous post (a year ago): I set up some infrastructure at https://pysemtec.org and invited some people (including the maintainer of owlready2) to form a group in which above mentioned coordination could take place.

majidaldo commented 1 year ago

I understand and agree with the thought, but I am just worried that we may break something... For example, all applications may have to change their import statements, which may become a royal pain:-(

this can be totally managed by the library and the library users. i don't see it as an argument against.