ontology-summit
[Top] [All Lists]

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

To: "'Ontology Summit 2012 discussion'" <ontology-summit@xxxxxxxxxxxxxxxx>
From: henson graves <henson.graves@xxxxxxxxxxx>
Date: Tue, 21 Feb 2012 10:11:39 -0600
Message-id: <SNT106-DS252513FC7D678559B8BB9FE4670@xxxxxxx>

Dear Matthew,

Your points about products and their specifications are well taken. As you are aware there are lots of situations where one is constructing a specification for a large production run for manufacturing say iPods. The concepts I outlined or something like them are needed for those situations. By the way I have used the basic approach outlined to construct axioms sets (models) molecules such as the water molecule.  The water molecule models that I have constructed can be proven to have many structurally isomorphic instances. The specification concepts are also useful in dealing with implementations which deviate in some way. An engineer friend of mine in charge of a line of semiconductor manufacturing systems (very large, complex and expensive) pointed out that when they made a service call for a customer’s system, the first thing was to identify what had been added or changed since it was delivered. These are as you know the real world of engineering and any useful formalism has to address this kind of thing.

 

Regards

- Henson

 

From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Matthew West
Sent: Tuesday, February 21, 2012 8:55 AM
To: 'Ontology Summit 2012 discussion'
Subject: Re: [ontology-summit] Ontology Engineering for Systems Engineering [systems, components, and PATTERNS]

 

Dear Henson,

Actually two plants genuinely being identical in specification is surprisingly rare. I can only think of 2 occasions where this has happened. In both cases the plants were built next to each other. A much more usual circumstance is that a design is evolved and developed from a previous one. Remember, we are typically not talking about building hundreds of these a day, but one or two per decade – at most.

 

Non-the-less I completely accept that there is a specification for P101, and that it might have more than one occurrence, and  that the spec exists as a class even if there is only one (indeed that is more the problem we have had persuading people in the industry).

 

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 henson graves
Sent: 21 February 2012 14:47
To: 'Ontology Summit 2012 discussion'
Subject: Re: [ontology-summit] Ontology Engineering for Systems Engineering [systems, components, and PATTERNS]

 

Dear Matthew,

As far as I can see we are still pretty much in agreement. My formalization is designed to work for specifications that may have many instances as well as for specifications that are categorical in the logician’s sense that they have only a unique model. Note that I really can talk about an instance of DU and any instance will necessarily have a pump. This use of DL class constructions provides a mechanism to specify necessary components.

 

I am not making P101 a class. I am using a class CBP for bottom pumps. What I am doing is making P101 a function defined for the class DU. You are correct that if 21 is the unique unit of the distillation unit then the value of P101 at 21 which I write as 21.P101 is the unique individual component part of unit 21. Surely in your industry one has replicated units of various sorts and so one does need to distinguish between the units.

 

I haven’t noticed any  comments regarding the formulation of patterns, or for that matter any substantive comments on the whole dialog.

 

Regards

- Henson

 

 

 

From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Matthew West
Sent: Tuesday, February 21, 2012 3:20 AM
To: 'Ontology Summit 2012 discussion'
Subject: Re: [ontology-summit] Ontology Engineering for Systems Engineering [systems, components, and PATTERNS]

 

Dear Henson,

 

Your story regarding the life of R101 resonates with me, but I would like to revisit it again for clarification. With regard to your diagram

As I understand it you are saying that P101 is an individual that participates in specific relationships within the crude distillation unit, e.g., connections to C1 and C2. If the diagram is a description of a specific distillation unit then S4567 is also an individual and further S4567 =D P101 for some time duration D.

MW: Strictly it is S4567 for period D = P101 for period D.

If the diagram is a specification for which there may be many or no realizations then certainly P101 is a tagged part of the specification.

MW: It’s not intended that way. Distillation units are generally one-off constructions, there may be some common features, but things like the local climate and availability of cooling water, and its temperature, will all affect the design. But there is a design as well as the individual even so, just only one implementation. P101 is the realization and not the design though.

But most likely S4567 would not be needed in the model.

