Add easy way to serialize CUDS objects

[pablo-de-andres]

In GitLab by @urbanmatthias on Jun 8, 2020, 17:42

• update __getstate__
• implemet a to_json method
• add a method to utils

[pablo-de-andres]

In GitLab by @urbanmatthias on Jun 8, 2020, 17:42

changed the description

[urbanmatthias]

The main problem here is that each cuds object is connected to a session, and this session should not be serialized. When deserializing the user would have to specify the session to which the objects schould be connected to. Furthermore it must be decided whether these objects should be added to any buffer. And if they should to which buffer. All of this make serialization a lot more complicated than one might expect.

Some example code can be found here:

https://github.com/simphony/osp-core/blob/0da7b0ce18c1db9ea7b3ef91bd3dc2dd17f1b33a/osp/core/utils/general.py#L51

https://github.com/simphony/osp-core/blob/0da7b0ce18c1db9ea7b3ef91bd3dc2dd17f1b33a/osp/core/utils/general.py#L77

[urbanmatthias]

Of course we want to not only serialize the cuds object itself, but also the contained objects, as it is done in the post method by calling the find_cuds_object method.

[urbanmatthias]

I think the easiest is:

• for serialize we should offer a method that takes a CUDS A as an input and returns a json as an ouput, that contains all the serialization of all the cuds A
• For deserialize we should offer a method where you can specify a session, where the created objects live in. The default would be the CoreSession. If someone wants to deserialize this data and not use osp-core, they need to implement their own deserialize

Other ideas:

• Have a JsonWrapper. Advantage: Uniform with DatabaseWrappers. Disadvantage: Might be cumbersome for such a simple functionality

[yoavnash]

As said in another discussion, the ouput json should be documented in a way that allows other users to implement their own converters if they would like to.

Also, would it make sense to have the converters as a separate project of OSP-core, so we could have a library of semantic converters (e.g., a cif <-> cuds [json format] converter)?

In the context of the OSP-API/MarketPlace-API, according to my understanding, the serialization should be such that two applications could exchange semantic data, also if only one of them is using OSP-core.

[aaronAB1993]

This is also what I understood Yoav. But how will that look like? As an example: Application A in the marketplace uses RDF and application B OSP-core. And now then want to exchange data. So A needs to deserialize the CUDS json into RDF. But vice versa: B needs to deserialize the RDF json into CUDS. Isn't that cumbersome? For me, the question goes back to how to exchange linked data. What about this: https://en.wikipedia.org/wiki/JSON-LD?

[yoavnash]

I think if we document the format of the JSON serialization then that should be enough for another user to implement their own converters if they wish to do so. In the reply above by Matthias, I think he presents a suggestion to offer further functionalities for supporting the decoupling of the CUDS serialization to OSP-core. Having a separate project for converters (see my previous reply) would be also a step in that direction.

I like this JSON-LD. I wonder if it would be hard to change to his format. @urbanmatthias, what do you think?

[urbanmatthias]

JSON-LD looks very interesting!

[urbanmatthias]

A library of converters is fine for me, but that also sounds like a lot of work,

[yoavnash]

It can be updated/maintained by other users (similarly to the wrappers). We should only provide the mechanism.

[aaronAB1993]

So just to be clear that I understand correctly: If application A uses some semantic technology which is not osp-core, than we have to implement two converters. JSON from A to CUDS and JSON from CUDS to A. Is that right?

And then your point is to do that explicitly in another project for converters?

[yoavnash]

Yes, I would say the conversion should be bi-directional. But maybe allow an application to implement only one direction if it doesn't need the other one?

In general, an application should be able to put in place its own converter (we probably should not implement it ourselves as we already have the OSP-core that does it). However, to show that CUDS serialization and OSP-core are truly separated, we could offer a repo of such converters (perhaps as part of the marketplace and not simphony).