How should Orchestrator triggers be interpreted?

[phochste]

@Dexagod how should these triggers bellow be interpreted? Are these documents send to the Orchestrator at some Date/Time and the Orchestrator need to do some actions on that date. Or are these triggers created in the policy rule language themselves (e.g. every monday morning send me a wakeup call)?

{
  "@context": "https://www.example.org/ns/policy",
  "summary": "Linked Data Notification Trigger",
  "type": "DateTimeTrigger",
  "dateTime":[
    {
      "@value": "2021-12-12T20:20:20.201Z",
      "@type": xsd:dateTime
    },
    {
      "@value": "2021-12-12T21:21:21.211Z",
      "@type": xsd:dateTime
    }]
}

{
  "@context": "https://www.example.org/ns/policy",
  "summary": "Linked Data Notification Trigger",
  "type": "StateTrigger",
  "resource": "https://mypod.org/resources/
  "state": ["Create", "Update"]
}

[mielvds]

I gave it some though in the last version of the orchstrator document and I couldn't think of a realistic use of datetime triggers in a declarative rule language.The rule would be invalid once executed... and I don't see policies as things that change often.

I propose to adopt crontab syntax and for one-time time-based triggers ... not sure

[phochste]

@mielvds thanks. I've write some in my spec based on the ideas in your document.

In the document I assume that something in the (Orchestrator?) environment generates the triggers as AS2 documents, which are then can be processed by the policy language.

How these triggers get defined I am not sure yet. What I do know is that there can be many rules what to do when the state of a resource changes or when a datetime trigger is due.

My gut feeling is that the cron and resource monitor function is part of the Orchestrator, but separate from the policy/rule "processor". The policy processor acts when one of these cron/resource-montitors fires a notification.

[mielvds]

My gut feeling is that the cron and resource monitor function is part of the Orchestrator, but separate from the policy/rule "processor". The policy processor acts when one of these cron/resource-montitors fires a notification.

My gut would agree; this should also be reflected by the orchestrator spec. But if I dwell on it a bit, making this separation is tricky to do nicely (also reflected by the confused state of the orchestrator spec).

Leaving the trigger generation ultimately means defining statements (eg. <#trigger1> a as:Announce; ) that the orchestrator generates and can be used inside the antecendent of the rule.

when
  ?s a as:Announce . 

For notifications, this is quite clear, but when it comes to scheduled triggers, it's a little akward, because you need

1. an identifier for the trigger that you can use in the antecedent;
2. a way to connect this identifier to for instance the cronjob

when
  ?s a ex:ScheduledTrigger; # doesn't tell you much

This would be ok if a trigger is always a certain payload - a notification, an occurred event, a resource state change - that is a closed context over which the rules are executed. Would that be an acceptable approach?

[phochste]

@mielvds Yes this seems to be an acceptable and quite elegant approach: whatever you want the Orchestrator to act on , it should be in the form of a notification. In the rules spec I give one example for a DateTimeTrigger notification that can be send to the Orchestrator:

{
  "@context": [
      "https://www.w3.org/ns/activitystreams",
      "https://www.example.org/ns/policy"
  ] ,
  "summary": "Time Trigger",
  "name": "Weekend"
  "type": [ "Announce" , "pol:DateTimeTrigger" ],
  "startTime": "2021-07-09T17:00:00-01:00" ,
}

As an alternative: I've tried last week to use the rule language itself to create a scheduled trigger event. This would in principle be possible but it felt a bit over-engineered as a first attempt to write rules. It requires a way to bootstrap the Orchestrator to write a new rule.

1. Send ScheduledTriggerConfiguration to Orchestrator
2. Orchestrator creates a new ScheduledTrigger rule and start a new cronjob based on this configuration
3. Cronjob sends a ScheduledTrigger notification to the Orchestrator
4. Ochestrator acts on the ScheduledTrigger

[mielvds]

option 1 is indeed more elegant. This essentially make it a 'act on linked data notifications' rule language, which has a nice clear scope.

A follow up action would then be to define the terms with which you can create 'trigger notifications'. I suggest to draft these in https://github.com/MellonScholarlyCommunication/spec-orchestrator and then eventually move them to https://github.com/MellonScholarlyCommunication/spec-notifications. Or do you prefer to draft them in this spec?

[phochste]

@mielvds This spec should only have some example. Where is really happens is in spec-notifications.