dialog, though I don’t think I’ve yet ingested it!
I have been
attempting to follow the discussion on “system components,
roles, fillers, and role relations”.
MW: Last Thursday I complained that
most ontologies do not give adequate treatment to what I
call system components, and if ontology is going to gain
traction within the systems world, it needs to get a better
understanding of this central idea in systems engineering.
I illustrated the issue by telling the
(simplified) life story of a system component: the pump,
P101, at the bottom of a distillation column. Here is its
Figure of Distillation Unit and
replacement of system component.
The designer creates a drawing of the
distillation column including at the bottom of the column a
pump to pump away the column bottoms. He labels it P101,
decides that one pump will be sufficient, and gives the
specification for the pump in terms of Net Positive Suction
Head, differential head, flow rate, materials of
construction, and many other things.
The construction engineer picks up the
drawing and specification and notices he has to install a
pump as P101. Fortunately, he has a pump in stock from a
previous project, that has been in stores unused for 5 years
which exactly meets the specification. On it is stamped
Serial No S3556.
The designer and the Operator comes to
see the pump be installed, and once the connections are
made, he gives the pump a friendly kick and says to the
construction engineer "It's good to see P101 realized at
last". The construction engineer says in return "Yes, and
it's good to get S3556 off my hands at last." He turns to
the operator and says "Why don't we change your drawings to
show S3556 instead of P101?" The operator says "No, don't do
that, it's a replaceable part, and one day another pump will
be put there, and I don't want to have to change all the
drawings and other documentation that refers to P101 each
time it is replaced, as far as I am concerned it's the same
pump whatever is installed there."
Some time later the pump breaks down
and needs to be taken back to the workshop. The maintenance
engineer says to the operator "Hi, can I take S3556
installed as P101 back to the workshop?" The operator
replies "Sure, but what am I supposed to do without my P101?
If it does not exist I cannot operate my distillation
column." The maintenance engineer responds, "I understand.
We have another pump S4567, that meets the same
specification as P101. We'll replace S3556 with it and you
will only be without P101 for a few hours. I don't
understand how you can continue to call it P101 though when
all the parts have changed at once." The operator replies "I
don't care about that. What I care about is what is
connected in my system to pump the liquid from the bottom
of the column. As long as it does that, it is P101 to me."
Later the distillation column is
demolished. The operator says, "A sad end, I was very fond
of P101, but it is no more." The demolition engineer says,
"Yes indeed. Fortunately, we can take S4567 and use it on
It's probably worth summarising the
key characteristics of a system component:
- It comes into existence the first
time it is installed.
- It is identical to the equipment
items installed, whilst they are installed (but not before
- It can survive complete replacement
of all its parts at once.
- It can survive periods of
- It ceases to exist when the system
it is a component of ceases to exist.
This is clearly rather different from
the life of ordinary physical objects. However, relatively
few ontologies recognise that such things exist. Many try to
fob system components off as being classes, or abstract
individuals, though these clearly do not have the required
Ontologists need to step up to the
mark here and provide proper recognition for system
PatH: Very good question, Matthew. Let
me try out an idea on you. Your P101 is actually a role
played by a pump, rather than a pump itself. Think of it as
being like Hamlet, as played by Lawrence Olivier (P101 as
played by S3556). You can change actors, and Hamlet is still
Hamlet - same role - and while Olivier is playing the role,
he *is* Hamlet, at least in a sense. But this second "is"
cannot be identity, since you can kick the actor, but you
can't kick a role.
MW: Well let's look and see just what
the parallels are. First if we start with a performance of
Shakespeare's Hamlet, then that is an activity, and
Shakespeare's Hamlet is a class of activity whose members
are all those performances. The performance of a part, is
the participation of an actor in that activity, in a role,
for example Hamlet. Just as the performance of the play is a
member of the class of activity Shakespeare's Hamlet, the
performance by an actor of Hamlet is a member of the role
Hamlet in the play. Now we can say more that there is a
constraint on the relationship between the play,
Shakespeare's Hamlet and the role Hamlet (both of which are
classes) such that each member of the play has a member of
the role as a part.
MW: Now we can construct a similar
structure around system and system component. A system, of
course, is not an activity. However, it is reasonable to
compare a system for the whole of its life with an activity
for the whole if its duration. So we will have system and
class of system and system component and system role, where
a system component is the component of the system, and a
member of a system role. Finally, each instance of the
system would have a member of the system role as a system
component. For our P101 example, the class of system might
be Crude Distillation Unit Type 3, the system role might be
Column 1 bottoms pump, and the particulars would be Shell
Haven CDU1 as the System, and P101 as the Column 1 Bottoms
Pump for CDU1.
MW: Well fine, but this does not cover
what I have been talking about, which is when the physical
pump is replaced in the same system component. The proper
parallel here with the play would be when Sir Laurence
Olivier plays Hamlet for the first act of a particular
performance of the play, and then Sir John Gielgood performs
the second act, with further changes throughout the cast.
MW: Now I would not say that in this
case the illustrious knights were playing the same role. In
fact they have definitely not played the same role, or they
would have been saying the same words in the same order.
What is happening is that they are playing different parts
of a performance of the role, and I would describe the
relationship as one of whole-part, each is playing a
different part of the whole performance of the role of
MW: And this indeed is why I think
that system component is more properly an individual than a
class, and the pumps that are installed play parts of that
MW: Of course, I will concede that
there is a set of the different parts of the performance of
Hamlet by the two knights, but I would not think that that
set was the object of interest when considering the playing
of the role Hamlet in a performance of the play, and I do
not think that the set of installed pumps is the object of
interest when I am considering what sort of thing a system
PatH: Both a pump and a pump-role are
spatiotemporal entities, but they have different identity
conditions. The identity of a pump, like any other physical
object, is determined by the disposition of pieces of
material stuff (metal, plastic, rubber), but the identity
of the role is determined by its interfaces to the rest of
the system (being connected to this pipe in this place and
operated by this controller, etc..)
MW: I agree. They are a different
category of physical object. Apart from the things you
mention above they can also survive the complete replacement
of all their parts at once (as can the role of Hamlet when
the actor is substituted) and they can survive periods of
non-existence. You don't find something suitable in many 3D
ontologies, though you do find them in at least some 4D ones
like ISO 15926, and probably IDEAS. The work Nicola and his
colleagues are doing is clearly moving in the direction I am
showing here, but the difficulties they are having clearly
show the limitations that 3D ontologies have in their
HG: For the most
part I think that I agree with you and disagree with a lot of
people. Sometimes I am not sure whether this is the case and
wonder if the problem is different terminology. Perhaps we can
sort this out.
MW: The main problem is that most
people with any background in philosophical ontology,
especially if it is slight, have preconceptions about what
sorts of things there possibly are at a high level, and
system component does not fit neatly into any of them. So
mostly what you have seen is various people trying to
shoehorn system components into the things they do know.
Most of my comments on the proposals of others have been to
point out why their scheme is not correct, or where their
approach falls short of meeting natural intuitions of
HG: This is my impression also. They keep
talking about earth worms or space-time worm holes or in any
case things I am not very familiar with. So your comments
are to address what ontologists need to know about the
ontology of engineered systems.
MW: The obscure language (to us) here
is a space-time worm. To translate, they mean what we would
understand by a state, i.e. something for a period of time
during which some property is true, e.g. a door whilst it is
open. One of the tricks I have noticed philosophical
ontologists play is to wrap ideas they do not like up in
obscure language like space-time worm when there are
perfectly ordinary words they could use. These then get
absorbed into the literature, and so when they get read back
to people like you and I, we think that the idea is strange
rather than just the language.
HG: To attempt to
sort out terminology and see who is really arguing what I
would like to put the discussion in the OMG MOF framework. As
you no doubt know the MOF specification adopts a four-layer
M0—What is to be modeled within the real world
M1—Models (for example, a UML model of some part of the world
M2—Metamodels (for example, an abstract syntax model in the
M3—The meta-metamodel which specifies the metamodel languages.
MW: I should probably point out that I
am not a fan of the OMG four layer architecture. It’s not so
much the layers, but that they are disjoint. My view would
be that all these things are in the real world or things
that are themselves signs for other things, or classes of
those things, and classes of classes. The 4 level
architecture requires that at each level that you have
classes, but no way of saying which things across all the
levels are classes.
HG: I too have never been a fan of the OMG
4 level architecture for similar reasons. However, speaking
of MO and M1 do enable separating the models in some
engineering language to be distinguished from their
interpretations in the sense of logic. Note that in the 4
level architecture the interpretations of an M1 model which
consist of physical parts is in M0. However, an M1 model
which contains individuals may be used to construct valid
interpretions of the model in M1 which are in M1.
HG: Actually for
this discussion one only needs M0 and M1, but for a discussion
of the relationship between conceptual models and ontologies,
M2 seems to be needed. My impression is that a lot of
confusion arises by an inability to distinguish between M0 and
M1. I suspect that I am using terminology somewhat differently
from you. But maybe we can figure this out.
HG: M0 is where
the real world of airplanes, oil refineries with their parts
with identification numbers live. Further in this world one
part may be connected to another. For example a pump with
serial number no. 5755/A may be connected to two tanks. Also I
agree that the components live in a 4D world.
MW: That’s a pretty good start. Where
do properties live, and the manufacturer’s model for the
HG: Properties live in M0 and a
manufacture’s model lives in M1. The models in M1 are
expressed in some language that is assumed to have
individuals, classes, and binary properties as specified by
an M2 metamodel. I will defer discussion their semantics for
a bit. M0 is the target for valid real world interpretations
of the models in M1. In my naïve view I do not assume that
M0 has classes as extensional things, rather one has
procedures to evaluate if an individual component satisfies
a class. I am assuming that the component has a model number
which identifies the class that is presumed to be an
instance of and a serial number which identifies the
component uniquely. As you are aware in some industries
counterfeit components is a real issue. As a result one may
need elaborate testing procedures to determine if a
component is a valid instance of the specification class. On
your last flight on a commercial aircraft take a guess as
to how many counterfeit parts were on it.
HG: M1 is where
models live. There are different kinds of models. One kind of
model attempts to describe say a particular crude distillation
unit uniquely at a point in space-time.
MW: A key question here is whether
your model is a representation of the crude distillation
unit, or a specification of a crude distillation unit, i.e.
are we looking at some signs that stand for it, or some
classes that it is a member of. I’m not sure the OMG
architecture is clear about this distinction.
HG: I agree that OMG does not
appear to appreciate the difference between a representation
of the crude distillation unit and a specification for the
HG: Such a model
would have serial numbers for all of the components and
connection lines between them.
MW: OK. So these are signs.
HG: yes a model that attempts
to describe a particular distillation unit would consist of
individuals which are within the language in M1. Lets look
at your crude distillation unit example from the 4 layer
perspective. The diagram on the right looks like an M1 model
which could be a design specification or a description of a
particular distillation unit. I cannot tell without more
detail. The pump symbol on the left with the label “Serial
No. 5755/A” appears to be an individual within an M1
MW: Yes. I always try to start
analysis from real world individuals, and then work out from
there in various directions (classes, things that might be,
etc). I find this keeps you grounded. So the diagram is
supposed to represent a real distillation unit that you can
walk up to and kick. There are specifications for the items
in the diagram, but the diagram shows particular objects
that meet those specifications. P101 is a system component
of the Crude Distillation Unit. It is the bottoms pump from
C1 to C2. Initially the pump with serial No S3556 is
installed. At a later date this pump is removed and pump
with serial no S4567 (see diagram above).
HG: However, this
is not the kind of model used for a design specification. An
architecture or design specification describes a class of
implementations or realizations.
MW: Right. The second type of model I
HG: In UML, SysML
or OWL such a model would use three classes: C1 and C2 for
tanks and 101H for pumps. The distillation unit model would
likely have a connection relation R1 between C1 and 101H and
another connection relation R2 between 101H and C2.
MW: You need to be careful here. I
think what you are calling a connection relation, is really
class of connection, in that it is a member of one class
that is connected to a member of the other class, i.e. it is
an instance of the C1 tank class that is connected to an
instance of the 101H class.
HG: Yes that is what I mean. A
connection relation is a subtype of the Cartesian product
(C1,101H) and a connection instance in M0 is a pair
<c1,p1> in Conn1 where c1 is an instance of C1 and p1
is an instance of 101H.
HG: In many
languages these connection relations would be called
properties or roles.
MW: Which does nothing to aid clarity.
Actually, even relation is a mathematical structure, and not
what is really being represented…HG: yes but I am talking about models in
M1. I am making some assumptions regarding the
expressiveness of the language in which the distillation
unit is being modeled. I am assuming that one has at least
individuals, classes, and subtypes of Cartesian products of
classes. As I am sure that you know there are a lot of
logical languages other than set theory which provide these
constructions as well as semantics for the constructions.
The distillation unit model would be called a class model.
The real distillation unit on the M0 level would
presumably be a valid interpretation (in the sense of
By adding sufficiently many individual terms to the model
one could construct a term model for the distillation unit
within an M1 model.
MW: Actually, in logical terms –
strictly model theoretic terms, the real live distillation
unit is a model of the ontology
of the class model
at the M1 level.
I am being careful. In strictly model theoretic terms the
models in M1 are really axiom sets and the valid
interpretations of them are distillation units in M0.
MW: NO!! In strict model theoretic
terms the real physical distillation unit (or at least a
representation of it) is a model of the axiom set. I know
that sounds crazy, but logicians have what is a model of
what the opposite way round from us engineers. In model
theory logicians take an axiom set and consider valid
instantiations (models) of the theory and are concerned
about unintended models, i.e. models (instantiations) that
are valid, but which they did not wish to be valid. HG: I do not see that we are in
disagreement, see below.
I am not sure how ontology got in at this point. I just
haven’t said what logic I assume that I am working in. I
haven’t really mentioned it except to say that it is an M3
concern. I will generously assume that you are in some way
referring to the semantics of classes, properties and any
other language constructions I use to build my models in M1.
MW: You introduced it with the phrase
“(in the sense of logic)” above. That sent us down this rat
hole. It’s useful to have the engineers and logicians
different uses of the word “model” clarified, but that was
the only purpose of this section for me. HG: I perfectly understand that what
engineers call models are what logicians call axiom sets and
what logicians call models or valid interpretations are what
engineers call implementations, realizations, or maybe
virtual reality if the interpretations are not in the real
world. By the way there are a lot of results which show how
engineer’s models in UML or SysML can be embedded within
various kinds of logics. When the engineer’s model is
embedded it becomes in a natural way an axiom set. We may
have gone down a rabbit hole in our dialog as we didn’t
realize when one of us what using the word “model” in the
engineer’s sense and when it was being used in the
logician’s sense. The real rabbit holes in conversation
result in my opinion when people cannot keep the distinction
between an axiom set and its valid interpretations straight.
There may be many other valid
interpretations of the distillation class model. One
interesting problem for logicians is how to build something
like a class model for which all valid interpretations have
the same structure. You really cannot do this in OWL without
MW: We have had problems rendering ISO
15926 in OWL, even OWL 2.
HG: That is not surprising. I
don’t know anything about ISO 15926 but if it can be used to
build effective models of things beyond Napa wines and pizza
toppings then OWL2 would be insufficient. This statement
does not cast any aspersions on OWL it simply notes that
OWL2 for good reason does not have constructions for
embedded parts, operations (functions), or behavior.
MW: Strictly it doesn’t need to. It
only needs the things that you can build those with. For ISO
15926 the problem is that OWL only allows a single level of
classification. So if I have some items of equipment, then I
can talk about types of equipment, but not classifications
of equipment types (where the equipment types are
instances). Or at least I cannot do that using the internal
instance of relation.
HG: I think that I agree with
you, but this need more discussion. It sounds like you are
saying that you need a higher order logic in which a type of
equipment can be an instance of for example a power type.
MW: First order logic is sufficient
for this. I’ve not yet found a need for anything genuinely
HG: The way that I
think about roles is that R1 is a subtype of the product type
MW: Sorry, this does not really tell
me what R1 is.
HG: An instance of
R1 would be a pair <c1,p1> where p1 and c1 are instances
of the respective classes.
MW: OK, it looks like R1 is intended
to be a relationship type between C1 and 101H.
HG: yes R1 is a relation type.
As a relation type it can have subtypes as well as
instances. An instance <c1,p1> of R1 could be called
HG: I would call
the M0 connection a relation instance. The M1 property can of
course have subtypes.
M2 which is the
OMG meta-model level is where one would specify properties for
part classes and roles. Of course to expressive properties at
M2 one really needs a meta-logic rather than a meta model.
MW: Well, one of the good things is
that as long as you are dealing between just two levels,
then the same logic will do the job, because logic, well OWL
at least knows about classes and instances, and the classes
at one level of the architecture are instances at the next
HG: Yes, OWL has classes and
instances and in some cases the instances can be used to
build a valid interpretation (logician’s model) of the axiom
set (engineer’s model). Of course in the M1 logic you have
to equate equal terms of the logic, e.g. 2+2 is the same
thing as 4.
HG: Let me know
how this fits or doesn’t fit with your way of thinking about
MW: Yes, that seems reasonable. But it
does not cover a system component (M0) being replaced, but
still remaining the same system component.
HG: what I have said does not
cover the issues of identity and we still haven’t talked
much about ontology, or the semantics of classes,
properties, and language constructions in M1. My impression
is that if a part with a specific serial number is replaced
with another component with a different serial number that
the two components certainly are not identical but the unit
in which they were replaced is still the same unit.
MW: Terminology alert. I am using
system component for what you are calling unit. So I talk
about a system component being the thing that is invariant
over the life of the system, where several equipment items
might be installed and spend some time as that system
HG: This is a good and
MW: The next bit is that in allowing
something to still be the same unit/system component but
have all of its parts replaced when one component/equipment
item replaces another as that unit sets of all kinds of
identity alarms for your average philosophical ontologist.
Physical objects are not supposed to retain identity when
all their parts change. Take your car, if I borrow it and
smash it up, buy a replacement exactly the same and
re-register it with your registration no, is it the same car
really? No. But what we are saying here is that for a
unit/system component, when you take all its parts a way and
put another one in its place, it is the same thing. It is
not too hard to see why they might find this hard to accept.
HG: All this says is that the criteria for
identity of a unit that I am using allows replacement
MW: Exactly. The problem for most
ontologists is that they do not have such a category in
their armoury, and are reluctant to admit one (another
feature of ontologists is the very high value put on
parsimony). HG: This is
reminiscent of the problem that fire, air, water, and earth
are possibly not the right concepts for an upper ontology
The replaced component still has the same
specification, i.e., it is still a member of the same
specification class. But after being swapped out it is no
longer part of a relationship instance of the connection
MW: There are actually a number of
relationships here. Being the Unit/system component means
being connected to other components of the system, and being
a part of (component of) the system. That is part of being a
system component. The tricky bit is becoming the system
component, because what I would want to say is that whilst
the component/equipment item is installed, it
is the unit/system component. Or to put that slightly
more formally, there is a state of the component/equipment
item that is also a state of the unit/system component. Now
the relationships here are those of this state being a state
of both the component/equipment item, and of the unit/system
component. HG: This sounds
like a fruitful topic for ontologists.
HG: Relationship instances change with
respect to space-time. People who once were friends of mine
are no longer friends. So friendship and partOf are not
MW: Actually, in the way I have said
it above, all the relationships are eternal. That state will
always be a state of the system component and the equipment
item. The temporality is determined by the start and end
date/time of the state. Some people (myself included) would
argue that having temporal relationships is problematic,
because they are essentially abstract (you cannot kick them)
and it is questionable whether abstract things can exist in
space-time, and hence cannot really have a temporal extent
(since they do not have a spatial one). But there are plenty
of people who ignore that difficulty without dying.
HG: This argues the need for
more ontological analysis of how things are indexed by
Other than your non-smiley face we have
avoided talking about ontology.
MW: Well there a plenty of ontological
issues you have touched on in your latest comments.
What is the difference between an ontology
and one of my design models (axiom sets)? The distinction
between an ontology and a model is imprecise in the
literature. However, a conventional definition might say
that an engineering ontology provides terminology for
modeling physical objects, their properties such as parts
and connections as well as properties which are observed and
measured. For example, candidate terminology for an
engineering domain might include physical object for
entities as vehicles.
MW: Well I would want an ontology of
both your physical objects and your design models, and the
relationships between them.
HG: Yes I agree and this is
where I think that upper or foundation ontologies are
extremely useful in the engineering of systems.
In OMG terminology,
Models are created using a
modeling language that is described by a metamodel (M3). OMG
also describes a level M3 metamodel as a specification for
an ontology and the modeling language in which the ontology
is expressed. This makes some sense in that their metamodels
which are class models describe the syntax used within a
model constructed according to the metamodel. For example,
the OMG MOF facility contains definitions of metamodels for
UML, SysML, and OWL. This is ok as far as it goes. The
metamodel does syntactically specify the terminology, e.g.,
that classes and property are language constructions to be
used in a model of the language in which the model is
defined. This is a start, but of course it does not provide
any semantics for the language constructions. This could be
done by using a meta-logic rather than simply a meta-model.
MW: There is no such thing, that I am
aware of, as meta-logic. You can of course apply logic to
meta-models, but that does not make a meta-logic, it is just
the same old stuff applied at a different level of
abstraction. HG: Sure there
is such a thing. The UML metamodels can be embedded as
axioms within a logic whose valid interpretations are axiom
sets in M1. In fact if one replaces metomodels with
meta-logic then many of the axioms about mereology can be
stated there and can be syntactically checked when axiom
sets (engineer’s models) are parsed.
MW: Hmm. Well for me an
example of a logic is: and, or, not, implication, universal
quantifier, existential quantifier. Everything else is part
of the lexicon. So I would say you are dealing with
different lexicons in M0, M1, etc, but the same logic.
Within a meta-logic one could express
axioms for classes such a Part class. My impression is that
the properties of Part classes needed for modeling oil
refineries and aircraft have somewhat different axioms than
are used by most ontologists. This of course requires more
MW: Well, the philosophical ontology
literature has quite a lot of mereology and mereotopology
(the posh words for whole-part and connection) but
relatively little on what I have called system component. So
this is what I think is the biggest are that needs more
work. The other area I think could do with work is on the
class of part relationship that you get in e.g. a bill of
materials. It seems to me that there are many possible
flavours here, e.g.:
A whole of class A
may have a part that is a class B.
A whole of class A
must have a part that is a class B.
HG: Again I agree with you. What you are
saying are typical issues of creating design specifications
and acceptance criteria for the resulting manufactured
articles. By the way the OWL and Description Logic class
constructions can be used effectively to express necessary
parts. For example, I am told that a water molecule must
have exactly one oxygen and two hydrogen atoms connected in
a specific way to be a water molecule. One can express the
necessary parts with “Water subclass of
hasoxygenatomOxygen and hashydrogenatomHydrogen.” Here
Oxygen and Hydrogen are classes and hasoxygen is a part
relation whose domain is Water and whose range is Oxygen.
This is a restricted existential quantification statement.
HG: I notice that you have used the word
system occasionally. I have not used it yet. It is not that
I don’t like it; I do like it. I am just tired of people
insisting that we cannot proceed with discussion without
defining “system” or “engineered system”. Another
suggestion has been that we enumerate all of the systems or
engineered systems as opposed to defining them. This idea
does not seem very realistic to me. One could give examples
of system of course. I am sure that the same argument that
one has to define terms could be applied to “unit” or most
any other common word in order to stop discussion, as well
as providing cover for those who do not believe the
discussion should be continued. While I agree that one
should work towards precision in classification the lack of
precision need not stop useful discussion. To quote the
mathematician Bruno De Finetti it is better to build on sand
than on nothing at all.
MW: Hmmm. Well on the one hand I don’t
think it is that difficult to come up with a definition of a
system. The only problem is coming up with one definition
that everyone agrees to, and I don’t think that is
necessary. I think it is enough to list as many definitions
as people wish to propose, in fact I think such a list has
already been contributed. I agree examples are always
MW: My definition would be that: a
system is a physical object that consists of components
where the components are connected and interact such that
the system has behavior that is more than that of the sum of
MW: The importance of having a system
as something that is defined, is that unit/system component
does not exist without it. A system component is a component
of a system, and without a system that it is a component of,
does not exist. HG: Ok I can
go with that. My units certainly have that property. My
basic objection to the word “system” in the Ontology Summit
context is that mention of it seems to set people off on a
line of magical thinking in the sense of conflating somebody
trying to build an oil refinery to refine oil and the oil
refinery having some intrinsic intension to refine oil. I do
not think the latter is needed to talk about oil refineries.
If one is discussing the political and social aspects of oil
refineries, then more may be needed.
HG: I hope that we haven’t added too many
more worms to our can.