[Motivating scenario] Safety rules in a manufacturing environment : represent a norm, a context, prohibition, obligation and permission

[DrLeturc]

Objectives of the motivating scenario

The link toward this motivating scenario is here. The aims of this motivating scenario is :

• to introduce the concept of norms in a Hypermedia Multi-Agent System ;
• prohibition, obligation and permission concepts.

Questions / Comments

What do you think of this motivating scenario and the way I tried to instantiate what we discussed during the plenary ?

I think it is always important to discuss about the motivating scenario before doing any pull request and use this template.

[smnmyr]

Hi @DrLeturc , thank you! I have only superficial comments since I'm not a normative MAS expert :-)

• I think the scenario is good. I think that the situation of emergency exit doors should however be modeled differently, i.e. that Emergency Doors are Doors but that they are more explicitly exempt from the obligation in the scenario text and the ABox.

• I do not understand why Q2 and Q3 are not expressible in SPARQL. I assume that the current state of the environment is measured through sensors/property affordances and represented in RDF. Then the SPARQL query should be (a bit complex since they go through the Bags but still) straightforward.

• Is it correct that the containers correspond to ,lrml:Obligation, lrml:Permission, and lrml:Prohibition?

[DrLeturc]

Thanks for your comments.

• I agree with your remark. In the first version of the ABox modeling I had considered a blanknode ?agent, a :leavesThrough predicate and another blanknode ?exit-door. I just rechanged my post.
• Can you give me the SPARQL request without enumerating explictly all the items in the request ? (I must admit that I'm not familiar with SPIN/SPARQL, but it seems not so obvious. According to Fabien, Corese could provide tools that we need)
• Interesting, but we choosed to model DeonticSpecifications with properties not with classes and to represent logical formulas with rdfs:container. Which is currently incompatible with their choices I think ?

[smnmyr]

• I meant the first one differently. The human-readable specification should be more explicit, i.e. "In the i3S workspace, if there is a fire, then all doors that are not emergency exits must be closed, and it is forbidden for people to take the elevators and it is allowed for people to take the emergency exits.

• I'm sorry myself, but am lacking the time to create the SPARQL atm. For Q2, casually writing, I don't understand why it is not possible to go from a :norm via :normativeRequirement to the Bag/Alt/Seq of contextual requirements and then to filter only for norms where all of them/one of them is satisfied.

• Sure, but just to establish the link can we not (again casually) do this [ a rdf:Bag ; rdf:li [ a sp:Ask ; sp:where ([ sp:subject ?door ; sp:predicate :isStatedAs ; sp:object :closed ] ) ] ; rdf:li [ a sp:Ask ; sp:where ([ sp:subject ?door ; sp:predicate :a ; sp:object :Door ] ) ] . ] a lrml:Obligation

[DrLeturc]

• Yes ! I changed it ! Thanks.

• Okay, I think the main problem in the SPARQL request is to adapt the request depending on the normative context.

• Could we redefine the range of hmas:obliges as the intersection between a rdfs:Container and lrml:Obligation ? I don't see counter argument.

[FabienGandon]

Hello, The problem with Q2 and Q3 is that you need to chain two queries with, in between, a transformation that is no available by default in SPARQL:

• run a first query to get the normative requirement attached to a norm
• run a transformation to go from the SPIN syntax used here to a new SPARQL query corresponding to that requirement
• run the second query to check if the requirement is match by the state of affairs

This cannot be written in standard SPARQL as far as I know.

PS: an equivalent problem occurs if you use a literal from of SPARQL instead of the SPIN syntax.

[smnmyr]

I understand, thank you Fabien! Is this conceptual? I would expect that there should not be a fundamental obstacle to automating this (e.g., with a future form of SPARQL).

[gnardin]

Hi @DrLeturc

• The scenario is simple and covers all three deontic concepts
• I propose to add the sanction concept in the Glossary, where sanction is a negative or positive reaction to any violation or compliance with an expectation. The sanction would represent the Thomas actions to ensure the compliance with the norms.
• I do not think the questions we want to answer are "How to", but "What are". Maybe q1. What are the set of norms in the workspace ? q2. What are the set of active norms in the workspace ? (I suggest avoid using the term context otherwise we may need to define it; in my view, we do not apply a norm, but we check its compliance or violation. We may react to a compliance or violation by applying/performing some actions) q3. What are the norms that have not been respected ? (You do not define the time range to which the norms will be checked)
• I would suggest to avoid bounding the norm definition with one specific representation deontic. I suggest a more general definition, such as Norms represent the standards of correct behavior that one expects from others.
• It is not clear what Normative Requirement means

[DrLeturc]

Thanks Fabien to have clarified my answer.

@gnardin :

* I propose to add the `sanction` concept in the Glossary, where `sanction is a negative or positive reaction to any violation or compliance with an expectation.` The sanction would represent the Thomas actions to ensure the compliance with the norms.

Thanks Gustavo for this comment. I worked on another motivating scenario that introduces Sanction but I closed the issues that presented this cause we had to discuss before on basics things. The aim of this motivating scenario was simply to introduce basic deontic concepts eg norms, obligation, permission, etc.

* I do not think the questions we want to answer are "How to", but "What are". Maybe
  q1. `What are the set of norms in the workspace ?`
  q2. `What are the set of active norms in the workspace ?` (I suggest avoid using the term `context` otherwise we may need to define it; in my view, we do not apply a norm, but we check its compliance or violation. We may react to a compliance or violation by applying/performing some actions)
  q3. `What are the norms that have not been respected ?` (You do not define the time range to which the norms will be checked)

I changed it. :) thanks

