[erlang-questions] Visual Erlang notation v0.1.0 - feedback request

[ok@REDACTED]

I am viewing visual_erlang.pdf in Acrobat Professional
and most of the figures are missing the connecting lines
you'd expect to find in them.

This year I'm teaching part of a 4th year data base paper,
where I'm talking about things like XML data bases and
graph data bases, and part of a 4th year logic paper,
where I'm talking about description logics (particularly
EL and EL+), RDF, and OWL.  In past years I have been
extremely frustrated by graphical tools that I could not
*program*, where I *knew* there was information in the graph
but I couldn't get it out.

So for me one of the essential feature of any "boxes and
connectors" notation is that there has to be a defined
way to map that to some sort of set of facts that I can
write queries on.  That is, it has to be more than pretty
pictures.

Turtle (RDF) is fine; SWI Prolog comes with a decent kit for
loading/exporting/storing/querying RDF.  Datalog is fine too.
It might be OK to make it something that can be visually
manipulated in 'dia', and define a mapping between dia
file format and a semantic form.

Thing is, *IF* this (or any other notation) is any good at
revealing just enough relevant structure, then it ought to
be possible to write "flaw detectors" to spot antipatterns.

It would also be interesting to have the connections between
this notation and other notations like SDL or especially
Maurice Castro's visual notation for Erlang.  (Anyone know
what Maurice is up to these days?)

My understanding is that in the early days of Erlang there
was some pressure to tie it up with SDL, but it was found
that there was a much clearer design notation for Erlang
than SDL.  I believe it was called Erlang...

Of course the present file is just a beginning, but there
is a certain "flavour" that already has me wondering.

When I read other people's Erlang code, I practically
ALWAYS find myself desperately searching for certain
information I regard as really important for my understanding.
"Desperately" because the information is often missing.
And this graphical notation currently has no place for it,
and it's not even clear that a graphical notation is
appropriate.  Yet it is something that Joe Armstrong has
stressed the importance of, and built a toolkit to help in
specifying and checking.

It's the *PROTOCOLS* between the processes.
By examining the source code of a module I can sometimes
recover the protocol *as implemented*, but since people
can make mistakes, that's not always the same thing as
the protocol as *intended*.  In my own code, I tend to
write the protocol down in comments, but *sigh* (hang
head) don't always keep it up to date as the code changes.
And of course the protocol-as-implemented in a receive
loop can be the union of two or more protocols.  (For
example, you might want a "management" protocol from a
master to a worker but "clients" might be allowed to
speak directly to the worker with a different protocol.)
And of course part of a protocol might be implemented in
a 'receive' and part of it in a 'case' somewhere else.

*The* notation for specifying protocols has to be UBF
(or some UBF variant).  How can that be integrated with
a visual notation?