SPARQL Construct

[Dexagod]

So a while ago I took a look at the possibility of using SPARQL Construct to create rules. Below an example of mellon scenario 5.1.

When using SPARQL Construct in this way, a set of triples is constructed according to the Construct clause, based on the matching data found in the WHERE clause. This has the advantage that it is easy to reuse data specified in the WHERE clause in the Construct Clause.

In case the WHERE clause finds no match in the input, the Construct clause has no results.

The resulting set of triples then form the actions that have to be taken by the orchestrator, which has to interpret these actions itself from these resulting triples.

HOWEVER this approach does not really provide an inherent way to model scheduled triggers and resource-based triggers. Scheduled triggers could make use of dates in SPARQL, but this would make repeating triggers ever hour rather difficult (also because the script would have to be run at set time intervals to check for this). So these cases would then best be handled through other means (websocket, cron, ...), and have a dummy notification be sent to the inbox to trigger certain actions.

#
# See:
#   https://mellonscholarlycommunication.github.io/coar-usecases/mellon-scenario.html#maintainer-announces-a-finished-artefact-in-the-data-pod
#
rulebook "Maintainer Announces a (finished) artefact in the Data Pod"

rule "Notify a registration service about a new publication"
______________________________________________________________________________

@prefix myself:        <https://pod.institution.org/reseacher/alice/profile/card>
@prefix eventlog:        <https://pod.institution.org/reseacher/alice/scholarlycontributions/eventlog>
@prefix registration:  <https://repository.institution.org/inbox>
@prefix as:            <https://www.w3.org/ns/activitystreams#>
@prefix coar-notify:   <http://purl.org//coar/notify_vocabulary/>
@prefix sorg:          <https://schema.org/>
@prefix rdf:           <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
@prefix pol:           <https://www.example.org/ns/policy#>
@prefix fno:           <https://w3id.org/function/ontology#>

CONSTRUCT 
{
  ?action a pol:Action.
  ?action sorg:description "Actions to be taken on receiving a new publication"

  # Send a notification to a registration hub
  ?action pol:executes [
    a fno:Execution ;
    fno:execute  pol:sendActivity ;
    pol:type     pol:AnnounceScholarlyWork  ;
    # This could maybe be used as a default value for the as:target
    # when no target is provided by the notification
    as:target    <registration>:
  ]

  # Append to the Artefact EventLog
  ?action pol:executes [
    a fno:Execution ;
    fno:executes pol:appendToLog ;
    # the target log to append to is the 
    as:target    ?eventlog:
  ]
}
WHERE
{
  # An AS2 Announce was received...
  ?notification a as:Announce .

  # ...from myself
  ?notification as:actor myself: .

  # ...about a new publication
  ?notification as:object ?object .
  ?object a ?type .

  # ... of a type in the given array of possibilities
  VALUES ?type { schema:Article schema:Review schema:Dataset }
}

[mielvds]

I believe @phochste and I came to a similar conclusion: all triggers should be available to the rule language as notifications. How resource/scheduled triggers are implemented is indeed up to the orchestrator.

Big side-remark though: if Rulebooks are meant to be shared, then they need to include a description of the scheduled trigger at hand.

Case: a university's rulebook declares that new artefacts should be announced to a specific index every month. Two researchers implement this rulebook. How can their orchestrators know what to schedule and how do you ensure they schedule the same?

[mielvds]

See also #2