* I would suggest to avoid bounding the norm definition with one specific representation `deontic`. I suggest a more general definition, such as `Norms represent the standards of correct behavior that one expects from others`.

I agree with you.

* It is not clear what `Normative Requirement` means

I kept it from standard vocabulary. I meant the "hypotheses" that has to be verified to apply a norm e.g. "a fire in a building" to apply the rule "close all the doors".

[oboissier]

Sorry to be maybe not answering at the proper level, but I have questions about the scenarios and about what you call a norm. In the MAS community, norms are targeting agent, group of agents w.r.t. actions or states to be achieved with some activation conditions, deactivation conditions. In what you propose, I don't see the targeted agent, e.g. in the statement "in case of fire, doors must be closed". In that statement who is the agent in charge of it? what if the doors don't close? who will be sanctioned?

[oboissier]

Other comment about the way norms are expressed: are they expressed w.r.t. entities of the systems or in relation to roles (i.e. abstract entities that may be played by real entities of the system)?

[DrLeturc]

Thanks Olivier for your comments.

Sanction is represented in another scenario I wrote but didn't publish yet in the github issue. However you wrote that the motivating scenario doesn't express the agent or institution in charge of monitoring that the norms are respected and who will be sanctioned. Two possibilities: either make the scenario more complex (not very advisable since we need to keep the motivating scenario as simple as possible, and limit the number of terms introduced by a scenario) or consider a future scenario in which we extend the vocabulary with what you say.

===== Nothing related to what you said ==== According to Olivier Corby, using rdf:Container is deprecated to represent logical operators since we can imagine using other operators than and and or... I imagine necessity, possibility, believe, bring-it-about... all my favorite modal operators.

It would be better and more elegant to write either with SHACL or in the following way : xxx hmas:hasNormativeRequirements [ a s:or [a s:not (...)]] and maybe represent propositional atoms either using [a rdf:statement ... ] or SPIN..

===================================

[andreiciortea]

@DrLeturc great concise scenario, thanks for this work. Three interrelated points:

Point 1: On @oboissier's question, I think this is a point we need to reconcile. Could we consider the agent responsible for closing the doors is expressed implicitly in this scenario — and if so, could we make the agent explicit? E.g.:

• if employees/people are responsible for closing the door, we could just say "if there is a fire, employees/people must close all doors"

• if an automated system is responsible, we could just say: "if there is a fire, the building automation system must close all doors".

  Why this is important: if there is no agent responsible for closing the doors, then I question if it is necessary to represent that norm at all — or if it is out of scope. This leads me to the next point.

Point 2 (follows from Point 1): In my understanding, one of the primary objectives for representing norms explicitly is to allow agents to determine what norms apply to them (in a given context). This means we need to represent either explicitly or implicitly who is the target of the norm. To keep this in check, I would propose an additional competency question along the lines:

Q4: What norms apply to me (w.r.t to a context)?

