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.