Platform communication

[ml-evs]

https://docs.google.com/document/d/1ktCBNyhrj5OOXq_gLeqhnqLde-PmjMBZXd98tau1PXE/edit?usp=sharing

[martin-held-hereon]

Platform-agnostic interoperability THREAD

[s4b7r]

Group 1: Request, registry, bridge ontology

Group 2: Response, JSON-LD, RO-Crate.

In the complete group Platform communication we agreed on minimum data: id and type

[martin-held-hereon]

Group 1: Request, registry, bridge ontology

[martin-held-hereon]

Assumption: The concept of an IRI is immutable.

[s4b7r]

Group 1: Request, registry, bridge ontology

[s4b7r]

Assumption: The concept of an IRI is immutable.

We meant: The concept linked to by an IRI must never change. Meaning: same IRI => same concept all the time / new version of the concept => new IRI (had to make that explicit in our discussion)

[edan-bainglass]

Point-to-point connection THREAD

[edan-bainglass]

Tasks

1. Design direct comms APIs between AiiDAlab and

• openBIS
• chemotion
• NOMAD
• NMRShiftDB

2. PoC (AiiDAlab <-> openBIS)

• Demonstrate operations in some way (TBD)

[edan-bainglass]

Open issues

• Authentication
• Semantic mapping
• Including data converters in mapping

[martin-held-hereon]

• virtualize registry
• filtering
• paging
• caching

[martin-held-hereon]

• address "WHat if platform doesn't have an IRI?"

[edan-bainglass]

@s4b7r, @martin-held-hereon could you elaborate on "virtualize registry"? I missed this discussion.

[s4b7r]

@s4b7r, @martin-held-hereon could you elaborate on "virtualize registry"? I missed this discussion.

We tried to cover that discussion in the request-specs as well. You can find it under "exact role of the registry". However, I have to admit we went over that kind of quick and did not formulate it as thoroughly as the first parts. I will try to make that a bit clearer and prepare a pull request.

To summarize quickly: The idea is that we could have a central registry, but that the spec so far is agnostic to that. The reason being: If some additional software component in your client sends the same query to multiple endpoints (e.g. for available types at the endpoints), this would be in a way a virtual registry: just a point where information of multiple endpoints is collected and relayed. "Virtual" because there is no extra host/service that makes up that registry but it is an additional software step. If we do the specification of that "registry interface" right, there is nearly no difference whether that registry is inside the client software, on a dedicated central host, or even multiple registries are hosted somewhere, e.g. if you need one specifically internally in your own institution.

[s4b7r]

I opened an issue in MADICES/interop-specs#5 for that

[stefhk3]

I have done the ro-crate export for nmrshiftdb2. How do we proceed here and discuss things? Is this page the place to go?

[stefhk3]

I used nmredata, but this is not using ontologies. I am thinking about extending it. Do you think that makes sense? Or is this completely irrelevant?

[martin-held-hereon]

We always wanted to keep the interop solutions open to non-ontologized cases, so I think it makes sense. Mikail's software and our interop concept have some sort of ID that can be used as an IRI as the only requirement, IIRC.

[edan-bainglass]

I agree. We need to keep in mind that two approaches were proposed: (i) semantically heavy (our work), and (ii) central format (proposed by Sasha). For ii, there was little use of ontologies. We should consider this approach as well in discussion. I will invite Sasha to the chat.

Note that I will contribute very little to the convo until end of month. We have both MADICES and PREMISE reports to deal with 😮‍💨 That said, thanks for keeping the chat going. I'll keep an eye and jump back in early next month. Cheers 🙂

[s4b7r]

Actually the concept of approach (i) does also not necessarily require heavy use of ontologies. I think it probably could in the simplest case also work without an ontological description behind the IRI. If we boil it down, the parts of querying available data types, and querying and updating those items also work without an ontological description. The important first step is to have that type "named" at all - and that is given by just having an IRI that is the reference to a type.
An ontological description of that could be added later. That gets important at least in that moment we want to think about the logic for mapping between types.

[edan-bainglass]

Technically correct. Also note that Mihai's demo (two web apps interacting via semantically annotated RO-Crates) has been greatly extended in the past week to cover more of approach (i). Indeed, it works simply through the existence of IRIs. I intend to set up a meeting with our platform comms group to present and discuss next steps in June.

[stefhk3]

Hi all, how are things going? I am a bit confused right now what we have, but I would love to get the nmrshiftdb2 integration done. As I said, I have the export implemented, take https://nmrshiftdb.nmr.uni-koeln.de/download/NmrshiftdbServlet/80124088_1H.jpeg?nmrshiftdbid=20182362&nmrshiftdbaction=madices as an example. How do we proceed best?

[s4b7r]

Maybe to clear some confusion: Is this regarding the interoperability specifications as given here or regarding "direct comms APIs between AIIDA and.."? We should probably split up this discussion page as it has quite a number of different things in it and that confuses me a bit now as well.

[s4b7r]

@stefhk3 if this discussion is closed because of my suggestion to Edan and you are unsure where to reply, I would say, just open an other discussion in this project. Or if you can relate it to them, it could fit into the interop-spec or interop-demo repos, I think.

[s4b7r]

@edan-bainglass I am not to familiar with the discussion feature in GitHub: is there an option to close discussions and would you do that here? I'd suggest that makes sense because this now very long page has mainly developed to be the documentation place for the MADIICES workshop. I think we can have a better overview and less confusion, if we close this discussion and open new ones for specific topics when they arrive - as stefhk3's did.

[edan-bainglass]

@s4b7r Apologies for the lack of communication. I am recovering from a 2+ week long case of Pneumonia 😷 Just getting back to things slowly this week. I will address your questions on Monday.

[edan-bainglass]

@s4b7r I'm back! I agree with the length of this discussion getting a bit out of hand. Let's proceed as you say and open focused discussions as they come. Closing this one for now!