Point 3: The 3rd point is about the granularity of norm definitions. Really great and concise scenario description, but I am wondering if we need to represent everything that goes into that paragraph as one norm. From a KR standpoint this makes sense, but from an Engineering MAS (EMAS) standpoint this is less intuitive: it means we have one general norm that prescribes and proscribes all behavior — and we instantiate that norm for all agents in the scenario. We can do this, but seems messy because there might be many stakeholders involved in defining this one norm and who might then want to change the norm over time (here I'm making a software engineering argument, cf. Single Responsibility Principle).

If we represent explicitly who is the target of a norm — e.g. a role in some organization — then this yields a natural way of defining more fine-grained norms. In this scenario, e.g.:

• we could have one norm that prohibits people to take the elevator
• we could have one norm that obliges a building automation system to close all doors
• etc.

@DrLeturc thanks again for this work, really great starting point!

[DrLeturc]

Thanks Andrei for your feedback ! I agree with you on everything you said.

CQ could be now :

ID	Question in natural language
q1	What are the set of norms ?
q2	Who is the authority in charge of applying a norm ?
q3	What is the scope of application of a norm ?
q4	What are the set of norms that are applicable w.r.t. a context ?
q5	What are the norms that have not been respected ?
q6	What norms apply to me (w.r.t. to a context) ?

I added :

• Authority: The authority who has the power and which is in charge of applying the norm..

Concerning the responsibilities, can we say that it is the authority in charge of applying who is responsible of it (i.e. who has the power on)? Thus, considering something like :

:Authority rdf:type owl:Class ;
           rdfs:comment "The authority who has a power to apply a norm and which is in charge of applying the norm. It may be an :Agent, an :Institution or an :Organization. "@en ;
           rdfs:label "Authority"@en .

:hasPowerOn rdf:type owl:ObjectProperty ;
        rdfs:domain :Norm ;
                rdfs:range :Authority;
                rdfs:comment "It defines who is the authority in charge of applying the norm. "@en ;
                rdfs:label "has normative requirement"@en .

Concerning the scope of the application of the norm, it can be explicitly expressed in the ABox e.g. "by saying that all doors are those of the i3s (workspace)" :

:allTheDoorShouldBeClosedRule hmas:obliges 
[ a rdf:Bag ;
  rdf:li [ a sp:Ask ; sp:where ([ sp:subject ?door ; sp:predicate :isStatedAs ; sp:object :closed ] ) ]  ;
  rdf:li [ a sp:Ask ; sp:where ([ sp:subject ?door ; sp:predicate :a ; sp:object :Door ] ) ] ;
  rdf:li [ a sp:Ask ; sp:where ([ sp:subject :i3s ; sp:predicate :contains ; sp:object ?door ] ) ] .
] .

The same works also for :

• if employees/people are responsible for closing the door, we could just say "if there is a fire, employees/people must close all doors"
• if an automated system is responsible, we could just say: "if there is a fire, the building automation system must close all doors".

Thus, I don't think we need to integrate a property that defines the scope of application of a norm into the ontology explicitly. (maybe I'm wrong)

I didn't see "The single-responsibility principle (SRP) is a computer programming principle that states that "A module should be responsible to one, and only one, actor. [1] The term actor refers to a group (consisting of one or more stakeholders or users) that requires a change in the module."

It should be expressed by a constraint on the range of :hasPowerOn ?

[andreiciortea]

Thanks @DrLeturc for the updates, some quick thoughts:

q3 What is the scope of application of a norm ? q6 What norms apply to me (w.r.t. to a context) ?

Just to check my understanding: in Q3, by scope you mean who is subject to the norm (i.e., what agents), right? And then Q6 would be for a specific agent — maybe we could rephrase it as:

Q6: What norms apply to a given agent w.r.t. a context?

• Authority: The authority who has the power and which is in charge of applying the norm..

Sounds good to me, so the authority would be who defined the norm and is potentially enforcing the norm (cc @gnardin and @oboissier)

Concerning the responsibilities, can we say that it is the authority in charge of applying who is responsible of it (i.e. who has the power on)? Thus, considering something like :

Not sure I understand this statement. Just to clarify, in my understanding, I would see multiple responsibilities here:

• an entity (agent, organization, etc.) responsible for defining the norm; the same entity could also be responsible for enforcing the norm, but enforcement could also be ensured by a different entity (e.g., legislative body vs. police)
• one or more entities (only agents?) responsible for fulfilling the norm; these entities are subjected to the norm and are required to comply with the norm

I didn't see "The single-responsibility principle (SRP) is a computer programming principle that states that "A module should be responsible to one, and only one, actor. [1] The term actor refers to a group (consisting of one or more stakeholders or users) that requires a change in the module."

It should be expressed by a constraint on the range of :hasPowerOn ?

Here I did not mean we should apply the SRP in our formalization, I was merely using the SRP as an argument for why it could be better to have more fine-grained norms rather than one big norm that covers the whole scenario.

[gnardin]

Hi @DrLeturc,

Below I do not comment on specific items, but I describe my perspective on the scenario based on how we are working at MSE to specify the regulation concepts.

In the proposed scenario, norms are defined in the scope of Workspaces (e.g., i3S workspace). We at MSE are thinking on norms defined in the scope of Organizations. These two different perspectives may cause misunderstandings.

An Organization Entity (henceforth Organization) exists to satisfy some organizational goals. These goals achievement depend on the execution of a set of activities that can be accomplished by Agents playing certain roles in the Organization. Agents that adopt a role may be obliged, allowed, or forbidden to performing certain actions. In this organizational context perspective, norms are used to associate roles and activities, thus specifying the expected behavior of the Agents when they adopt a role and commit to performing an activity.

