SUO: RE: The Plumbing Theorem(s)
Dear John,
>
> To answer the questions about dyads and triads as simply as
> possible, I would like to explain the issues in terms that
> anyone can verify just by going down to the basement and
> examining the plumbing.
>
> Let us suppose that you had the following resources:
>
> 1. Long lengths of water pipe and the option of ordering
> more whenever you need it.
>
> 2. The ability to cut the pipe to any desired length and to
> finish the ends with whatever threading is needed to link
> it with suitable connectors.
>
> 3. A large supply of dyadic connectors: sleeves, which let
> you link two pipes in a straight line; and elbows, which
> let you link two pipes at an angle (usually a right angle,
> but other angles may be permitted).
>
> With those resources, you can direct water from the point of
> entry into your house to at most one faucet elsewhere in the
> house. You cannot direct the water to any additional faucets,
> bathtubs, showers, or toilets.
>
> But if you were given some triadic connectors (T shape or
> Y shape), you could connect one additional faucet or other
> facility for each triadic connector you use.
>
> Connectors with more than 3 links would be unnecessary.
> A tetrad (+ shape) could be used instead of two triads.
> But if you had enough triads, dyads, and straight pipe,
> you wouldn't need any tetrads, pentads, hexads, etc.
>
> All these facts can be verified by looking at the plumbing,
> playing with pipes, or drawing diagrams until you are satisfied
> that they are true.
>
> John Sowa
>
It is very interesting that you should pick a plumbing example.
As I have mentioned once or twice, I am a Chemical Engineer
by original training and practice, and a lot of what we do
could be described as "plumbing", though the scale is slightly
different. Our pipes might be up to a metre in diameter, and
when we have heaters fired by gas or other fuel they are the size
of a house. However, scale and quantity of "plumbing" doesn't
change the principle.
You will then not be surprised that precisely this issue is one
we have paid considerable attention to.
Perhaps I can use this to illustrate some of the different ways
you can represent this situation. But first let me make a few
observations on John's representation of a piping network.
In John's example above he treats a T piece as a relation. In
EPISTLE we tend to see a T piece as a physical object with
three connection points (connecotrs), especially since T pieces
are things we have to buy and that have a weight. One of the things
we particularly try to do in EPISTLE is to model the same sort of
things in the same way. In this case we treat all physical objects as
independent objects (i.e. not relations). Think about this from a
practical point of view for a moment. If a T piece were really a
relation you would never be able to buy one. When you go to the shop
you buy a T piece that is not connected to anything, yet when you model
it as a relation, you require that it is connected to 3 things, or you
cannot admit its existance.
Anyway, on to expose our own treatment of how things are connnected.
Most pipes are use to connect two things. In fact, we do not
initially care much about the pipe (or pipe network) at all, only
that the connections are made. So for example, when we start to
design a refinery, we will say that we want a Crude Distillation
Unit, and a Platformer (which turns low octane naphtha from the
CDU into a high octane component of gasoline). So what I want
is a connection between the CDU and the Platformer. So we want to
say:
Connected <CDU, Platformer>
In this case, the relation might be seen as representing the pipe
(or a route through a piping network) that forms the connnection
(note: above in John's example, it is the pipes that are being
connected).
When you look at things at the next level of detail, we found we
were essentially modelling the piping components (physical objects)
and the way they are connected. In our case often with flanges,
o-rings, and nuts and bolts.
So we would have a T piece with 3 connections to pieces of pipe.
So simplisticly this might look like:
Connected <T, P1>
Connected <T, P2>
Connected <T, P3>
Well, there is a slight issue here, in that I cannot distinguish
which pipe is on which connector, and whilst this doesn't matter much
from a logical viewpoint, from a fluid flow viewpoint, it does make
a difference whether you are flowing across the top of the T, or going
round the corner. On the other hand a T piece is really just a degenerate
form of a vessel with some arbitrary number of connectors. Certainly
on vessels it matters if the connector is at the top, side or the bottom.
So now we need to label the connectors say:
1 --- 2
|
3
Now I can say:
#1 Connected <C1, P1>
#2 Connected <C2, P2>
#3 Connected <C3, P3>
But now I also need to say that these connectors are part of the T piece
or I do not know specifically that the T-piece has anything to do with it.
So I get:
#4 Part-of <C1, T>
#5 Part-of <C2, T>
#6 Part-of <C3, T>
This still leaves us with the nuts, the bolts, and the "o" ring.
Often we are not interested in these, but sometimes we might be,
so we give ourselves the opportunity. We describe these as being
"used in" the connection. This means that our relation itself has
to participate in a relation. We get:
#7 used-in-connection <materials1, #1>
#8 used-in-connection <materials2, #2>
#9 used-in-connection <materials3, #3>
I'm not sure how you handle this sort of thing. We treat all relations
as referenceable objects.
Finally, or course we have to have the break down of materials1 etc. into
their component parts, but I think I will leave that now as an exercise for
the reader.
Just to tidy up one point from the beginning. Initially we started with
wanting to connect a CDU and a Platformer. This approach of
"used-in-connection" means that I can hold information at different levels,
by indicating the pipe as being the thing that is used in the connection
between the CDU and Platformer.
I might add that all the above is still a simplification, since it is really
states of all the objects referenced in the above example that are involved
in all the relations (which are then timeless) so that changes can be
recorded as well as some snapshot. But that can wait for another time.
I would like to finish by drawing out 2 points.
1. There is more than one possible way to represent objects using
constants and relations as your representation constructs.
2. You should make your choice carefully, and use it consistently
or you will store up all sorts of problems for later.
3. And oh yes, I didn't need triadic relations to construct a piping
network of arbitrary complexity. I just needed to make a different
choice of how to represent it.
Regards
Matthew
===============================================================
Matthew West http://www.matthew-west.org.uk/
Principal Consultant Shell Visiting Professor
Operations & Asset Management The Keyworth Institute
Shell Services International The University of Leeds
http://www.shellservices.com/ http://www.keyworth.leeds.ac.uk/
H3229, Shell Centre, London, SE1 7NA, UK.
Tel: +44 207 934 4490 Fax: 7929 Mobile: +44 7796 336538
===============================================================