We demonstrate two visual notations whose specifications were created with GenEd. The first notation describes place-transition petri nets. The second notation defines entity-relationship (ER) diagrams.
= 0em
A petri net
is a triple 
with 
a set of places,
a set 
of transitions, and a relation 
representing edges.
A tuple 
defines a place-transition net
if the
following conditions hold. The tuple 
is a petri net with
places 
and transitions 
. 
defines a capacity for each place.
specifies the weight of every edge.
, defines the initial marking.
The complete specification of place-transition nets is out of scope of this paper. We already proved in [1] with Pictorial Janus that our approach can handle complex visual notations. We only outline the design of the specification for place-transition nets. We define concepts representing legal constellations for places, transitions, and edges. A petri net is specified as a composite object consisting of at least 5 parts. Primitive concepts are typeset in a slanted style.
pleqgroup* plformula*
petri_net
(& composite_thing
&
(5 has_parts)
(1 has_parts place)
&
( (has_parts\! rectangle)
transition)
&
( (has_parts\! arrow) edge)
) endplformula* endpleqgroup*
Petri nets are specialized to place-transitions nets after defining capacity labels, places with capacity, token, places with tokens, edges with capacity, and active transitions.
pleqgroup* plformula*
place_transition_net
(&
petri_net
(1 has_parts place_with_token)
) endplformula* endpleqgroup*
An interesting special case of place-transition nets is a predicate-event net. All places and edges have a maximal capacity of 1.
= 0em
pleqgroup* plformula*
predicate_event_net
(&
place_transition_net
&
( (has_parts\! place) predicate_event_place)
&
( (has_parts\! arrow) predicate_event_edge)
) endplformula* endpleqgroup*
The definition of predicate-event places and transitions are omitted. There are still other interesting concepts characterizing special petri net elements that are left out due to lack of space. However, the next section discusses entity-relationship diagrams which are specified in almost full detail.
Figure 7: An ER diagram modelling airlines
Figure 8: A simple entity-relationship diagram
Our definition of a subset of entity-relationship (ER) diagrams was inspired by [11]. We present this example in order to demonstrate the expressiveness of our specification language and the reasoning capabilities of GenEd. Due to space constraints we show only a screen shot of GenEd (see Figure 7) displaying a subpart of a larger example modelling relationships in an airline company. Figure 8 shows a simple ER diagram specifying a relationship between a pilot and an aircraft. The design and evaluation of the specification for this simplified type of ER diagrams took about half an hour for an experienced user of GenEd. We assume a few primitive concepts and spatial relations representing geometrical objects (rectangle, circle, diamond, line, text) used in our ER diagram language.
mm]r-e.ps,scale=1.0
A relationship-entity
connection is a line that touches
exactly one text label (expressing cardinality) and two other
regions (rectangle or diamond). A cardinality
is a text
string with values chosen from the set 
.
pleqgroup* plformula*
relationship_entity
(& line
(3 touching)
(1 touching text)
&
(2 touching (rectangle diamond))
&
(1 touching rectangle)
(1 touching diamond)
) endplformula*
plformula*
cardinality
(& text
( touching relationship_entity)
&
(1 touching)
( text_value {1,m,n})
) endplformula* endpleqgroup*
An attribute-entity connection is a line that touches only two regions (circle or rectangle) and no text string.
mm]a-e.ps,scale=1.0
pleqgroup* plformula*
attribute_entity
(& line
(2 touching)
&
( touching (circle rectangle))
&
(1 touching rectangle)
(1 touching circle)
) endplformula* endpleqgroup*
mm]entity.ps,scale=1.0
An entity is a rectangle that contains its name. It touches at least one relationship-entity and optionally some attribute-entity connectors. It is linked with at least one diamond.
pleqgroup* plformula*
named_region
(& region
(1 containing)
( containing text)
) endplformula*
plformula*
entity
(& rectangle named_region
&
(1 touching relationship_entity)
&
( touching (attribute_entity relationship_entity))
&
(1 linked_with diamond)
&
( linked_with (circle diamond))
) endplformula* endpleqgroup*
A relationship is a diamond that contains its name. It touches one relationship-entity and optionally some attribute-entity connectors. It is linked with two entities.
mm]relationship.ps,scale=1.0
pleqgroup* plformula*
relationship
(& diamond
named_region
&
(2 linked_with)
( linked_with entity)
&
(2 touching)
( touching relationship_entity)
&
(2 touching ((touchingrftext_value)
1)
)
&
(1 touching ((touchingrftext_value)
m)
)
&
(1 touching ((touchingrftext_value) n) )
) endplformula* endpleqgroup*
An attribute is a circle that contains its name. It touches one attribute-entity connector and is linked with an entity.
mm]attribute.ps,scale=1.0
pleqgroup* plformula*
attribute
(& circle named_region
&
(1 linked_with) ( linked_with entity)
) endplformula* endpleqgroup*
The last example suggests that our approach might also be usable in the domain of geographic information systems (GIS). This example demonstrates the advantages of a forward-chaining parser and the necessity for non-monotonic reasoning. In the context of an aerial image interpretation system we assume that there exists a two-dimensional model of a geographic scene stored in a GIS. In this system multi-spectral images are interpreted, for example, in order to detect changes in the scene. To speak of an interpretation of an image, e.g. a change has to be described not only at the geometrical level but also at the conceptual level. We use GenEd to create a model of an example world. This small example consists of two primitive objects (water surface and house) that can be easily detected in aerial images by using spectral analysis. We assume a symmetric relation `near' that may hold for objects if they are located next to each other.
Figure 9: Sketches of the villa example.
A swimming pool is a water surface with at least one house in its neighborhood (relation `near'). A villa is a house with at least one swimming pool in its neighborhood. The left part of Figure 9 sketches an image of a scene with several houses along a street. In this scene no villa has been recognized since there exists no water surface next to a house. It is important to note that each house could still incrementally be classified as villa provided a water surface is found in the neighborhood. This is visualized in the right part of Figure 9. This particular house is now classified as villa and the water surface as swimming pool. This reclassification is triggered by the newly added water surface and affects only houses in the neighborhood of this water surface. It is automatically performed by the forward-chaining parser and always results in the most-specialized classification (that is what we are interested in). A backward-chaining parser would be inadequate if we imagine a scene with a large amount of houses and only a small number of water surfaces since we usually do not know in advance where a water surface might be detected. Thus, it is also not acceptable to query the state of all houses. This scenario illustrates that GenEd might also be a suitable query interface for a GIS.