NOTE: We are working on integrating the notion of Space to allow including this aspect also in the specification of norms (preliminary stages).

Back to the scenario, the norms are defined in the scope of the i3S Workspace, which raises the question: Whom defines the norms?

If we think the scenario from an Organization perspective, the people would be playing two roles: a (normal) role to support the i3S Organization achieving its goals and an (emergency) role to leave the building in an emergency situation. The norms (i.e., regulative norms) of how the Agents should behave in both situations are specified in the context of the Organization.

• In a normal situation, the norms specify how the Agents should behave to achieve the organizational goals

• In an emergency situation (e.g., fire), the norms specify the Agents should stop everything they are doing and leave the building through the emergency exits and not using the elevator. In line with @andreiciortea 's comments w.r.t. to norms, we can define three norms in the emergency situation

  • People must leave the building (Obligation)
  • People are allowed to use the emergency exits (Permission)
  • People must not use the elevator (Prohibition)

Associated to an Organization, there is a Regulation System (probably similar to what you propose as Authority) that is responsible for enforcing the norms. The enforcement requires the monitoring, the evaluation, and the sanctioning of Agents w.r.t. the compliance to the regulative norms. The Regulation System activities should be associated to roles (i.e., monitoring - Detector role, evaluating - Evaluation role, and the sanctioning - Executor role) that are played by one or more Agents. The Regulation System can itself be a separate Organization.

In the scenario, Thomas plays the three roles: (i) Detector role since he monitors people's behaviors, (ii) Evaluator role since he evaluates whether their behavior were compliant or not to the norms, and (iii) Executor role since he acts to avoid further violations.

NOTE: I assume that the closing of the doors are not subject to any norms since it is an automatic process. I focused only in the people behavior.

This text shares my perspective on the scenario and how it can be integrated to the concepts we are defining at MSE for the Regulation ontology.

[DrLeturc]

@gnardin : very interesting point concerning the Organization part ! You answered to some of my questions related to Organization and the range of the scope of a norm.

Should I add it to this current motivating scenario or we let it in yours ? I can make a proposition of TBox modelling for your motivating scenario. Concerning your second point :

"In a normal situation, the norms specify how the Agents should behave to achieve the organizational goals

In an emergency situation (e.g., fire), the norms specify the Agents should stop everything they are doing and leave the building through the emergency exits and not using the elevator. In line with @andreiciortea 's comments w.r.t. to norms, we can define three norms in the emergency situation ...

People must leave the building (Obligation)
People are allowed to use the emergency exits (Permission)
People must not use the elevator (Prohibition)

"

Actually as it has been proposed in the current modelling, we can model it with the actual T/ABOX.

But a raised question is when we should split a norm into different sub-norms ?

Concerning the term "Authority", it would be like a specifical role into an Organization entity ?

" (i) Detector role since he monitors people's behaviors, (ii) Evaluator role since he evaluates whether their behavior were compliant or not to the norms, and (iii) Executor role since he acts to avoid further violations."

Interesting points, I think we should clarify these points in another motivating scenario that would extend this current motivating scenario ? Or should we put it in this one ? But I fear we would introduce too many new terms.

[gnardin]

@DrLeturc My previous (long) comment was to align our understanding of how we are viewing the Regulation aspects rather than to change your motivating scenario.

Should I add it to this current motivating scenario or we let it in yours ? I think you do not need to add all the details in your motivating scenario, but you could contextualize it in relation to an Organization. For example, you could replace "i3S Workspace" by "i3S Organization Entity", which will link the Organization Entity concept with the Norms concept even if you do not define the Organization Entity in your motivating scenario. Basically, you will be reusing the concept defined in one of the motivating scenarios we describe introducing the Organization Entity term.

Actually as it has been proposed in the current modelling, we can model it with the actual T/ABOX. You can model it in T/ABox, but don't you need to have it in the scenario description in order to elaborate the Competency Questions that will lead to the T/ABox?

Concerning the term "Authority", it would be like a specifical role into an Organization entity ? Yes, I think so.

Interesting points, I think we should clarify these points in another motivating scenario that would extend this current motivating scenario ? Or should we put it in this one ? But I fear we would introduce too many new terms. As I mentioned earlier, I do not think all these aspects need to be included in a single motivating scenario since it would create long and complicated scenarios. My comment was just to provide an whole overview of how we see norms integrating with the other concepts we are working on.

However, I think that the scenarios should be contextualized to allow the reader to understand how the introduced concepts relates to the other existing concepts.

I may be completely wrong. This is just my current view when trying to apply the methodology we discussed during the Plenary Meeting.