pextralabs / scene-platform Goto Github PK

Besides the @part java annotation which need to be imported explicitly by the DRL package would be great to support the @part as a simple fact metadata.

declare Fever extends Situation
    febrile: Person @part("patient")
end

In order to use some experimental features like pojo-rules we have to upgrade the drools version to the latest stable release 7.0.0

The Drools runtime throws StackOverflowError when a self-relation scenario (bellow) happens

The self-relation friends causes a loop when the engine calls toStringfor the List class because in a situation of Friendship between A and B, A is inside of B's friends and vice-versa.

declare Person
    id: int
    name: String
    friends: List
end

declare Friendship extends Situation
    friendA: Person @part(label = "a")
    friendB: Person @part(label = "b")
end

rule Friendship
@role(situation)
@type(Friendship)
 when
    a: Person()
    b: Person(this != a)
 then
    SituationHelper.situationDetected(drools);
 end

The problem is AbstractCollection's toString method, a quick solution would be to offer our own List class reimplementing toString.

The scene-model and scene-core modules need to be published to maven in order to be shared.

Also, the common dependencies need to be reviewed and organized.

When setting up a KB with EQUALITY option apparently subsequent situation instances for the same cast (e, g, intermittent fevers) are taken as the same instance and not activated again despite being deactivated as expected.

The snapshot feature works great with primitive properties but when the property is an object (non-primitive type) it always gives me this:

java.lang.IllegalAccessException: Class br.ufes.inf.lprm.scene.model.Snapshot can not access a member of class co.pextra.fraud.Session with modifiers "protected"

@part annotation helps the mapping of facts in a situation rule activation to fill roles (participations) in a situation instance, however, that mapping doesn't mean the object should take part in the unicity of the situation.

In the scenario bellow, the location is a property of Session situation, but everytime the device (already enrolled in a Session) updates its location (new Location object) a new Session is created because the new hash differs from the previous Session version despite conceptually being the same. A change of location doesn't define a new Session.

declare Session extends Situation
    client: Client @part
    auth: AuthToken @part
    location: Location @part
end

rule "Session"
@role(situation)
@type(Session)
    when
        client: Client()
        auth: AuthToken(user == client)
        device: Device(auth == this.auth, location: this.location)
    then
        ...

Scene presents a critical inconsistency between complementary situations (ex: Dead/Alive, Healthy/Unhealthy). They overlap each other for the same individuals/contexts. Thus in some cases a person in the working memory can be Dead and Alive at the same time.

Olá,

o exemplo mostra que quando a pessoa está com uma temperatura corporal acima de 37.5 graus então uma situação é detectada. Ok! Mas como utilizo a API do scene para detectar a intermitência de febre? Como eu configuro o scene para me dizer o intervalo entre as ocorrências de febre e assim detectar uma intermitência febril?

O framework possui uma documentação para que eu possa estuda-la e entender tudo que o scene pode fazer?

Grato pela atenção.

Before any evaluation of a temporal operator between situation facts drools performs a validation which throws this:

java.lang.ClassCastException: org.drools.core.common.DefaultFactHandle cannot be cast to org.drools.core.common.EventFactHandle
	at org.drools.core.rule.VariableRestriction$TemporalVariableContextEntry.updateFromTuple(VariableRestriction.java:634)
	at org.drools.core.common.SingleBetaConstraints.updateFromTuple(SingleBetaConstraints.java:118)
	at org.drools.core.phreak.PhreakJoinNode.doLeftInserts(PhreakJoinNode.java:105)
	at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:76)
	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:519)
	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:505)
	at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:341)
	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:301)
	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:136)
	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:94)
	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73)
	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:970)
	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1312)
	at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1232)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1398)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1377)

A straightforward dialect for situation writing/designing to be transpiled at runtime into drl rules.

The so-famous Fever situation could be described like:

package br.ufes.lprm.scene.examples.fever

situation Fever
  when
    @febrile: Person(temperature > 37)
end

• The situation keyword would refer to a special kind of rule with no need for an explicit consequence (RHS) which would always be internal situation life cycle management code.
• There would be no need for a static SituationType-descendant Java class. The situation declaration provides enough information for building the situation class dynamically. The @<label> construct would represent that the binding variable maps to a class attribute <label> as a situation role.

short-term downfalls:

• situation only file: domain rules and events would be written apart from the situations, although, defined situations could be used by any domain business rule.

Config the publishing of scene-server as a docker image on Docker Hub.

We need a publish/subscribing feature for situations which fill these requirements:

• A subscriber wants to know about any situation of any type;
• A subscriber wants to know about any situation of a certain type;
• A subscriber wants to know about any situation of any type involving an specific actor/participant;
• A subscriber wants to know about any situation of a certain type involving an specific actor/participant;

PUT /subscribe

request

{
  ????
}

In case of success, the subscribing call should respond with a subscriptionId.

response

{
  "subscriptionId": "da39a3ee5e6b4b0"
}

DELETE /subscribe/:subscriptionId

Further, the subscriber could unsubscribe itself by sending a HTTP Delete with the same subscriptionId provided by the subscribe request.

For technical purposes:

• https://www.tomcarroll.net/clustered-publish-subscribe-with-play-akka-and-websockets/

Implement quality control for clinical products scenario