What is Pump Facility PF101? A Study in Ontology Chris Partridge Technical Report 04/02, LADSEB-CNR Padova, Italy, June 2002 Questo lavoro è stato condotto nell'ambito dell'attività del gruppo di ricerca “Modellazione concettuale e Ingegneria della Conoscenza” del LADSEB-CNR LADSEB-CNR Corso Stati Uniti 4 I-35127 PADOVA (PD) e-mail: mbox@ladseb.pd.cnr.it fax: +39 049-829.5763 tel: +39 049-829.5702 -- 1 of 146 -- -- 2 of 146 -- MC1 METHODOLOGY: CASE STUDY 1 WHAT IS PUMP FACILITY PF101? Issue: Version - 6.01 - 01-June-2002 -- 3 of 146 -- Copyright Notice © Copyright The BORO Program, 1996-2002. Notice of Rights All rights reserved. You may view, print or download this document for evaluation purposes only, provided you also retain all copyright and other proprietary notices. You may not, however, distribute, modify, transmit, reuse, report, or use the contents of this Site for public or commercial purposes without the owner’s written permission. Note that any product, process or technology described in the contents is not licensed under this copyright. For information on getting permission for other uses, please get in touch with contact@BOROProgram.org. Notice of liability We believe that we are providing you with quality information, but we make no claims, promises or guarantees about the accuracy, completeness, or adequacy of the information contained in this document. Or, more formally: THIS DOCUMENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. Contact For queries regarding this document please use the following email address: contact@BOROProgram.org -- 4 of 146 -- MC1-iii BORO C O N T E N T S 1 Introduction - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MC1-1 1.1 The source of the case study- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MC1-1 1.2 Differentiating the BORO approach - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MC1-2 1.3 The choice of ‘pump facility’ for the case study - - - - - - - - - - - - - - - - - - - - - - -MC1-3 1.4 Mechanics of the approach- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -MC1-4 1.5 The ECM v2.22 application model - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -MC1-5 1.6 The structure of the paper - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -MC1-5 2 The selected domain - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -MC1-6 2.1 The context - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -MC1-6 2.2 The domain - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MC1-7 2.3 The challenge - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MC1-7 3 Analysing the ECM v2.22 domain - - - - - - - - - - - - - - - - - - - - - - - - - - -MC1-9 3.1 The ECM v2.22 application model - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MC1-10 3.2 EPISTLE engineers’ intuitive concerns - - - - - - - - - - - - - - - - - - - - - - - - - - - - MC1-19 4 Re-engineering the domain - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -MC1-26 4.1 Re-engineering the individuals - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MC1-26 4.2 Re-engineering the upper ontology- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -MC1-52 5 Extending the ECM v2.22 domain - - - - - - - - - - - - - - - - - - - - - - - - - MC1-64 5.1 Extending the ECM v2.22 application model - - - - - - - - - - - - - - - - - - - - - - - MC1-65 5.2 ECM v2.22’s practical approach - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MC1-66 5.3 A strict(er) ECM v2.22 approach - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -MC1-70 5.4 The installation association’s activities - - - - - - - - - - - - - - - - - - - - - - - - - - MC1-72 M C 1 M E T H O D O L O G Y : C A S E S T U D Y 1 WHAT IS PUMP FACILITY PF101? -- 5 of 146 -- MC1-iv BORO CONTENTS MC1 5.5 The physical oil rig’s construction activities - - - - - - - - - - - - - - - - - - - - - - -MC1-73 5.6 The physical oil rig’s relationship with the physical pumps - - - - - - - - - - - - -MC1-74 5.7 ECM v2.22’s extended ontology of individuals - - - - - - - - - - - - - - - - - - - - - -MC1-76 5.8 EPISTLE engineers’ intuitive concerns- - - - - - - - - - - - - - - - - - - - - - - - - - - -MC1-78 6 Re-engineering the extended domain - - - - - - - - - - - - - - - - - - - - - - -MC1-79 6.1 Re-engineering the ground level - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -MC1-79 6.2 Re-engineering the extended upper ontology - - - - - - - - - - - - - - - - - - - - - - MC1-90 6.3 Generalising the re-engineered patterns- - - - - - - - - - - - - - - - - - - - - - - - - MC1-102 6.4 The re-engineered domain - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MC1-104 7 The Case Study - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MC1-105 Appendicies - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MC1-107 Appendix A - The BORO Program and its Approach - - - - - - - - - MC1-109 A.1 What does the business ontology approach do? - - - - - - - - - - - - - - MC1-109 A.2 How can businesses reap the benefits? - - - - - - - - - - - - - - - - - - - - - MC1-110 A. 2.1 Developing awareness and experience - - - - - - - - - - - - MC1-110 A. 2.2 The need for an explanation - - - - - - - - - - - - - - - - - - - - - MC1-111 Appendix B - Core BORO concepts - - - - - - - - - - - - - - - - - - - - - -MC1-113 B.1 Business ontology - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MC1-113 B. 1.1 Ontology(-with-a-capital-O)- - - - - - - - - - - - - - - - - - - - MC1-113 B. 1.2 ontology(-with-a-small-o) - - - - - - - - - - - - - - - - - - - - - MC1-114 B. 1.3 Why have a general framework? - - - - - - - - - - - - - - - - - MC1-115 B. 1.4 An ‘objective’ reference ontology - - - - - - - - - - - - - - - - -MC1-117 B. 1.5 Developing a reference ontology - - - - - - - - - - - - - - - - -MC1-117 B. 1.6 Aspects of the business ontology approach - - - - - - - MC1-119 B.2 Ontological Categories of Object- - - - - - - - - - - - - - - - - - - - - - - - - MC1-120 B. 2.1 Identity (and ‘identification’) criteria- - - - - - - - - - - - - MC1-121 B. 2.2 The ontology’s grounding - - - - - - - - - - - - - - - - - - - - - MC1-123 -- 6 of 146 -- MC1-v BORO CONTENTS MC1 Appendix C - EPISTLE - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MC1-125 C.1 EPISTLE and its ECM - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MC1-125 C.2 Objectives - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MC1-125 C.3 Membership - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MC1-126 C.4 EPISTLE’s ontological flavour - - - - - - - - - - - - - - - - - - - - - - - - - - - MC1-126 C.5 EPISTLE and BORO - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MC1-126 Appendix D - The EPISTLE Core Model - - - - - - - - - - - - - - - - - - MC1-129 MCI - Bibliography- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MC1-131 BORO Working Papers - Bibliography - - - - - - - - - - - - - - - - - - - - - - - - MC1-133 BORO-General Bibliography - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MC1-135 INDEX - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MC1-137 -- 7 of 146 -- MC1-vi BORO CONTENTS MC1 -- 8 of 146 -- MC1-1 BORO 1 Introduction This paper is a case study that describes how the Business Object Reference Ontology (BORO) approach1 works in practice. It describes in detail a selected part of the work using the approach that has been going on in the EPISTLE2 com- munity for several years. This will help people better understand not just the ben- efits of using the approach, but also what it is and how it is applied. It will also illustrate the kinds of results it gives - by providing specific examples of the kind of very general patterns this type of analysis typically produces. 1.1 The source of the case study EPISTLE’s prime deliverable is the EPISTLE Core Model (ECM) - a general model that is used as a basis for developing consistent application specific models. The case study is taken from an analysis of version 2.22 of the model (using an early version of the BORO approach). What sparked the analysis were some intuitively awkward questions that some of the EPISTLE users had been asking about the 1. See Appendix A—The BORO Program and its Approach for details of the BORO Program and its approach. 2. See Appendix C—EPISTLE for details of EPISTLE. M C 1 M E T H O D O L O G Y : C A S E S T U D Y 1 WHAT IS PUMP FACILITY PF101? -- 9 of 146 -- MC1-2 1 Introduction What is Pump Facility PF101? BORO results of applying the framework described in the ECM v2.22 model. The analysis not only resolved these awkward questions, but also provided the basis for a sim- pler, more general, framework. Work is (and has been) going on to incorporate these improvements into future versions of the EPISTLE Core Model. Some of it has already been incorporated into the latest version at the time of writing - v3.1 - and further enhancements are being incorporated into v3.2, which should be published soon. 1.2 Differentiating the BORO approach A major problem facing enterprises trying to build or integrate systems of any real richness, is trying to find a consistent semantic framework for doing this. Without such a framework, as the richness increases, so does the complexity and costs. The EPISTLE framework was developed to provide such a framework. It, unusually in the computer industry, provides a clear high level framework – built on intuition and experience. However, as this case study reveals it is difficult to build such a framework well. Architects and users usually have an intuitive gut feeling for the general patterns that lie behind the specific details of their domain. Specifying these with the kind of clarity and exactness needed for a framework is very diffi- cult. Architects often find themselves making clear general distinctions, which then lead to counter-intuitive and seemingly unnecessarily complicated results. These are often accepted as it is thought that it is possible to get ‘good enough’ results by working with and around them – and that there is no sufficiently easy way of finding a better framework. The BORO approach provides a new tool for dealing with these situations. Like ECM v2.22 it has a framework, but one based upon a business ontology (this is one of the concepts explained in Appendix A—The BORO Program and its Approach ). This is a relatively innovative paradigm for business modelling – and the case study shows how the ontologicallity of the framework: • leads us towards a consistent and more intuitive model of the world. And this, -- 10 of 146 -- MC1-3 BORO 1.3 The choice of ‘pump facility’ for the case study What is Pump Facility PF101? • encourages us to generalise specific patterns into simple general models – with much wider applicability. The case study illustrates how difficult it is to regiment our raw intuitions into a consistent structure without an ontological framework. It provides examples of the typical counter-intuitive results and complexity that attempts at regimen- tation run into. It also provides examples of how attempts to draw out a simple general pattern from similarities based upon raw intuition can (as they usually do) lead to awkward compromises. It then shows how an ontological framework provides a consistent environment, which encourages the safe subsumption of many specific patterns into a few simple general ones – which turn out to have much wider applicability. This has many obvious practical benefits. Intuitive, simple models are much easier to understand. Simple, general models can be transformed into simple, highly functional systems – that are easier to maintain. And in big systems, from a management point of view, simplicity and generality are a necessity. 1.3 The choice of ‘pump facility’ for the case study The case study follows the re-engineering of the ECM v2.22 notion of a pump facility – and its associated notion of a physical pump. This recommended itself as a good choice for a number of reasons. Firstly, it is a good example of a common problem when trying to harmonise understanding across different communities - a goal for both BORO and EPISTLE. It is a common everyday example of different disciplines using the same term, but actually talking about different (intimately related) things. The case study shows quite clearly that attempting the harmonisation raises ontological issues that can only be adequately resolved in an ontologically aware framework. Secondly, it shows how the simple general patterns that lurk in familiar places can be extremely difficult to extract without an ontological framework. The case study provides a number of examples. One simple one is that it was (and is) intui- tively obvious to the EPISTLE engineers that (what ECM v2.22 terms) pump facil- -- 11 of 146 -- MC1-4 1 Introduction What is Pump Facility PF101? BORO ities and physical pumps were both pumps. However, the general distinctions made in the ECM v2.22 framework (which generalised other important insights) meant that this simple insight could not be accommodated. The ontological resources of the BORO framework resolve this issue. Thirdly, it reveals a general pattern that is commonplace in business models – one that it extremely likely to be re-used. Pump facility can be seen as an example of a type of role that persists through a change of its occupier – and so is, in some sense, independent of it. Another classic example is the way organisation roles – such as Chairman of the Board – are independent of the specific person occupying the role. Though in both cases they are dependent of having a pump/person of some type to ‘play’ the role. Clearly it is useful to have a general pattern for these types of situation that can consistently and intuitively be applied across the board. 1.4 Mechanics of the approach The approach is based upon starting with an existing model/system – preferably a working system. This helps to scope the domain and means that a lot of the effort of formalising has been done. In the case of EPISTLE, the starting point was the EPISTLE Core Model v2.22 (from now on shortened to ECM v2.22). The approach takes the existing model/system and re-engineers it into the BORO framework. The analysis starts with particular individuals – hence the title of the paper – ‘What is pump facility PF101?’. The reason for this is our experience of the world is grounded in individuals – they are what we have our strongest intuitions about. We see and touch particular pumps not pumps in general. The analysis of the individuals and the other types of objects is done on an onto- logical basis3 . It focuses on a key characteristic, their extensions. How this works is explained as we start the analysis. Extension is key, within BORO, as it is the basis for an object’s criterion of identity. ECM v2.22 lacks clear criteria of 3. See Appendix B—Core BORO concepts for a description of the meanings of the ontological terms. -- 12 of 146 -- MC1-5 BORO 1.5 The ECM v2.22 application model What is Pump Facility PF101? identity – and the case study shows how BORO having this makes for a better model/system. 1.5 The ECM v2.22 application model The analysis starts by taking an application of the ECM v2.22 data model, and analyses the BORO ontology it implies. This typically involves a re-interpretation (a re-engineering) of what the items in the model originally meant – resulting in a more accurate representation with a better grounding in ‘reality’. This case study focuses on a single simple application model to illustrate the points it needs to make. What we actually did (and what should happen in prac- tice) was to consider a sample that was sufficiently wide to validate the ele- ments of the framework being analysed. An ontology is grounded through its individuals, and the BORO analysis builds up its ontology from these grounded individuals. One hurdle we had to overcome is that the formal ECM v2.22 framework has no individuals – it is a general frame- work for structuring process engineering applications. Individuals are informally used in the general analysis, but only formally found within these specific applica- tions. So, to kick-start the BORO analysis, we devised a specific application model to act as an example of the things generalised into the framework. 1.6 The structure of the paper A description of the case study is given in the main body of the paper. Ancillary information is relegated to Appendices. There is also a BORO Working Papers - Bibli- ography of referenced materials. The case study is broken down into sections. The next section – 2 – The selected domain - describes the domain selected for the case study – and the ontological problem it poses. Section 3 – Analysing the ECM v2.22 domain then provides a description of the ECM v2.22 application model for the domain. Section 4 - Re- engineering the domain a description of the re-engineering into the BORO frame- work. Section 5 - Extending the ECM v2.22 domain describes an extension of the -- 13 of 146 -- MC1-6 2 The selected domain What is Pump Facility PF101? BORO domain of the ECM v2.22 application model to include the component of relation and Section 6 – Re-engineering the extended domain describes the re-engineering of this. The final Section 7 – The Case Study, very briefly summaries the results of the case study. 2 The selected domain EPISTLE has a well-established tradition of using pumps in their examples – in particular, pump facility PF101 . We follow this tradition and consider an offshore oil drilling rig (from now on shortened to ‘oil rig’) that has a pump (facility), PF101, specified as a component. 2.1 The context Offshore oil rigs are large, expensive and typically built to order for use in a partic- ular place. When designing a particular new oil rig, the design engineers specify the components, such as a pump4, needed to construct it. And they give them reference numbers, known as tag numbers, to identify them. When the oil rig is constructed a pump meeting the specified requirements is pro- cured and installed. This pump will typically have been constructed at a factory to the manufacturer’s specification for that type of pump – and allocated an identi- fying serial number. Once the oil rig is put into operation, it is usually operated by an operator, and maintained by a maintainer. This operator thinks and works with the tag number allocated by the designer. Whereas the maintainer thinks, like the manufacturer, in terms of a manufacturered pump with a manufacturer’s serial number. This gives us two views of a pump: 4. In practice the specification often stipulates a requirement for a number of pumps – one to be actually installed and the others kept as back up. Here we simplify things and assume that only one pump is specified and actually installed. -- 14 of 146 -- MC1-7 BORO 2.2 The domain What is Pump Facility PF101? • The designer and operator see the pump as a component of the oil rig (the designer actually specifies it as a component and allocates it a tag number). • The manufacturer and maintainer see both the original pump installed in the oil rig and its replacement as things that have been made in a factory and installed in the oil rig. From now on we will call these the designer/operator’s and the manufacturer/ maintainer’s views. 2.2 The domain We start by taking as our initial domain a situation to which these two views can be applied. We consider the pumps that exist in the simple situation where a maintenance engineer replaces an oil rig’s pump – or, put another way, where he or she takes the original pump out of the oil rig and replaces it with the new one. To make it easier to talk about them, we name the pumps identified in these views. In hallowed EPISTLE tradition, we give the designer/operator’s pump the tag no. PF101. We take the manufacturer/maintainer’s pumps as having serial numbers XYZ1234 and XYZ5678, respectively. 2.3 The challenge It may seem that all we have here is a situation where the same term ‘pump’ is used (by the different groups of people, with different interests) in two different senses. That all we need to do to harmonise understanding is to provide a description of what the designer/operator and manufacturer/maintainer mean – in effect, what their pumps are, and how they differ. 2.3.1 A seemingly innocent assumption But this makes the seemingly innocent assumption that since the designer, oper- ator, manufacturer and maintainer know what they mean sufficiently well to do their job, that this is sufficient for building these ‘meanings’ into a formal frame- -- 15 of 146 -- MC1-8 2 The selected domain What is Pump Facility PF101? BORO work. What the EPISTLE engineers found is that this is not so. They had to work quite hard even to develop a reasonably consistent way to explain what the two senses of pump are within an overall framework. If we examine why this is such hard work, we find it is due to a lack of a clear answer to an ontological issue: What kinds of things are the two senses used to describe? 2.3.2 The core ontological issue To appreciate this issue consider the following situation, that unfolds in three stages. 1 Consider a meeting where we show representatives from the operator and the maintainer around the oil rig and ask them to point to their pump (PF101 and XYZ1234, respectively). They clearly point to the same thing, a pump installed in the oil rig. Questioning does not seem to reveal any discrepancy. For example, they agree on the pump’s operating characteristics – such as flow rate, head and power. It would seem as if they are just using different names – tag PF101 and serial no. XYZ1234 – for the same thing. It seems tempting to say that the maintainer and operator’s pumps are the same thing. Currently some engineering computer systems even insist that they are effectively the same 5 : the pump referred to by its tag no. is given the characteristics of the manufacturers pump that is chosen as the first for the job. This is a natural, intuitive, interpretation of the situation. 2 An hour later, a maintenance engineer changes the pump. 3 Two hours later, the same representatives are taken to the same place on the oil rig. A simple question now reveals a problem. If we were to ask them whether this pump was the same as the one they saw a couple of hours ago, then they would give different answers. From an operator’s point of view it is the same – it is the same component of the oil rig, with tag no. PF101. From the maintainer’s point of view it is clearly different; it has a different serial number, XYZ5678, and it was made at a different time and place from the earlier pump (serial number XYZ1234). The logic of this argument now tempts us to say that the maintainer and operator’s pumps are different things. But here logic leads us to the counter-intuitive conclusion that two different pumps are in the same place at the same time. Where, when we touch the pump, 5. I am indebted to Jan Sullivan of POSC-CAESAR for this point. -- 16 of 146 -- MC1-9 BORO 2.3 The challenge What is Pump Facility PF101? we are touching two pumps even though it feels like one. We need to explain what is hopefully only an apparent contradiction - why: When faced with the pump our intuition seems to tell us there is only one pump there in front of us, but When considering the situation before and after the replacement, logic seems to tell us that, in each situation, there are (apparently) two different pumps there, in exactly the same place. 2.3.3 Can two things be in the same place at the same time? Pumps with tag numbers and/or serial numbers may be relatively new, but the problem faced here is ancient. It is an age-old philosophical (ontological) conun- drum usually captured in the question: can two things exist in the same place at the same time?6 It is important to recognise that the problem is not academic, but a practical commonsense one that the engineers working on ECM v2.22 intuitively recog- nised as they were building their framework. What forced it to their attention was need for clarity in the specification of that framework. And for them it was a serious practical problem. If their specification was inconsistent, then it could not serve its purpose as a framework for storing and automatically exchanging information. The engineers needed a solution. 3 Analysing the ECM v2.22 domain We illustrate the implications of ECM v2.22’s solution by constructing an exam- ple application model. This highlights the EPISTLE engineer’s concerns, which then provide a motivation for the BORO re-engineering. This we do, first at the individ- ual level and then at the upper levels. 6. It can be traced back to one of the oldest questions in philosophy raised by the Ancient Greek Heraclitus of Ephesus in the 5th Century BC who asked “can we step into the same river twice”. The river’s water changes much as the designer’s pump changes manufacturer’s pumps. -- 17 of 146 -- MC1-10 3 Analysing the ECM v2.22 domain What is Pump Facility PF101? BORO 3.1 The ECM v2.22 application model To give a context for the construction of the application model – we start by look- ing at the general approach taken by ECM v2.22 towards solving the ontological issue. 3.1.1 ECM v2.22’s solution to the ontological issue The EPISTLE engineers spent a lot of time thinking about this issue – though they understandably did not think of it as an ontological issue, more as a modelling problem. They tried out a number of options in their search for a solution. By the time ECM v2.22 was issued, their proposed solution was to make an absolute dis- tinction between two types of thing. They suggested that the manufacturer/ maintainer’s pump is a physical thing and the designer/operator’s pump is a logi- cal thing (more specifically a facility, which is a subtype of functional thing, which in turn is a subtype of logical thing) where physical and logical things are quite dis- tinct (these subtypes can be seen in Appendix D’s Figure MC1–0.1). The relation- ship between the two is that the physical manufacturer/maintainer’s pump is installed in (and deinstalled from) the designer/operator’s pump facility. Effectively ECM v2.22’s answer to the question - “Can two things be in the same place at the same time?” - is a limited ‘yes’. It says: a physical thing and a logical thing can be in the same place at the same time – but they are there in a different way. In the situation that gave rise to the question, the manufacturer/main- tainer’s pump is physically and the designer/operator’s pump logically there. And for things like pumps, these are the only two ways in which they can exist – and so co-exist in the same place at the same time. EPISTLE’s engineers’ intuitive concerns This solution ‘worked’ well enough, though it required some odd workarounds. But, some of the EPISTLE engineers were not really satisfied. They felt that a number of their intuitive concerns – particularly with regard to the status of logical objects – indicated that they were missing some important opportunities to improve the framework. All in all they felt that this solution was not sufficiently ‘right’ for what they needed to do. The nature of these concerns will become -- 18 of 146 -- MC1-11 BORO 3.1 The ECM v2.22 application model What is Pump Facility PF101? clearer after we construct the application model for our example – which we start doing now. 3.1.2 Constructing the application model We follow the normal BORO approach and start our analysis with individuals (in ECM v2.22’s term’s instances – that is, belonging to the instance subtype - not entity instances, which are something different). This means we build the applica- tion model from the bottom up, starting with the individuals then moving onto the individual’s relations with other individuals (in ECM v2.22’s term’s associa- tion instances) and finally – in the next section – taking in the more general classes. The individuals As explained above, the ECM v2.22 tactic for resolving the ‘two pumps or one’ issue is an absolute distinction between physical things and (logical) facilities. This means that in its ontology the different types of pumps fit under the dis- tinct physical and logical things subtypes on the subject dimension of its frame- work. The designer/ operator’s pump The designer/operator’s pump is a pump facility, tag number PF101, fitting under the subtype, logical thing. Following ECM v2.22’s rules that each entity must belong to a subtype from each of its framework’s dimensions, PF101 fits under the logical (subject), instance (instantiation), actual (life-cycle), real (reality) thing entity subtypes. We are not interested in the life-cycle and reality dimen- sions in this example, so we ignore them from now on. For various reasons7, ECM v2.22 uses two types of ‘instantiation’ – the EXPRESS ‘instance of’ relation and the ECM v2.22-defined ‘class-member’ asso- ciation. Typically both of these are used when ‘fitting’ instances, such as PF101, into the framework. 7. The principle reason is that EXPRESS language does not directly support classes of classes. The class sub-type and the class-member association are a work-around that enables EPISTLE to have classes of classes. However it introduces an issue about the nature of entities such as facility. Is it a class whose instances are facilities – or a class of classes of facilities? However these questions are outside the scope of this paper. Note, however, that BORO only has a single ‘instantiation’ (class-member) relation, and so avoids these problems. -- 19 of 146 -- MC1-12 3 Analysing the ECM v2.22 domain What is Pump Facility PF101? BORO So PF101 is, firstly, an instance of two entity types - specific thing and facility. This tells us that PF101 is a specific facility. PF101 is, secondly, a member of the pump facility class (this necessitates ‘introducing’ the pump facility class for it to be a member of). This tells us it is a pump facility. Together they tell us PF101 is a specific pump facility. The model in Figure MC1–18 below gives us a picture of this. Figure MC1–1 Pump facility PF101 Using two types of instantiation here leads to some duplication - as both types tell us PF101 is a facility. This creates the possibility of a contradiction, where something is classified under different, mutually exclusive, subtypes by the two types of instantiation. This is avoided by the ECM v2.22 principle that “[t]he clas- sifier and member must both be of the same subject subtype”9 – in this case ensuring that both the pump facility class and PF101 belong to the same subject type – facility10 . 8. This, like all the other EPISTLE figures in this paper, uses the EXPRESS-G notation extended to handle instances of entities 9. §6.5.5 Classification, EPISTLE Framework V2.22. 10. Architectually this duplication indicates that the distinctions in the framework do not quite align up with what they are going to describe. However, much of the unnecessary structure here is a result of the less than satisfactory EXPRESS language (which EPISTLE had to work within) rather than a result of the engineer’s analysis. classification facility class specific classification association INSTANTIATION SUBJECT specific facility functional thing logical thing facility pump facility PF101 pump facility classification PF101 instance class of thing specific thing association classifer member member classifer thing 1 1 1 -- 20 of 146 -- MC1-13 BORO 3.1 The ECM v2.22 application model What is Pump Facility PF101? The manufacturer/ maintainer’s pumps There are two manufacturer/maintainer’s pumps; the original physical pump, serial number XYZ1234, and the new physical pump, serial number XYZ5678. ECM v2.22 fits these into its framework in an analogous way. They are instances of the physical and specific thing subtypes – and members of the physical pumps class. The result is modelled in Figure MC1–2 below. They also ‘fit’ under the actual (life-cycle), real (reality) thing entity sub-types – in ECM v2.22’s other two dimensions – but, as mentioned before, we ignore these here. Figure MC1–2 Physical pumps XYZ1234 & XYZ5678 It is worth noting in passing that the ECM v2.22 framework does not allow a sin- gle ‘pump’ class to be constructed with both physical pumps and pump facilities as members. It ‘forces’ you to have separate physical and logical classes for each of them. (This is not as clear as it could be because we have modelled the two classes in separate diagrams.) This counter-intuitive restriction is a result of the rule mentioned above where classifier and member must belong to the same sub- type and its use of separate physical and logical subtypes11. 11. This is a simple example of how trying to make clear general distinctions can have obviously counter-intuitive unintended results. In the BORO analysis the pump class returns. classification INSTANTIATION SUBJECT instance class of thing specific thing association classifer member thing 1 1 1 physical thing class specific classification association specific physical thing physical thing XYZ5678 pump classification physical XYZ5678 physical pump XYZ1234 XYZ1234 classification physical pump member classifer member classifer -- 21 of 146 -- MC1-14 3 Analysing the ECM v2.22 domain What is Pump Facility PF101? BORO The installation associations Figure MC1–1 and Figure MC1–2 show the three individuals (in ECM v2.22 terms, specific instances – excluding associations) in our example – PF101, XYZ1234 and XYZ5678. We now need to specify how these are related (in ECM v2.22’s terms, the specific instances of associations that relate them). At this stage the only (sub)type of association in our scope is installation. And there are only two associations: physical pumps XYZ1234 and XYZ5678 both have, at different times, an installation association with pump facility PF101. Activities beginning and ending associations Within ECM v2.22, associations typically have life spans, and in recognition of this activities are used to mark an association’s beginning and ending12- and so its lifespan. This is needed for the installation associations, which only last for a fixed period of time. They are ‘begun’ by an install activity and ‘ended’ by a dein- stall activity. The PF101 installation associations PF101’s installation activities help to make its associations clear. The original pump XYZ1234 underwent an install activity that began an install association between it and pump facility PF101, and undergoes a deinstall activity that ends this association. Then the new pump XYZ5678 undergoes an install activity that begins a new install association between it and pump facility PF101. We start by modelling these two installation associations in Figure MC1–3 below: • Physical pump XYZ1234 has a specific installation association with PF101, and • Physical pump XYZ5678 has a specific installation association with PF101. 12. “An association has a lifetime during which the association is a valid one. Conceptually, the start and end points of the lifetime of an association are defined by the activities that bring the association about and terminate it.” §4.3 Association, EPISTLE Framework V2.22 . -- 22 of 146 -- MC1-15 BORO 3.1 The ECM v2.22 application model What is Pump Facility PF101? Figure MC1–3 Pump specific installation associations The activities We now consider the activities. There are two types of activity: installation and construction. We first consider the installation activities associated with the installation associations. Then we look at the construction activities, which have no associated associations. PF101’s installation associations’ install and deinstall activities The two installation associations in Figure MC1–3 each have their own install and deinstall activities, to mark their lifespan – giving us these four activities: • Install XYZ1234/PF101, • Deinstall XYZ1234/PF101, • Install XYZ5678/PF101, and installation specific pump facility specific installation association INSTANTIATION SUBJECT 1 1 functional thing logical thing facility PF101 PF101 installation XYZ1234 PF101 installation XYZ5678 XYZ1234 XYZ5678 instance association thing physical thing installable service specific physical pump installable installable service service specific thing -- 23 of 146 -- MC1-16 3 Analysing the ECM v2.22 domain What is Pump Facility PF101? BORO • Deinstall XYZ5678/PF101 We keep the model simple by excluding a couple of things. Firstly, replacement activities, which are just a deinstall activity followed by an install activity13 . Sec- ondly, the event effects (a subject subtype) that ECM v2.22 normally uses to link the start and end activities directly to their association. This means that in our model the activities are indirectly linked to the association via the things that participate in it – as can be seen in Figure MC1–4 below. Figure MC1–4 Pump facility PF101 installation activities 13. “We would expect to have a pair of activity entity types corresponding to each association entity type. In addition, many associations have an additional activity entity type that combines the effect of the previous two activities into a single activity (or transaction).” – §4.4 Activity, EPISTLE Framework V2.22 instance SUBJECT thing service specific thing 1 activity installation activity install deinstall installation association service physical thing service logical thing INSTALLATION 1 PF101 XYZ1234 installable installable service service installable installable service service installable install XYZ1234 PF101 deinstall XYZ5678 PF101 XYZ5678 XYZ1234 installation PF101 XYZ5678 installation PF101 installable installable installable installable service service install XYZ5678 PF101 deinstall XYZ1234 PF101 specific installation activities specific physical pumps/ pump facility specific installation associations facility -- 24 of 146 -- MC1-17 BORO 3.1 The ECM v2.22 application model What is Pump Facility PF101? Physical pumps construction activities For the BORO re-engineering it will help to have a model that marks out the extent of the lives of the physical pumps – their beginnings and endings. We can consider the activity that begins their lives (following a hint in EPISTLE Framework V2.2214) as a construct activity in a factory composed of a series of (ECM v2.22) assemble activities – one for each part, which ‘begins’ an assembly association between the pump and the respective part. Similarly the activity that ends their lives would be a dismantling activity composed of a series of disassemble activi- ties – ‘ending’ the assembly associations. For the sake of simplicity, we just model the overall construction activity, with construct and dismantle subtypes – without concerning ourselves with the series of assemble and disassemble activities of the individual parts or their assembly associations. This gives us these four construction activities: • Construct XYZ1234, • Dismantle XYZ1234, • Construct XYZ5678, and • Dismantle XYZ5678. These are shown in Figure MC1–5 below. 14. “In addition, … an additional activity entity type that combines the effect of the previous two activities into a single activity (or transaction).” §4.4 Activity, EPISTLE Framework V2.22. -- 25 of 146 -- MC1-18 3 Analysing the ECM v2.22 domain What is Pump Facility PF101? BORO Figure MC1–5 Physical pumps construction activities ECM v2.22’s ontology of individuals We now have a sufficiently complete picture of the application. There are eleven specific things in the ground level ontology – diagrammed in Figure MC1–6 (below). These are the things that ground the example in ‘reality’ and which the BORO re- engineering will take as its starting point. To help us focus this analysis, we now clarify the intuitive concerns that the engineers using ECM v2.22 had with this ontology. instance SUBJECT thing specific thing 1 activity construction activity construct dismantle physical thing INSTALLATION 1 XYZ1234 construct XYZ1234 dismantle XYZ5678 XYZ5678 construct XYZ5678 dismantle XYZ1234 specific construction activities specific physical pumps assembles disassembles assembles assembles disassembles disassembles -- 26 of 146 -- MC1-19 BORO 3.2 EPISTLE engineers’ intuitive concerns What is Pump Facility PF101? Figure MC1–6 The example’s ground level ECM v2.22 ontology 3.2 EPISTLE engineers’ intuitive concerns The engineers using ECM v2.22 had a number of commonsense concerns about this way of characterising their world – easily expressed in simple questions, such as: When the physical pump XYZ1234 is pumping, what is the logical facility PF101 doing? Or even more basically: When I touch physical pump XYZ1234, am I also touching logical facility PF101? These show how intuitively clear it is that the pump facility and the physical pump are inter-related in all sorts of ways - much more than just their install and de- install activities. The root of the engineers’ unease seems to be the lack of a clear physical pumps XYZ1234 installation PF101 XYZ5678 installation PF101 XYZ1234 XYZ5678 PF101 service service installation associations deinstall XYZ1234 PF101 install XYZ1234 PF101 deinstall XYZ5678 PF101 install XYZ5678 PF101 installable install activities dismantle XYZ5678 construct XYZ5678 dismantle XYZ1234 construct XYZ1234 construction activities service service service service pump facility installable installable installable installable installable disassembles assembles assembles disassembles -- 27 of 146 -- MC1-20 3 Analysing the ECM v2.22 domain What is Pump Facility PF101? BORO explanation of these inter-relations, in the context of the overall absolute physi- cal/logical distinction. These can be seen as a lack of a clear structural, architectural (ontological, even) framework for the relationships between physical and logical objects occupying the same place (i.e. co-extensive) and: • the properties they have, • the activities they participate in, and • the parts they have. We examine these now. 3.2.1 Co-extensive things’ properties One of the basic ways in which two co-extensive pumps are related is by their properties. The two pumps share many of the same types of properties. And when a physical pump is installed in a pump facility (and so they become co-exten- sive), they necessarily have many of the same properties – e.g. the same height, the same weight. ECM v2.22 effectively offers little in the way of explaining how properties are related in general. In its model, Properties are a subtype of Characteristic, which is a different subject type from Physical and Logical Object (you can see this in Appendix D’s Figure MC1–0.1). In its terms, any ‘Thing’ can have a ‘Possession Association’ with any type of ‘Characteristic’15 – and there is no division of Char- acteristic or Property into physical and logical. There are no general constraints on properties and their relationship to Physical and Logical Things. To understand the nature of the engineers’ concerns it is worth examining the options for providing a better explanation within ECM v2.22’s absolute physical/ logical distinction. 15. A thing may possess specific characteristics, modelled by a possession of characteristic association linking the characteristic(s) to the thing(s) possessing them. … Note that the thing being described by … possessing a characteristic may be of any subject subtype.” §7.2 Activity, EPISTLE Framework V2.22 . -- 28 of 146 -- MC1-21 BORO 3.2 EPISTLE engineers’ intuitive concerns What is Pump Facility PF101? Distinguish- ing physical and logical properties - I At the architectural level, one of the first things that needs to be clarified is whether the absolute physical/logical distinction extends to properties. One could stipulate that there are distinct physical and logical versions of many properties. But when we consider properties, like tangibility and visibility, which seem particularly physical, this does not seem viable. In fact, it seems just con- tradictory to talk about logical tangibility and logical visibility. Anyway, even if we were to find a satisfactory way of explaining how there are dis- tinct physical and logical versions of properties – and so creating parallel physical and logical worlds of objects and their properties – we would be no closer to explaining the relationships, including necessary sameness, between the proper- ties of co-extensive physical and logical objects. So the option of extending the distinction to properties is unattractive. It seems intuitively wrong and provides no answers to our question about the inter-rela- tionship of the properties. Distinguish- ing physical and logical properties - II The physical/logical distinction may apply to properties in another way. It may be that instead of there being different physical and logical versions of properties (as there are pumps), that some properties are irredeemably physical or logical. This seems to be the case with ‘physical’ properties, such as tangibility and visi- bility. It seems intuitively obviously that these can only be properties of physical things. Surely if something is tangible and visible, it is physical. The issue then arises whether logical things can have ‘physical’ properties . Could a logical pump be ‘physically’ visible and tangible? If we say yes, this raises more questions. Presumably it would be seen and touched in the much the same way as the physical pump? In fact, whenever we actually see or touch one, we would do so in exactly the same way. We can only see and touch a pump facility when it has a physical pump installed, so seeing and touching a logical pump involves seeing or touching a physical one – though not obviously vice versa. -- 29 of 146 -- MC1-22 3 Analysing the ECM v2.22 domain What is Pump Facility PF101? BORO But there is the inter-relationship between the pumps’ properties to explain. Why do a pump facility and its installed physical pump necessarily have the same prop- erties? Maybe the two pumps are sharing their tangible property – that is, there is one tangible property that they both have (to confirm this it would be helpful to have a criteria of identity for properties). But, if so, how does this work? What happens to this shared property when the physical pump is deinstalled? These considerations may make the option of restricting physical properties to physical objects attractive. But this option has its own problems – especially for things like pump facility PF101 that we ‘naively’ think we can see and touch (and occupies space and time). If logical things cannot have these types of physical properties, how do we know about them? What happens if we cannot, in principle, see and touch (or otherwise perceive) the logical pump PF101 (if only the physical pump has the property of being visible and tangible)? In trying to interpret ECM v2.22, we are torn between a notion of logical object that precludes physical properties and the need to explain how we experience things such as pump facilities. And the framework, as it was constructed, does not give us an answer. What is logical existence? This is closely related to another intuitive discomfort felt by the engineers. They wondered what happens to pump facility PF101 in the gap between the deinstalla- tion of physical pump XYZ1234 and the installation of physical pump XYZ5678. Does it carry on existing? And on what basis should they make the decision? If the logical pump has no obvious physical properties, then these cannot be the basis for establishing whether it exists. One option to consider might be that the existence of PF101 depends upon the existence of an installed physical pump. But, it seems odd that the existence of a logical thing like PF101 should rely on the existence of a physical thing – and different physical things at different times. As PF101 is a logical object, surely there is no reason why it should not carry on exist- ing. But if it does carry on existing, what does this mean? Does it keep its char- acteristics (such as weight and RPM) from before the deinstallation? The answer is not clear. -- 30 of 146 -- MC1-23 BORO 3.2 EPISTLE engineers’ intuitive concerns What is Pump Facility PF101? It is also unclear when PF101 starts to exist. Some engineers thought that it started the moment the design engineer wrote it into the specification. But this account faces the same problems of explaining the pumps’ characteristics when there is no physical counterpart. It also seems to confuse the existence of a con- cept (or sign) for something with that thing’s existence. An analogy with physical pumps makes this clearer. An individual physical pump is named (and so specified) when the factory making it includes its production on its schedule. At this stage a concept (sign) for the physical pumps exists, but not the actual physical pump. The engineers’ standard properties It might seem intuitively attractive to make obviously physical properties, such as tangibility and visibility, only apply to physical pumps. But our intuitions are less clear about what constraints there are on the engineers’ – less obviously ‘physical’ – standard properties. How are the engineers’ standard ways of characterising a pump to be applied to the different types of object? Should one or both of the pumps have a RPM? Or a weight? Initially it seems that we should say both, as both the manufacturer and the designer give these characteristics to their pumps. But then we have a prob- lem. Are there two different – but the same – weight properties and two different – but the same – RPM properties? And why do they have to be the same, why can’t they be different? Can the necessity for their sameness be explained by there being only one weight property shared by both pumps? And if so, what hap- pens to this property when the physical pump is replaced? These properties suffer from the same structural, architectural problems as the more physical properties. The absolute physical/logical distinction may help to explain the ‘two things in one place’ puzzle for objects such as pumps. But by legitimising two distinct things in the same place, it creates a need to explain the necessary sameness of many of their basic properties – which it does not sat- isfy. And if would be helpful to know whether the properties were merely the same in some relevant respects or actually identical – something a criteria for identity of properties could help us establish. -- 31 of 146 -- MC1-24 3 Analysing the ECM v2.22 domain What is Pump Facility PF101? BORO 3.2.2 Co-extensive things’ activities As mentioned earlier, it is not just properties that need to be explained. The activities that co-extensive physical and logical things participate in also need a framework. This has been done for some activities – install, deinstall, construct and dismantle have a framework within which the roles of physical and logical pumps are explained. But these are ones where the activities are not ‘shared’. For ‘shared’ activities there is no general framework – and here we come across the same structural, architectural problems that we found for properties. One of these was particularly immediate for the EPISTLE engineers. It relates to the ubiquitous pump – and its main activity, pumping. Designers and operators design and operate pump facilities that pump. Manufac- turers and maintainers produce and maintain physical pumps that pump. So pumping does not seem to be restricted to physical or logical pumps. ECM v2.22 supports this - Activity is a different subject type from Physical and Logical Object (you can see this in Appendix D’s Figure MC1–0.1) – and not subject to any physical/logical distinction16. But this suffers from the same intuitive puzzle as the co-extensive pumps and their properties – and gave the engineers similar intuitive concerns. There is a need to explain why the co-extensive pumps have to participate in the same activities. There is a further question about whether they are participating in two similar activities – or one. When a pump facility is pumping, the physical pump installed is necessarily also pumping. Are there two pumping activities or one? (Note that a criterion of identity for activities would help us answer this.) There is also the conceptual problem of explaining how the pump facility, which is classi- fied as logical, can undertake a pumping activity that appears indubitably physi- cal. 16. Though activities may not be characterised as physical or logical, as mentioned earlier, ECM v2.22 does implement some specific constraints on whether (and how) physical and logical things can participate in some types of activity – e.g. only a physical thing can be installed by an install activity. -- 32 of 146 -- MC1-25 BORO 3.2 EPISTLE engineers’ intuitive concerns What is Pump Facility PF101? There is also the twist that some activities, such as install and deinstall, happen to both the physical and logical pump, but affect them in different ways. A dein- stall may only involve disconnecting a physical pump – but ‘destroys’ the physical existence of the logical pump facility. 3.2.3 Co-extensive things’ parts As well as the co-extensive physical and logical things’ relations to other types of thing (properties and activities), there are its relations to the same two types of things – in particular, the physical and logical things that are its parts. The physical pump clearly has things such as nuts, bolts, pistons, and so on as parts – and these seem physical. But does the logical pump have parts? It would seem that this is possible, as the designers of oil rigs sometimes specify the components of the pump. And it would seem that these parts are logical. And these physical and logical parts would seem to be co-extensive – as their wholes are. ECM v2.22 takes this view. It stipulates that parts have to be of the same entity type as the whole. The parts of a logical pump are also logical – the parts of a physical pump, physical. It is impossible for logical and physical objects to share parts. Taking this to its ‘logical’ conclusion, we can imagine a parallel logical uni- verse, exactly mimicking its physical counterpart, part for part, atom for atom. While the parallel logical universe may seem counter-intuitively over-populated, less simple strategies, bound by ECM v2.22’s overall framework, lead to the need for more sophisticated and complex solutions. For example, if one allows physical and logical things to share parts – presumably physical parts – one needs to explain when and how a collection of physical pump parts compose a logical pump (and, presumably, that they can only compose one logical pump at a time). The answer cannot be ‘always’ as the physical parts of a manufactured pump do not always compose a pump facility. In particular, we need to explain why they do when they are installed in a pump facility. -- 33 of 146 -- MC1-26 4 Re-engineering the domain What is Pump Facility PF101? BORO 3.2.4 Similar puzzles, suggesting a common solution The engineers intuitive concerns were motivated, in part, by a desire for a reason- ably complete and consistent story about what is going on. Where an explanation of one area (objects), was consistent with what happened in other areas (proper- ties, activities and parts). ECM v2.22’s lack of a completely convincing story shows how difficult it is to find one – the EPISTLE engineers tried very hard Hopefully, the analysis is also beginning to show the interconnectedness of our conceptual frameworks. How adopting a structure in one area influences related areas. How adopting a structure that allows two things to be in the same place at the same time, creates a need for an explanation on how to relate their proper- ties, activities and parts. The similarity of the puzzles in the different areas and their structural, architec- tural nature suggests the possibility of a single overall solution. This is the goal of the BORO re-engineering. 4 Re-engineering the domain 4.1 Re-engineering the individuals The purpose of BORO’s re-engineering is to provide the engineers with a better – in the sense of more intuitive as well as simpler and more fruitful - story about what is going on. This, as we shall see in this section, starts with a better story of what the individuals are. 4.1.1 Grounding the analysis It is important that the analysis has as strong a grounding as possible. The BORO categories differentiate the types of thing by the way they are grounded, and so provide a good basis for ordering the analysis. Individuals, which are -- 34 of 146 -- MC1-27 BORO 4.1 Re-engineering the individuals What is Pump Facility PF101? directly grounded are analysed first; then the tuples that are grounded in individ- uals; and finally classes, which are grounded in individuals, tuples (and classes). In each case, we take the criterion of identity, which characterises the grounding, as our starting point for the re-engineering. BORO has such a criterion, but ECM v2.22 does not provide us with much of one – as explained below, particularly for individuals. So the analysis is more about determining how to apply this criterion then re-interpreting EPISTLE’s. ECM v2.22’s criterion of identity for individuals Discussions with the EPISTLE team and a careful reading of EPISTLE Framework V2.22 seems to show that it has no explicit identity criterion for individuals (in its terms, instances). It has something much closer to an identity criterion for classes. For example, class and individual are described in EPISTLE Framework V2.22 ’s Sec- tion 5.1 – Instantiation as follows: “Associated with an entity type is a qualifier which tells us whether an entity of that type is describing an instance of some thing or the type of thing it is. Class - a set of its members. A class is defined by a set of criteria that determine, for any thing, whether that thing is or is not a member of a class. For example centrifugal pump is a class because it is concerned with a type of equipment rather than an individual instance of that type. Anything that is not a class is an instance:- Specific - an individual occurrence of something, for example a pump with a specific serial number. … [‘Typical’ left out, as not relevant here]” How do we tell whether two descriptions of a (specific) instance are of the same instance or different ones? This passage clearly has no criterion of identity to help us. The description of classes is better, but it is insufficiently clear to pro- vide a criterion of identity. It mentions a set of criteria, but does rule on whether different sets of criteria necessarily lead to different classes? For example, if you have a class criterion of ‘ triangles having three equal sides’ and another of ‘triangles having three equal angles’ do these define the same class or not? (It -- 35 of 146 -- MC1-28 4 Re-engineering the domain What is Pump Facility PF101? BORO can be shown mathematically that all triangles meeting either one of the criteria also meet the other.) EPISTLE Framework V2.22 does not tell us. It would be unfair to ‘criticise’ ECM v2.22, as it is an example of good or even best practice in this area. Most ‘standards’ for