Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [henshin-user] NestedConditions

Indeed, that would help in this example. For more complicated examples, there may be combinatorical effects when "desugaring" the partial NAC into several standard NACs. It's an interesting question if one could give an algorithm for doing that. Maybe something to tackle under the Christmas tree. :-)

Best regards,
Daniel

On 12/20/2019 11:41 AM, Zschaler, Steffen wrote:

Thanks. But one could express this by adding a second NAC that extends the right B with a D.

 

Steffen

 

Dr. rer. nat. Steffen Zschaler AHEA

 

Senior Lecturer

King's College London

Department of Informatics

 

Visiting Scientist

The Francis Crick Institute

 

Email szschaler@xxxxxxx

Phone +44 (020) 7848 1513

WWW   www.steffen-zschaler.de

 

From: henshin-user-bounces@xxxxxxxxxxx <henshin-user-bounces@xxxxxxxxxxx> On Behalf Of Daniel Strüber
Sent: 20 December 2019 10:38
To: henshin-user@xxxxxxxxxxx
Subject: Re: [henshin-user] NestedConditions

 

In the context of the alternative semantics (which, as we figured out in the other sub-thread, currently isn't implemented), I think it still would make a difference. I put a slightly modified version of the example below. The only difference is the inclusion of an additional "forbid" element, which is connected to the existing "forbid" element via an edge.

  [forbid :D] --> [forbid :B] ---> [preserve :A]  <---- [preserve :B] <----- [create :C]

The "border-elements only" NAC looks like this:

    D -> B -> A       (where A has a mapping from the LHS)

The "replicate full LHS" NAC looks like this:

   D -> B -> A <- B    (where A, the right-hand B, and their common edge have mappings from the LHS)

An example model where a rule including either of these NACs would match:

    b:B -> a:A

An example model where a rule including the second NAC, but not the first NAC would match:

    d:D -> b:B -> a:A

Best regards,
Daniel

 

On 12/20/2019 11:21 AM, Zschaler, Steffen wrote:

Sure, but then it wouldn’t make a difference whether we use a complete or incomplete morphism, would it?

 

Many thanks,

 

Steffen

 

Dr. rer. nat. Steffen Zschaler AHEA

 

Senior Lecturer

King's College London

Department of Informatics

 

Visiting Scientist

The Francis Crick Institute

 

Email szschaler@xxxxxxx

Phone +44 (020) 7848 1513

WWW   www.steffen-zschaler.de

 

From: henshin-user-bounces@xxxxxxxxxxx <henshin-user-bounces@xxxxxxxxxxx> On Behalf Of Daniel Strüber
Sent: 20 December 2019 09:32
To: henshin-user@xxxxxxxxxxx
Subject: Re: [henshin-user] NestedConditions

 

Yes, in this example, the rule would be inapplicable. To slightly modify the example to get two applicable rules, we may include some additional "forbid" elements (without a counterpart in the LHS) into the original rule.

Best regards,
Daniel

On 12/19/2019 3:06 PM, Zschaler, Steffen wrote:

Just to make sure I understand this correctly:

  • When only the border elements are replicated in the NAC (here: the :A node), the NAC looks like this:
  •     B -> A       (where A has a mapping from the LHS)
  •  

 

Wouldn’t that mean the rule can simply never be matched (because there would, by definition always be a B to be matched for the NAC)?

 

Steffen

 

Dr. rer. nat. Steffen Zschaler AHEA

 

Senior Lecturer

King's College London

Department of Informatics

 

Visiting Scientist

The Francis Crick Institute

 

Email szschaler@xxxxxxx

Phone +44 (020) 7848 1513

WWW   www.steffen-zschaler.de

 

From: henshin-user-bounces@xxxxxxxxxxx <henshin-user-bounces@xxxxxxxxxxx> On Behalf Of Daniel Strüber
Sent: 19 December 2019 13:26
To: henshin-user@xxxxxxxxxxx
Subject: Re: [henshin-user] NestedConditions

 

Consider a rule (using the integrated syntax:)

    [forbid :B] ---> [preserve :A]  <---- [preserve :B] <----- [create :C]

When only the border elements are replicated in the NAC (here: the :A node), the NAC looks like this:

    B -> A       (where A has a mapping from the LHS)

When the full LHS is replicated, the NAC looks like this:

   B -> A <- B    (where A, the right-hand B, and their common edge have mappings from the LHS)

Using the first NAC, the forbid node can be matched to all :B objects from the input model, including one which was bound to the preserve :B node while matching the LHS.

Using the second NAC, the forbid node cannot be matched to a :B object which was already bound by LHS :B node.

Best regards,
Daniel

 

 

On 12/19/2019 2:15 PM, Zschaler, Steffen wrote:

Thanks, Daniel. You seem to imply that there is a semantic difference between the three forms. Could you explain?

 

Thanks,

 

Steffen

 

Dr. rer. nat. Steffen Zschaler AHEA

 

Senior Lecturer

King's College London

Department of Informatics

 

Visiting Scientist

The Francis Crick Institute

 

Email szschaler@xxxxxxx

Phone +44 (020) 7848 1513

WWW   www.steffen-zschaler.de

 

From: henshin-user-bounces@xxxxxxxxxxx <henshin-user-bounces@xxxxxxxxxxx> On Behalf Of Daniel Strüber
Sent: 19 December 2019 13:13
To: henshin-user@xxxxxxxxxxx
Subject: Re: [henshin-user] NestedConditions

 

Hi Steffen,

Henshin allows the morphism between the host graph and the application condition graph to be a partial morphism. Consequently, all three cases you mention (only nodes replicated, only border nodes replicated, full LHS replicated) would specify different application conditions for the same rule.

 

While this design decision has its awkward sides (especially the representation in the graphical editor), I encountered some situations before where it was desirable, as it allowed to precisely specify an intended behavior.

 

I'm actually surprised by the fact that the graphical editor defaults to the "node only" case -- I would have expected "full LHS replicated" as the default. However, in most cases, the resulting behavior will be identical. The only exceptions seem to arise in the (exceptionally rare) case where there are multiple references of the same type between the same two objects.

 

 

Best regards,

Daniel

 

On 12/19/2019 11:32 AM, Zschaler, Steffen wrote:

Hi,

 

A rather technical question about NestedConditions and their representation in a .henshin file. Do tell me to take this somewhere else if that would be more appropriate.

 

I understand the theory behind application conditions: the condition is a graph and a morphism into this graph from a host graph. That is represented in Henshin by the ability to add a “formula” to a graph, where this formula can be a NestedCondition, which itself again contains a graph and a set of mapping. The containing graph is the host graph, the graph in the NestedCondition is the application-condition graph, and the mappings capture the morphism. So far so clear.

 

Except that’s not how it seems to work in practice: if you look at the attached file, produced by the standard graphical editor, you will see that only the nodes from the host graph have been replicated in the application-condition, but the edges haven’t. In other examples, I have seen cases where only the border nodes had been replicated. In any case, the mappings clearly aren’t a morphism as they do not fully cover the host graph.

 

Are all of these formats indeed acceptable? If so, is there a regularised format that is used inside Henshin and, if so, can this be reused outside of Henshin? Alternatively, are there minimum expectations on how an application condition should be encoded in a .henshin file? Is any of this documented anywhere? Should it be?

 

Thanks,

 

Steffen

 

Dr. rer. nat. Steffen Zschaler AHEA

 

Senior Lecturer

King's College London

Department of Informatics

 

Visiting Scientist

The Francis Crick Institute

 

Email szschaler@xxxxxxx

Phone +44 (020) 7848 1513

WWW   www.steffen-zschaler.de

 






_______________________________________________
henshin-user mailing list
henshin-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/henshin-user
-- 
Dr. Daniel Strüber 
Postdoctoral Researcher
 
Department of Computer Science and Engineering
Chalmers | University of Gothenburg, Sweden
http://danielstrueber.de/





_______________________________________________
henshin-user mailing list
henshin-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/henshin-user
-- 
Dr. Daniel Strüber 
Postdoctoral Researcher
 
Department of Computer Science and Engineering
Chalmers | University of Gothenburg, Sweden
http://danielstrueber.de/




_______________________________________________
henshin-user mailing list
henshin-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/henshin-user
-- 
Dr. Daniel Strüber 
Postdoctoral Researcher
 
Department of Computer Science and Engineering
Chalmers | University of Gothenburg, Sweden
http://danielstrueber.de/



_______________________________________________
henshin-user mailing list
henshin-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/henshin-user
-- 
Dr. Daniel Strüber 
Postdoctoral Researcher
 
Department of Computer Science and Engineering
Chalmers | University of Gothenburg, Sweden
http://danielstrueber.de/

_______________________________________________
henshin-user mailing list
henshin-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/henshin-user
-- 
Dr. Daniel Strüber 
Postdoctoral Researcher

Department of Computer Science and Engineering
Chalmers | University of Gothenburg, Sweden
http://danielstrueber.de/

Back to the top