Re: Terminology

[Olaf Kummer <kummer@informatik.uni-hamburg.de>]

Dear Michael, dear all,

> this posting is in order to discuss the terminology of the
> interchange format.

Thanks a lot for sharing. I will comment on some items,
but even there we have little disagreement. I usually suggest
small clarifications.

> Each label is necessarily associated with a Petri net object or with
> the net as a whole. 

This implies that It is not allowed to attach labels (not even
predefined labels) to other labels? Is this intended?

 From the following paragraph I infer that predefined labels are
used to determine the type of net elements. Why not use them to 
indicate the type of label, too?

> We dsitinguish between two kinds of labels.
> The [first] kind are the labels with potentially unbounded values.  They
> depend on the net type or other labels (name, marking).  These
> labels are called open labels. The second kind are the labels which
> define the meaning of their objects (type of an arc (read arc,
> inhibitor), classes of objects as T. Mailund proposed).  These labels
> are called predefined labels.  Predefined labels influence the
> graphical representation of the Petri net objects.

Maybe we should add to this description that the permitted range
of predefined labels depends on the Petri net type and that they
originate from a small finite set of values? (At least this is how 
I understood your proposal.)

> Petri nets may be structured.  We distinguish two kinds of structuring.
> The first kind organizes a Petri net in pages.  Thus, a Petri net may
> consists of pages. A page may be also substructured in pages.

I read this as: "Each net and each page may contain net elements
and pages, possibly both." Is this correct?

> Pages
> are associated with each other via reference places and reference
> transitions.  Such a reference node has a graphical representation and
> is a source or a target for an arc. 

Is it permitted that arcs cross page boundaries? I guess no, but i'd like
a definite statement on that issue.

> But, a reference node has no individual (open) labels. 

In our tool we allowed label on reference nodes. Sometimes we
felt that it was more natural to attach certain initial tokens
to the reference nodes instead of the main nodes, e.g. many
tokens for a database place that originate from different
subsystems.

If we allowed labels for reference nodes, we would be able
to export the locality information. Tools that do not allow labels
on reference node could still move them to the reference node
during import.

Is it too difficult for the other tools to allow 
labels on all nodes? If yes, I will withdraw this 
proposal and we'll go with the original suggestion.
I just wanted to point out that this might be an artifical
restriction.

> Are there more than one label of a certain kind on an object or a net?

It does not seem required to have multiple identical
predefined labels, as far as I understand your proposal.

Regarding multiple open labels: Why not? Two guards seem to have 
a well defined semantics (simply use the conjunction of both).
Same for two initial marking expressions (simply add them together).

For some label types this makes less sense. Place types come 
to mind. My feeling is that this should be specified individually 
for each Petri net type.

Olaf
-- 
Olaf Kummer, Luruper Weg 21, 25469 Halstenbek, Germany
Tel: 04101-473957 / 040-42883-2245    Fax: 040-42883-2246
mailto:kummer@informatik.uni-hamburg.de
http://www.informatik.uni-hamburg.de/TGI/mitarbeiter/wimis/kummer.html