Catch-22 on Imported Classes?

Posted by Mike Bergman on May 21, 2020; 9:12pm
URL: http://owlready.306.s1.nabble.com/Catch-22-on-Imported-Classes-tp1798.html

Hi Jean-Baptiste,

owlready2 is fantastic stuff (even though there are still some rough edges. ;) ). Thanks!

I am importing large sets of CSV files of classes that define the structural (subClassOf) relationships in my ontology. I begin with a small ontology stub, and then import from there. The input CSV files are simple s-p-o text files, not in any particular order. Each class in the input files also has a line devoted to it assigning to owl:Thing.

The input routine has two passes. The first loop defines the new class to the stub ontology (via Thing) per the documentation:

id = types.new_class(id_frag, (Thing,))

The second pass then assigns the actual parent class to the new class. (NB: this loop was pretty hard to debug because variable types needed to be either strings or classes, depending):

id.is_a.append(parent)

Both of these loops are now working fine. However, the import file reflects a nice hierarchical structure, with NONE of the new classes a direct child of owl:Thing. (Thing is initially required per the documentation to register the classes in the first place.) The starting stub ontology has the actual tie-in points for the upper new classes; all imported new classes are ultimately descendants of owl:Thing. I want to remove the superfluous owl:Thing assignments now that the new classes have been imported successfully.

To do so, in an interactive environment, this statement works fine:

id.is_a.remove(owl.Thing) or id.is_a.remove(var)

But, when embedded in the loop, this statement always fails. I have tried all sorts of combinations of commands and named or prefixed classes. One trick is to make sure my variable references are typed as classes using a tip discussed in these lists:

id = getattr(rc, parent)

But, if parent is so classed in the routine it seems to fail. (That was also the case when trying to use a second superclass in the tuple with Thing in the first loop.)

My suspicion is that Thing is universally global (even more than World) and is not reachable with this standard call.

Any ideas about how to use these methods correctly or workarounds?

Thanks for your tool and your time,

Mike