Excellent dialog, though I don’t think I’ve yet ingested it!
Thanks,
Leo
From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx]
On Behalf Of henson graves
Sent: Sunday, February 19, 2012 2:40 PM
To: 'Ontology Summit 2012 discussion'
Subject: Re: [ontology-summit] Ontology Engineering for Systems Engineering [components, roles, filers, and role relations]
Dear Matthew,
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 story.
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 another plant."
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 or after).
- It can survive complete replacement of all its parts at once.
- It can survive periods of non-existence.
- 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 characteristics.
Ontologists need to step up to the mark here and provide proper recognition for system components.
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 Hamlet.
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 system role.
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 component is.
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 analytic power.
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 engineers.
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 metamodeling
architecture:
• 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 UML specification)
• 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 pump?
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 unit.
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 language.
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 mentioned.
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 logic).
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
L
of the class model at the M1 level.
HG: 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.
HG: 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 some extensions.
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 beyond FOL.
HG: The way that I think about roles is that R1 is a subtype of the product type (C1,101H).
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 an R1-relationship.
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 level up.
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 things.
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 component.
HG: This is a good and interesting point.
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 components.
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 for engineers.
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 class.
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 invariant relationships.
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 space-time.
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 discussion.
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 hasoxygenatom[1]Oxygen and hashydrogenatom[2]Hydrogen.” 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 useful.
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 the parts.
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.