Custom IRIs of CUDS get lost when CUDS are serialized and deserialized again

[MBueschelberger]

@kysrpex, I am currently running this example for building a dcat2:Resource-CUDS with a custom IRI.

When I do a pretty_print, everything is instanciated as expected:

- Cuds object:
  uid: 41942304-d669-4a31-88ef-3a95ee61b3ca
  type: emmo.CifImportWorkChain
  superclasses: emmo.AiiDA, emmo.AiiDANode, emmo.AiiDAWorkChain, emmo.CifImportWorkChain, emmo.EMMO, emmo.Graphical, emmo.Item, emmo.Language, emmo.Optical, emmo.Package, emmo.Perceptual, emmo.Perspective, emmo.Physical, emmo.Python, emmo.Software, emmo.Symbolic
  description:
    To Be Determined

   |_Relationship emmo.hasInput:
     -  emmo.QueryForCrystallographyOpenDatabase cuds object:
        uid: 22788c6d-6719-4405-9305-ba30723285cf
         |_Relationship dcat.downloadURL:
         | -  dcat.Resource cuds object:
         |    uid: http://localhost:8000/api/v4/nodes/70aec7a7-e9e5-4150-9d93-ed1414e2fba8?jsonpath=$.data.attributes
         |_Relationship dcat.mediaType:
         | -  dcterms.MediaType cuds object:
         |    uid: https://www.iana.org/assignments/media-types/application/json
         |_Relationship emmo.INVERSE_OF_hasInput:
           -  emmo.CifImportWorkChain cuds object:
              uid: 41942304-d669-4a31-88ef-3a95ee61b3ca
              (already printed)

However, when I use the post-function to serialize to a REST API and use a _deserialize_cuds_object on the payload, the custom IRIs were disregarded:

- Cuds object:
  uid: 41942304-d669-4a31-88ef-3a95ee61b3ca
  type: emmo.CifImportWorkChain
  superclasses: emmo.AiiDA, emmo.AiiDANode, emmo.AiiDAWorkChain, emmo.CifImportWorkChain, emmo.EMMO, emmo.Graphical, emmo.Item, emmo.Language, emmo.Optical, emmo.Package, emmo.Perceptual, emmo.Perspective, emmo.Physical, emmo.Python, emmo.Software, emmo.Symbolic
  description:
    To Be Determined

   |_Relationship emmo.hasInput:
     -  emmo.QueryForCrystallographyOpenDatabase cuds object:
        uid: 22788c6d-6719-4405-9305-ba30723285cf
         |_Relationship dcat.downloadURL:
         | -  dcat.Resource cuds object:
         |    uid: 7814ed6c-9fca-415b-a289-09e223f4d960
         |_Relationship dcat.mediaType:
           -  dcterms.MediaType cuds object:
              uid: f3fc82ea-c34c-420b-a81e-bbc06574db42

Is it this behaviour related to a filter in a low-level osp-core-function which is parsing the JSON-LD for an owl:NamedIndivudual containing the http://www.osp-core.com/cuds-namespace and hence disregards any custom IRI without this namespace?

Is there any breaking change planned for osp v.4.0.0 related to the serialisation of CUDS ? Do you think there is an opportunity to fix this issue on an upcoming release between >v3.7.0 and <v4.0.0?

[kysrpex]

Hi @MBueschelberger. Yes, I think _deserialize_cuds_object is possibly tapping into the same code that imports the CUDS from rdf, which converts custom IRIs to an UID and adds a triple with the predicate owl:sameAs to connect the two, but the "default one" is the UID. This comes from a time where a custom IRI was not supported. I think it's time to remove this behavior and just use the custom IRI. I will categorize this as a bug, which means that it must be solved within the v3 branch.

[kysrpex]

@MBueschelberger Can you install OSP-core from PR #759 and see if it solves your problem? If yes, then I will mark it as ready for review so that @pablo-de-andres or @yoavnash can have a look at it.

[MBueschelberger]

Works perfectly for me!

Thanks :)

[MBueschelberger]

Since #759 is merged, I will close this issue.