Re: Structuring the discussion points

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

Dear Martin, dear all,

Martin Fabian wrote:
> >What I consider sensible as minimal graphical attributes:
> > - position of the center for transitions and places.
> <snip>
> >Do we want to store offsets or absolute positions?
> >
> Should this be specified at all in the format?
> If relative coordinates are used, then the question is "relative to what?"
> And if the answer is "upper/lower left/right corner" then those coordinates
> are absolute, right?

Maybe I did not express myself clearly.

For places and transitions it seems to me that we should 
save their absolute position. The comment was about textual
annotations which move together with their place or transition
in most PN tools.

Of course we should specify this question in the
standard. Otherwise it would not be possible to
transfer textual annotations correctly from one
tool to another.

> >>         * meaning of different arcs
> >>           (normal, inhibitor, read, ... (which else))
> >  flexible arcs (multiset valued)
> >I know that several formalisms do not need to indicate
> >flexible arcs explicitly.
> >
> "Normal" includes "weighted"?

I think so.
 
> I certainly think that all arcs should be weighted, but optionally and with
> a default weight of one.

I my opinion, weight should be a special label (or however we
decide to call textual annotations).
 
> >>         * labels as pure text
> >>           (the developers are free to substructure the labels,
> >>            but a pure text of a label is required, too)
> >
> We should distinguish between "label" and "name" (where necessary). Each
> pn-element (at least transitions (and places?)) may have both a label _and_
> a name. For instance, for transitions, the label may be related to an
> event, which need not be unique between transitions (several transitions
> may be labeled by the same event). The names must be unique, though. 

It is possible to view names as just another form of
textual inscriptions for the sake of uniformity.
We may desire to make an explicit distinction, although 
I am not sure what we would gain. Alternatives:

<place>
  <name><text>Opodeldok</text><graphics>...</graphics></name>
</place>

or

<place>
  <inscription type="name"><text>Opodeldok</text><graphics>...</graphics></name>
</place>

> This brings up the question of an "alphabet". In our use of pns, each net
> has an alphabet, the elements (the "events") of which label the
> transitions. This is something we find useful and necessary. 

It would be a special kind of annotation.
It can be represented textually, can't it?

> What about time?

Yes, we need that.

> We would need both P-timed and T-timed nets. Also, there's interesting work
> going on at http://www.cs.chalmers.se/Cs/Research/Algorithms/ (see "A
> Decision Support System for Scheduling a Shop Floor Work Center") with
> "arc-timed" nets, where the time is assoicated with (in this case) the
> output-arcs. Simplifies lots of things (though expressitivity is the same,
> of course).

That is the way it is done in Design/CPN and Renew and probably 
many other tools. Not quite as expressive as timed transitions
with earliest and latest firing times, but well understood.

Again, I consider time as a special type of textual annotation.
I would like to start a list, continued from my paper at
http://www.daimi.au.dk/pn2000/Interchange/detailed.html

  net annotation types include:
    comment
    name
    declaration
  place annotation types include:
    comment
    name
    initialmarking
    currentmarking
    capacity
    type
    timed (maybe split! make suggestions!)
  transition annotation types include:
    comment
    name
    guard
    expression
    action
    uplink
    downlink
    timed (maybe split! make suggestions!)
  arc annotation types include:
    comment
    expression
    timed (maybe split! make suggestions!)

Please extend this list. I can only introduce those
annotation types that I use myself, for obvious reasons.

Regards, 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