Serialising owlready2 object

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Serialising owlready2 object

cdemir
Dear all,

thank you for Owlready2. I am using it on daily basis and I think it is great. That being said, I would like to know your opinion on the following matter.
Let A be an instance of Python class that wraps owlready2.entity.ThingClass. Following, A.owl corresponds to an object from owlready2.entity.ThingClass. Hence

A.owl  => family.Person
type(A.owl) => <class 'owlready2.entity.ThingClass'>

I would like to serialise A (save it as binary format). Using pickle directly I got this=>_pickle.PicklingError: Can't pickle family.Person: attribute lookup Person on owlready2.entity failed. Expectedly, if I set A.owl to an empty string (e.g. If A.owl=" "), then pickling it works.

What am I missing here ?

Cheers,

Caglar Demir
Reply | Threaded
Open this post in threaded view
|

Re: Serialising owlready2 object

Jiba
Administrator
Hi,

It seems that owlready objects are not serializable with Pickle. Actually, I never asked me the question of serialization, since the Owlready quadstore is an effective alternative for storing data.

I think that serializing Owlready object woul dbe very complex, but maybe you can define some Pickle routine for serializing the entity IRI, and then, at deserialization, recover the entity by its IRI (provided that the ontology was previously loaded) ?

Jiba
Reply | Threaded
Open this post in threaded view
|

Re: Serialising owlready2 object

cdemir
Hello Jiba,

funny enough, I indeed have already implemented somewhat similar routine which appears to be working. However, this workaround implicitly introduce an overhead. Please consider the following scenario if you are interested in:

1) Let's say we have many (>10^6) As each of which has
A.owl =>  family.Person
A.instances =>  {family.X, family.Y} where family.X and family.Y are instances/individuals belong to A.owl. We call such A as a concept object.

2) Such concept objects  are not contained in the originally given ontology as we generate them by applying logical operations [1]. Consequently, instances/individuals in A.instances do not have type information (.is_a()) of newly generated concepts [2]. Besides, I must admit that I like .is_a() convention a lot as it can be used for instances as well as classes :)

3) After some computation, we would like to serialise some concept objects.

4) In the serialisation phase, we have to include  the type information of instances belonging to newly generated concept objects explicitly and then save the ontology. By doing so, we can save/serialise/store information that is encoded in newly generated concept objects.

        for A in selected_concepts:
          for i in A.instances:
                     i.is_a.append(A.owl)

This would be very time consuming.

5) In the deserialization phase, we simply load all classes and fill concept objects

Cheers,

Caglar Demir

[1] https://owlready2.readthedocs.io/en/latest/restriction.html#logical-operators-intersection-union-and-complement

[2] https://pythonhosted.org/Owlready2/class.html#mutli-class-individuals