Communication of urgent changes

[ThomasJejkal]

(From HMC CCT3, Versioning discussions) As a consequence of the above: how does someone communicate an urgent patch / change to HMC central services or the whole FDO-based digital ecosystem? As a user, that is. E.g. a real-time registry of urgent patches or announcements which can be used to cross-check any holding of FDOs inside or outside Helmholtz

[Pfeil]

I feel that I am missing some point :D I remember we have talked about this, but I think I did not understand the problem correct back then also.

E.g. a real-time registry of urgent patches or announcements which can be used to cross-check any holding of FDOs inside or outside Helmholtz

I do not understand this example. Is this, like, a new version of a profile was released and Helmholtz should notify everyone to adjust their FDOs (and their software)? But that is not really urgent... What is cross-check, what do we check here? Do you have examples for patches/announcements so I can get an idea about what scenarios we are talking about and how it related to the PIT service?

[ThomasJejkal]

Well, this point was just mentioned and not discussed in detail in CCT3. As far as I remember this point came up while writing the versioning guidance document and together with the question how "revoking" or "deleting" a FAIR DO can be communicated. Another aspect was the situation, where an issue with a service will require a version update and how such breaking changes are communicated to whom.

In my opinion, it would be quite difficult to realize such thing in a good way as we do not track which version of a base service was used to create a FAIR DO.

[Pfeil]

Some thoughts on this topic.

the question how "revoking" or "deleting" a FAIR DO can be communicated

Revoking / deleting a PID is in the FAIR DO sense a change of the PID record. Currently, we communicate this as a change via AMQP. What could be considered, in future, would be to detect if a change has been a deletion or revocation. So far, I would say the FAIR DO concept is in a too early stage to implement such a feature reliably, though. But communication is already happening.

situation, where an issue with a service will require a version update

I think in such a case this is more a matter of the model within the FAIR DO rather than the Typed PID Maker. The security issue will be added to the record, or one has to regularly check the chain of new versions for this information. And this change has to be detected somehow.

how such breaking changes are communicated to whom

1. I think the simplest solution is to look (for example) once a week into the PID record of a software in use and check for issues. This method would not be in the scope of the Typed PID Maker. The approach is similar to RSS/Podcasts (poll-based).

2. If one wants to rely on notifications (which are potentially faster), approaches like the messaging approach pop in. But it does not mean the Typed PID Maker has to be in charge of this specific type of notification. I can imagine semantic watchers, which take the notifications of the Typed PID Maker and send messages with more semantic or contextual detail. But this requires that the message broker receives messages about the changes of the FAIR DO to be watched. This is quite a strong assumption in a global environment. The messaging approach here does not fulfill the needs of the use case.

In some sense, the Typed PID Maker can be used for approach 1. With ETag support in Version 2.0 (soon(TM)), one can get a token representing the state. If one regularly resolves the PID using the Typed PID Maker, and the token changes, this means the PID has to be (semantically) checked for issues. For approach 2, we would need either some global network to get such changes from the creators source directly, or use an often-polling implementation of approach 1.

We could add an API which polls certain PIDs (those which are requested to be watched) in the background and then send a message if it changed, even if we are not the owners of this PID. This would enable us to integrate PIDs from others in the same workflow we currently offer for "owned PIDs". In future, it could even consider semantic details for often-needed use cases. Although I think we are somehow a bit far from the last part.

API extensions could be (pseudo markup):

watchPID(pid) -> ETag
unwatchPID(pid) -> ETag
getNotificationsViaRest(pid, Etag) -> List<Event>
// or something similar.
// Events could be: update/tombstoned/"deleted"/... whatever we also support for owned PIDs in future.

Opinions? I am not sure if I met the issuers' intention with this.