MW: Correct, a designer does not care about S4567. That is the constructors/maintainers problem.

You suggested an informal definition for “system” as being 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. This informal definition certainly works here.

As you know there was discussion in the posts regarding whether P101 really was an individual, a class, a role, or whatever. You also suggested that there is relatively little in the ontological literature on what you have called a system component, and on the part relationship that you get in e.g. a bill of materials, and the idea that a system may have necessary and perhaps optional parts. I also have found relatively little in the mereology and mereotopology literature applicable to system components. So I have attempted to sort this out in a form that could be used by engineering modeling languages and support reasoning on the models (engineer’s sense). Here is a way to deal with some of these issues that has worked well in practice, at least in my experience in modeling things like the distillation unit. I will be very interested to find out if I am missing something in the ontology literature as well as any comments on the approach outlined below.

The distillation unit can be represented as an axiom set in a Description Logic as follows: the axiom set would contain a class DU for the distillation unit system, classes C1 and C2 for the columns, a class CBP for column bottom pumps, and a binary component relation hasPump used to express that any distillation unit has a pump. One can express that an instance of the system DU necessarily has a component pump with the Description Logic assertion

                DU [1]R.CBP.                                              (1)

If this assertion is translated into say FOL then the assertion becomes

                d. d:DU implies ! p. R(d,p).                    (2)

Further one can introduce P101 as the name for the unique part p which satisfies the component relationship. P101 is a Skolem function for the hasPump relation. Thus any valid interpretation of the axiom set DU necessarily has a pump. If there is only one distillation unit then P101 is a Skolem constant. If there are multiple distillation units then for any distillation unit dk, i.e., dk:DU, the notation dk.P101 is the individual pump which belongs to the unit dk. Thus dk.P101:Pump. This construction enables one to distinguish components of multiple distillation units. The use of Skolem functions in this context is also beyond the kin of DL, but is well known in logic. Skolem functions provide semantics for the computer science embedded object constructions, as well as the engineer’s composite structure. This explanation may also be in the literature but I am unaware of it.

MW: You are actually making P101 a class still it seems to me, and dk.P101 is the P101 on a particular unit, i.e. what I have been calling P101. I’m OK with that, since it does recognize the individual. In fact I used a shorthand for P101, its full name was 21P101, where 21 was the unique unit number for the distillation unit.

This idea can be extended to give a full specification for a distillation unit. This approach firmly makes P101 an individual and distinguishes it from its relation relationship of being a pump for the distillation unit. To represent the connections requires a language construction which is not standard in DLs, but one that can be added under restrictions without destroying the decidability properties. I am including a draft of a paper which does a version of the components and connections. It is targeted to a rather different audience from that of the Ontology Summit.

From my perspective the diagram represents an engineer’s model (logician’s axiom set) at the M1 level; M0 containing physical reality but virtual reality as well. An M1 level model may or may not have S4567 as an individual, again depending on whether the model is intended as a description of a concrete distillation unit or as a specification for distillation units.

MW: S4567 is at M0. There would be a manufacturer’s model in M1 that it would be an instance of. At some point in the design process, a manufacturer’s model would be chosen that meets the spec for P101, and one (or more likely two) individual pumps ordered.

Within the M2 layer one can define a meta-class Msystem which has the syntactic property represented in assertion (1). The pattern is that the axioms for a system include an assertion that it is a subtype of a conjunction of existential restrictions and some other things to represent the connections. In this case the class DU is an instance of meta-class Msystem. So Msystem is part of a System ontology and it is most definitely a pattern. So in this account patterns and ontologies are pretty much the same thing. I have used such patterns in the context of model based product development using SysML. For example one has an ontology (pattern) for an aircraft decomposition. These patterns can greatly accelerate product development.

You have explicated a notion of identity needed in any engineer’s modeling language which seems correct to me. I believe there may be work in logic relevant to this. But for now let’s just take it as what one wants and sort out the semantics of it later.

 

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.

 

 

 

 


_________________________________________________________________
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)
<Prev in Thread] Current Thread [Next in Thread>