Re: [ontology-summit] Ontology Engineering for Systems Engineering [comp

[Ron Wheeler <rwheeler@xxxxxxxxxxxxxxxxxxxxx>]

On 20/02/2012 12:45 PM, Matthew West wrote:

Dear Ron,

 

Actually, that is not correct (please reread my description below).

 

In addition many different P101's are in "existence" at once. 

 

MW: There is only one P101. It is (was at as happens now) the pump at the bottom of Column 1 of a particular distillation unit. P101 is not a design for which there can be many instances. There is a design too, and P101 is one of its instances (see my exchange with Pat Hayes for clarification on how the relationship works).

There could be many designs for the system in which P101 occurs. In the designs, each P101 could be different in terms of it capabilities and properties.
They are all called P101 and appear in many documents with that designation with the understanding that at implementation time there will be some actual pump with a make model and serial number that performs the function. 

 

There is only 1 S3556(at least there should be only 1).

 

MW: Agreed.

Operations and Maintenance see P101 and S3556 as being very closely related. Turning on or off the switch marked "P101" will cause S3556 to act.

 

MW:  It causes both P101 and S3556 to act, provided at the time they are coincident.

 
Engineering quite often has no idea about S3556 and for modelling, the relationship is often not relevant.

 

MW: I agree. S3556 is primarily of interest to the project engineer who builds the plant, and the maintenance engineer who manages the maintenance and replacement.

They may have dozens of different P101's in existence is various models, engineering reports, upgrade plans or dreams by the fireside.

 

MW: No. You have misunderstood what P101 is (my intention). It is a particular one.

This is a bit confusing to me. "Particular" in what sense? Agreed if you are talking about the identification of an M1 creature.
The introduction of the idea of "role" looked promising but I am not sure if M1 entities are anything other that fillers of roles.

The pump known as "P101" has may different specification is the various models in which it appears.
Each simulation that is created during the design or upgrade of this part of the refinery could have slight or major variations in the nature of P101.

There may be many different configurations involving P101 with different valves and sensors attached and even different piping and tank configurations.

 

MW: There can be different P101’s in different possible worlds (as with anything else), but only one in this world.

Now we are introducing the concept of "world".
Is each simulation a new world? It does have a lot of the characteristics of a world.

Do we lump together the Physical M0 objects and some set of M1 objects and put them in one world and all of the
other M1 instances with a P101, each belong to a different world?

I am not sure that introducing "world" actually helps a plant to have a rational and comprehensive view of its universe.

It is a question of judgment as to when one should stop calling the pump in the model P101 and cause a new pump P324 to come into existence.

MW: No. P101 is the pump at the bottom of C1, and whatever pump is that is at the bottom of C1 is P101. Anything else is something else.

I think that this is a good general policy.
The judgment comes in when you change the configuration of the system sufficiently that identifying the pump at the bottom of C1 as P101 creates too large a variation in the characteristics of P101 for engineers to accept the new pump as the "same thing".

This is really a side issue and not terribly critical to the discussion.

I think that the general thrust of the discussion is very good without my comments.
I hope that this is adding to the discussion.
If not, just ignore me. You are doing fine.

MW: there are clearly things that still need clarifying.

 

Regards

 

Matthew West                            

Information  Junction

Tel: +44 1489 880185

Mobile: +44 750 3385279

Skype: dr.matthew.west

matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx

http://www.informationjunction.co.uk/

http://www.matthew-west.org.uk/

 

This email originates from Information Junction Ltd. Registered in England and Wales No. 6632177.

Registered office: 2 Brookside, Meadow Way, Letchworth Garden City, Hertfordshire, SG6 3JE.

 

 

 
Ron

On 20/02/2012 10:32 AM, Matthew West wrote:

Dear Ron,

 

I think you are confusing when you can talk about something, with when it exists. For example, I can talk about Winston Churchill and Franklyn Roosevelt and their conduct of WWII now, without confusing that with them existing now. Similarly, I can talk about my holiday next year, without that meaning that I am actually on that holiday.

 

The same is true for systems and system components. Just because something does not exist now, but will exist in the future does not mean we cannot talk about it, only that what we are talking about is that object that will exist in the future. We will have signs that refer to it, and for sure, those signs are objects that exist now, but what they refer to does not, nor need it.

 

Regards

 

Matthew West                            

Information  Junction

Tel: +44 1489 880185

Mobile: +44 750 3385279

Skype: dr.matthew.west

matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx

http://www.informationjunction.co.uk/

http://www.matthew-west.org.uk/

 

This email originates from Information Junction Ltd. Registered in England and Wales No. 6632177.

Registered office: 2 Brookside, Meadow Way, Letchworth Garden City, Hertfordshire, SG6 3JE.

 

 

 

From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Ron Wheeler
Sent: 20 February 2012 14:35
To: Ontology Summit 2012 discussion
Subject: Re: [ontology-summit] Ontology Engineering for Systems Engineering [components, roles, filers, and role relations]

 

This looks very good.
The only tiny quibble might be with the timing of P101's existence.

It may come into existence years before the construction design when the first simulations are created and run to produce the data required to support the capital acquisition program.
It may run through many sets of specifications before a final decision is made to implement the system.

It will live on forever in the engineering project history in each of the configurations that was simulated and analyzed. These may be used for post-implementation reviews, upgrade planning or as a model to be used another refinery.

It may never actually be funded and physically constructed but will exist as part of a system that was built at least virtually.

Ron

On 19/02/2012 4:14 PM, Obrst, Leo J. wrote:

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.

 

-- 

Ron Wheeler

President

Artifact Software Inc

email: rwheeler@xxxxxxxxxxxxxxxxxxxxx

skype: ronaldmwheeler

phone: 866-970-2435, ext 102

-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@xxxxxxxxxxxxxxxxxxxxx
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

rwheeler.vcf
Description: Vcard

_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/   
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/  
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2012/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2012  
Community Portal: http://ontolog.cim3.net/wiki/     (01)