UNIFICATION OF TYPES AND MULTI-LEVEL MODELING: Introduction - IS UNIFICATION OF TYPES AND MULTI-LEVEL MODELING KCL, 13 th March 2024 Chris Partridge (BORO Solutions and University of Westminster) Caveat 2 The syntactic view that a theory is an axiomatized collection of sentences has been challenged by the semantic view that a theory is a collection of nonlinguistic models, and both are challenged by the view that a theory is an amorphous entity consisting perhaps of sentences and models, but just as importantly of exemplars, problems, standards, skills, practices and tendencies. (Savage 1990, vii–viii) Savage, C.W., 1990, “Preface,” in Scientific Theories. Minnesota Studies in the Philosophy of Science. Volume 14, C.W. Savage (ed.), Minneapolis: University of Minnesota Press, pp. vii–ix. From Winther , Rasmus Grønfeldt , "The Structure of Scientific Theories", The Stanford Encyclopedia of Philosophy (Spring 2021 Edition), Edward N. Zalta (ed.), URL = < https://plato.stanford.edu/archives/spr2021/entries/structure-scientific-theories/ >. Scientific theories may be pragmatic, but Information systems (IS) is very much a pragmatic, engineering discipline . Syntax and semantics are interesting in as much as they make a practical difference to the systems’ purpose. Interesting question is: what elements of syntax and semantics make a difference? There will be all sorts of inter-disciplinary term collisions – e.g. ‘domain’. I’m aiming to stick to IS terminology – with occasional hazard warnings for logicians. Aim Give an overview of how the unification of types could fit into IS To provide the basis for making a connection between the work in logic and IS 3 Structure The evolution of Information System (IS) architectural style Mainstream data architectural style Emerging (practical) requirement Emerging hierarchy data architectural style Emerging ‘agile’ data architectural style Agile architectural style implementations Pragmatic development life cycle Developmental innocence and unification More ‘lifting the veil’ Summary 4 The evolution of Information System (IS) architectural styles What is an IS data architectural style? “Patterns used to structure, describe, and govern the data within Information Systems (IS)” More specifically focus on: a technology/language ways to use (or not use) the (structure embedded in) the technology/language (such as tables in relational databases) to represent the domain (the universe of discourse) 6 Ways of creating a semantic dependency upon syntax 7 A common tendency in architectural styles is, having selected a technology/language, (post-hoc) rationalising its explicit syntactic structure as the semantic structure. This creates a dependency between the ‘data’ syntax and the semantics. Where the technology/language is levelled, the tendency exhibits itself by taking the language’s inter-strata relations as a type-instance relation. An alternative tendency, when the designer assumes a levelled ‘type’ semantics is to try and design this view into a levelled technology/language. One whose syntactic structure accommodates the designer’s view of the levelled ‘type’ semantics. This, however, builds in (freezes) the designer’s type semantics into all applications built using the technology/language. Major evolutionary transitions (simplified) {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} data architectural style name structure ‘data’ syntax semantic dependency mainstream two category uses the syntactic structure emerging hierarchy multi-category uses the syntactic structure emerging agile two category pushed down into the rows e merging hierarchy emerging agile In the simplified picture: three styles, two transitions We characterise each style’s structure in two ways: ‘data’ syntax and (type) semantic dependency (on the syntax) Maynard Smith, John and Eörs Szathmáry , 1995, The Major Transitions in Evolution (Simplifications include ignoring graph, non-SQL, document, key-value pairs structures) mainstream 8 Mainstream data architectural style ‘data’ syntax: two category semantic dependency: uses the syntactic structure Mainstream data architectural style {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Table Row Category {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} name structure ‘data’ syntax semantic type mainstream two category uses the syntactic structure See : Maley , Corey J. 2023. ‘ Icons , Magnitudes, and Their Parts ’. doi : 10.22201/iifs.18704905e.2023.1411. See also later in more lifting the veil section : fn 2 in Linnebo , O., and A. Rayo. 2012. ‘Hierarchies Ontological and Ideological. doi : 10.1093/mind/fzs050 10 Note: this relation is implied by the ‘mereology’ of the table. Example: architectural style Partridge, C., Cesare, S. de, Mitchell, A., & Odell, J. (2016). Formalization of the Classification Pattern: Survey of Classification Modeling in Information Systems Engineering. https://doi.org/10.1007/s10270-016-0521-5 Category {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Leopard Sabor {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Tiger Shere {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Lion Aslan {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Table Row Architectural Style: rough rules of thumb: Use a table to represent the ‘kinds’ of thing in the domain Use a row in the table to represent the things Use the syntactic table-row structure for type-instance semantics 11 Extending the domain Partridge, C., Cesare, S. de, Mitchell, A., & Odell, J. (2016). Formalization of the Classification Pattern: Survey of Classification Modeling in Information Systems Engineering. Software & Systems Modeling , 1–37. https://doi.org/10.1007/s10270-016-0521-5 Ranks 12 Representing the extended domain {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Leopard Sabor {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Tiger Shere {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Lion Aslan {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Lion-Species Aslan Lion {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Tiger -Species Shere Tiger {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Leopard -Species Sabor Leopard {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Species Lion Tiger Leopard {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Species-Rank Lion Species Tiger Species Leopard Species {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Rank Species Genus Order Issue: Principle: Parsimony The relations have the same sort of formal structure Issue: Principle: DRY - Don't Repeat Yourself Repetition, data redundancy is a data ‘ smell ’ 13 style.visibility style.visibility style.visibility style.visibility style.visibility Emerging (practical) requirement IS recognising a hierarchy of ‘types’ {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Aslan {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Lion {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Species {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Rank Recognises the benefits of generalising the lion-species and species-rank relations as well as the Aslan-Lion relations. A hierarchy of types => higher order types (also known in IS (roughly) as powertypes - https://en.wikipedia.org/wiki/Powertype_(UML)). 15 Higher order types are ubiquitous in IS systems In the 1990s, a number of papers emerged that explicitly drew attention to powersets and their use in classification—most explicitly mentioning the link to the mathematical object, though not always adopting its formal structure. There is a “road to Damascus” theme in the early literature, noting the lack of recognition of powersets in the community and their ubiquity in the domains being represented , for example, Odell [81] (pp. 23, 32) and Henderson-Sellers and Gonzalez-Perez [52]. Partridge, C., Cesare, S. de, Mitchell, A., & Odell, J. (2016). Formalization of the Classification Pattern: Survey of Classification Modeling in Information Systems Engineering. Software & Systems Modeling , 1–37. https://doi.org/10.1007/s10270-016-0521-5 The approach to classification is framed by an aspiration to explain as well as characterize the formal structure. It is a plausible hypothesis that this extra explanatory burden is a contributory factor to the slower adoption of the formal structures in the conceptual modeling communities . 16 In the 1990s, … (power objects) Partridge, C. (1996). Business Objects: Re-Engineering for Re-Use (1st Edition). Butterworth-Heinemann. Odell, J.J.: Power types. JOOP 7 (2), 8–12 (1994) In the 1990s, a number of papers emerged that explicitly drew attention to powersets and their use in classification—most explicitly mentioning the link to the mathematical object, though not always adopting its formal structure. Partridge, C., Cesare, S. de, Mitchell, A., & Odell, J. (2016). Formalization of the Classification Pattern: Survey of Classification Modeling in Information Systems Engineering. https://doi.org/10.1007/s10270-016-0521-5 17 1994 – Early statement of the perceived implementation issue Martin, J., & Odell, J. J. (1994). Object-oriented methods. Prentice Hall PTR. “Implementing powertypes can present challenges …” 18 ‘Multi-Level Modeling ’ (MLM) community https://jku-win-dke.github.io/MULTI2023/ Last year it had its 10 th International Workshop Focuses on how to handle this emerging requirement. 19 MLM’s ontological metamodeling view Atkinson, C., & Kühne , T. (2003). Model-driven development: A metamodeling foundation. Software, IEEE , 20 (5), 36–41. 20 Emerging hierarchy data architectural style First adaption: Change the structure – a structural level for each rank in the hierarchy Shift to multi-category ‘data’ syntax-structure Atkinson, Colin & Kühne , Thomas. (2002). Rearchitecting the UML infrastructure. 10.1145/643120.643123. An example Levels can be finite, can also be unbounded {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} data architectural style name structure ‘data’ syntax semantic type mainstream two category uses the syntactic structure emerging hierarchy multi-category uses the syntactic structure Category {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Level 0 {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Level 1 {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Level 2 {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} … {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Level n {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} … 22 Example: emerging architectural style {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Aslan {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Lion {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Species {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Rank Level 3 Level 2 Level 1 Level 0 Typically, assumes types are ‘pure’ – that the hierarchy is not cumulative. (motivation probably apparent ease of implementation) Architectural style: rules of thumb: Allocate ‘types’ of thing in the domain to the ‘right’ level Build the levels up from individuals at level 0 Use the syntactic structure to connect the levels 23 Emerging ‘agile’ data architectural style Agile shift: same ‘data’ syntax-structure change approach to semantics Agile shift Semantic structure no longer follows the syntactic structure Table becomes just a (syntactic) container for the semantic rows. {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} data architectural style name structure ‘data’ syntax semantic type mainstream two category uses the syntactic structure emerging agile two category pushed down into the rows {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Table Row Category Structure looks the same 25 Example: architectural style Architectural Style: rules of thumb: Represent all things as rows in the model Represent their relations as rows in the model {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Objects Aslan Lion Species Rank {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Type-instance relations Aslan Lion Lion Species Species Rank 26 This is one possible way of implementing. There are many possible ways, ranging from one table to many. Adding the top ontology to the domain 27 {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Objects Objects Type-instances … Top ontology manoeuvre: Add the most general types of things to the domain. A sign of this manoeuvre is when the tables appear to have a corresponding row - as shown in the example below. For the IS community at least, this raises questions about the role of the tables. They seem to be containers, that only acquire semantic properties as a result of their contents. An interesting question: metamodeling versus higher-order types 8.5 Relation between meta- modeling and higher-order types A further closely related topic is the relation between metamodeling and higher-order types (sometimes in this context, higher-order types are called ontological meta- modeling and distinguished from linguistic meta- modeling ). A survey of the formalization of this, and relating the issues to historical discussions, may help to deepen the understanding of the issues. Partridge, C., Cesare, S. de, Mitchell, A., & Odell, J. (2016). Formalization of the Classification Pattern: Survey of Classification Modeling in Information Systems Engineering. Software & Systems Modeling , 1–37. https://doi.org/10.1007/s10270-016-0521-5 Simplifying slightly, this suggests an interesting question: When the types are unified in the domain, what is the role of the language in which the domain is described? 28 Example: predicate logic perspective Many philosophers, including Barry Smith and Jonathon Lowe warn about a rationalisation of predicate logic where the structure of the logic (language) is assumed to reflect the ontological structure [(Smith, B., 2005) (Lowe, 2012) and (Lowe, 2013))]. Smith has made a clear and spirited attack on this stance which he calls ‘ Fantology ’ whose description starts (Smith, B., 2005, p. 1): “this is a doctrine to the effect that the key to the correct understanding of reality is captured syntactically in the ‘Fa’ … of standard first- order predicate logic. Here ‘F’ stands for what is general in reality and ‘a’ for what is individual. Hence “f(a) ntology ”. Because predicate logic has exactly two syntactically different kinds of referring expressions—‘F’, ‘G’, ‘R’, etc., and ‘a’, ‘b’, ‘c’, etc.—so reality must consist of exactly two correspondingly different kinds of entity: the general (properties, concepts) and the particular (things, objects).” it then proceeds to describe how this stance arose in modern philosophy, with a cast of, if not villains, then culprits. It ends making the point that (Smith, B., 2005, pp. 19–20): “Our fundamental idea is that predicates (the standard predicates of first-order logic fantologically conceived) do not represent [‘representing’ here means of course, representing an object in the domain]. … Rather they are what link together variable and constant terms which are those parts of the syntax which do stand for something.” 29 Agile architectural style implementations 2004 - Prescient (possibly) query 1 Introduction Following Codd’s use of first-order logic to formally underpin the relational model of data [4], most formalizations of information modeling approaches restricted their logical foundations to first-order (where quantification is permitted over individuals only, not predicates). This is the case for Entity Relationship (ER) modeling [3], as well as Object-Role Modeling (ORM) and its variants [e.g. 2, 12, 13]. A full formalization of ORM’s fact-oriented (attribute-free) approach to information modeling was first provided in [11], with alternative formalizations supplied later [5, 15]. In contrast, the Unified Modeling Language (UML) [19, 20, 22] introduced the notion of powertypes, whose instances may themselves be types, thus requiring higher-order semantics. There appear to be three main arguments for requiring higher-order types to logically underpin information modeling semantics: to allow one to think of instances of certain categorization types (e.g. AccountType , CarModel ) as being types themselves (as for UML powertypes); to formalize very directly the semantics of flexible data structures where attribute entries may themselves denote sets or general concepts (e.g. object-relational tables in non-first normal form); to allow one to specify business rules that seem to cross levels/metalevels (or ignore level distinctions) in the same model (e.g. the Finance department is responsible for defining the possible values of AccountType ). As the move to higher-order logic may add considerable complexity to the task of formalizing and implementing a modeling approach, it is worth investigating whether the same practical modeling objectives can be achieved while staying within a first-order framework. This paper examines some key issues involved, suggests techniques to maintain a first-order formalization, and also makes some suggestions for adopting a higher-order semantics. The examples are presented in ORM and/or UML notation, but the issues are relevant to all information modeling approaches. Halpin, T.A.: Information modeling and higher-order types. In: CAiSE Workshops (1), pp. 233–248. (2004) “It is worth investigating whether the … objectives can be achieved while staying within a first-order framework.” 31 Agile Example: Adaptive/Dynamic object model “We have noticed a common architecture in many systems that emphasize flexibility and run-time configuration. … We call these systems “Adaptive Object-Models”, The real power in Adaptive Object- Models is that the definition of a domain model and rules for its integrity can be configured by domain experts external to the execution of the program. These systems are important when flexibility and dynamic runtime configuration is needed …” Yoder, J. W. & Johnson, R. (2002). " The adaptive object-model architectural style ". In Working Conference on Software Architecture (pp. 3–27) Johnson, R. E. (1998). "Dynamic object model". Work in Progress. Technically: the level 1 structure still has some semantic/ontic commitment There is no top ontology manoeuvre. But it is a step in the right direction. Note: The implementation is essentially a different way of approach a mainstream style structure. It does not involve any further work on the structure. 32 An early (1990s) example The way attributes mimic logical multiple and dynamic classification can be used to translate an object model onto an entity-oriented database. This is a useful feature because it means that, with some manipulation, an O-O business model can be fully implemented on a traditional entity database—although this gives the database an unusual structure. I normally make use of this feature to build a validation system for the business model on an easy-to-use PC-based entity-oriented database (such as Microsoft’s ACCESS). This means I can test the conceptual correctness of the model before it is translated into the system specification. I find that it saves a lot of time and effort if conceptual errors are found and fixed during business modelling. Without the validation system, they would be embedded into the system specification and only unearthed during acceptance testing. (Ch. 6 § 2.2) Partridge, Chris. Business Objects: Re-Engineering for Re-Use . 1st Edition. Oxford: Butterworth-Heinemann, 1996. The validation system does not require sophisticated technology and should not involve much effort. It can be built within a CASE tool (if one is being used) or constructed on a simple computer database. (I have found that non-object-oriented PC databases are a cheap and effective solution .) (Ch. 18 § 5.1 ) It is worth bearing in mind that the business object model is technology independent. This means, among other things, that it can be implemented on any technology. It can be implemented into an object database, a relational database or even simple flat files. It can be implemented in an object-oriented programming language, such as C++ or Smalltalk, or it can be implemented in a traditional language, such as COBOL. However, each of these implementations requires its own system meta-model in the migration model. (Ch. 18 § 6.2 ) 33 Pragmatic development life cycle Broad software life cycle stages based upon Figure 11.6 ( Partridge, Chris. Business Objects: Re-Engineering for Re-Use . ) Can broadly divide the software life cycle into three stages {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} stage focus framework the general tools such as programming languages and databases application the application using framework tools operation operating the application framework application operation time Later stages are dependent upon earlier stages. 35 Stages organised in time 36 framework A development platform e.g. C or SQL Server application 1 e.g. SAP, Maximo application 2 … … operation 1.1 operation 1.2 operation 1.3 operation 2.1 operation 2.2 operation 3.3 time Deployment of copies motivates the separation into stages. Developmental innocence and unification Developmental choices From a developmental perspective, building your own framework is a serious endeavour significantly easier to build on a pre-existing framework For the first two styles, building (in that style) on a pre-existing framework comes with a cost you also inherit some semantic/ontic commitments For the agile style, you avoid these though you incur other costs If you want to have control of your top ontology, then you don’t want to be saddled with someone else’s choices so, the agile style is attractive 38 Mapping developmental innocence 39 {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} data architectural style mainstream emerging hierarchy emerging agile level 1 level 0 level 1 upwards level 0 level 1 level 0 framework application operation committed Legend - semantic/ontic commitment ‘innocent’ There is a natural correspondence between developmental innocence and opportunities for unification Broad semantic unification Quine (Quine, W. V. 1956. ‘Unification of Universes in Set Theory’) describes unification in terms of a single universe of discourse The Agile style mirrors this structure (roughly in the sense that it creates a single level 0 universe of discourse) The single level 0 universe of discourse opens up opportunities for a broad semantic unification for example, set theory and mereology can be given a unified treatment see Florio, Salvatore, and Øystein Linnebo . Core Constructional Ontology: The Foundation for the Top-Level Ontology of the Information Management Framework (manuscript) 40 More ‘lifting the veil’ Local lifting the veil {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Lion Aslan {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Objects Aslan Lion {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Type-instance relations Aslan Lion Implicit type-instance explicit type-instance “A related point is that whereas the set-theoretic membership relation is typically regarded as a non-logical predicate, the corresponding type-theoretic relation is typically regarded as a logical predicate.” p. 270, fn 2 Linnebo , O., and A. Rayo. 2012. ‘Hierarchies Ontological and Ideological’. doi : 10.1093/mind/fzs050 A similar practical veil lifting happens for the set-theoretic subset relation This additional practical expressivity is useful in software systems. 42 Summary Summary Architectural styles involve (at least) both: a technology/language with a syntactic structure, and a semantic approach (to that syntactic structure) A useful distinction we looked at two semantic approaches that build in dependency of the semantics upon the syntax this dependency is a kind of ‘loss of ontological innocence’ we then looked at a semantic approach that didn’t build in this dependency this has a kind of ‘ontological innocence’ From a development perspective, this ‘dependency’ choice is made at the framework stage hence, when it is made once one starts building the application if one chooses a framework with dependency this places a constraint upon the engineering of the ontology if one chooses a framework without dependency this enables the unconstrained engineering of the (top) ontology In addition, the ‘ontologically innocent’ approach enables for types the unification of types (into a single level) ‘lifts the veil’ of the type apparatus more generally the unification of all semantic ‘patterns’ – including mereology (into a single level) the unification across all semantic ‘patterns’ ‘lifting the veil’ of the pattern apparatus Hence, this ‘innocent’ environment suits ontological engineering where this engineering is empirical, experimental 44 Afternoon session 14-14:50 Chris Partridge, “Why Form, and so Unification of Types, Is Important?” IS motivation for unification – in terms of form 15:10-16 Al Cook (Critical Insight), “Formal Structures Meet a Data Engineer - My Experiences” IS Motivation for form from a practitioner 16:10-17 Sergio de Cesare (University of Westminster), “Implementing a Unification of Types in a Low-Code Environment” example of IS unification of types 45 Appendices An IS Top Ontological View (Survey) of higher order types Based upon: Partridge, C., Mitchell, A., Cook, A., Sullivan, J., West, M. (2020). A Survey of Top-Level Ontologies - to inform the ontological choices for a Foundation Data Model. CDBB. https://doi.org/10.17863/CAM.5831 An IS Top Ontological View (Survey) Partridge, C., Mitchell, A., Cook, A., Sullivan, J., West, M. (2020). A Survey of Top-Level Ontologies - to inform the ontological choices for a Foundation Data Model. CDBB. https://doi.org/10.17863/CAM.58311 drill down higher order types reasonably well-recognised in the IS TLOs, but not ubiquitous 48 Vertical aspects: boundedness 49 Higher-order as a kind of type-instance boundedness The interesting hierarchical relation for us, in the top-level ontologies we have reviewed, is type-instances. The first interesting case for us is firstly, whether type-instances is downwards bounded – the left-most case in Figure 4. … Then if type-instance is also, upwards bounded – the left-most case in Figure 5; there is a choice as to whether it is finitely bounded to a fixed number of levels – and if so, to how many levels. If TLOs are so constrained, they are often fixed to either three or two levels. Figure 5 has examples of two and three levels. OMG’s Meta Object Facility (MOF) is a case whether there are four. higher order == no fixed levels 50 TLO’s boundedness surveyed Survey summary : Most TLO’s are bounded A significant number are fixed two-(or three-)level higher order types reasonably well-recognised in the IS TLOs, but not ubiquitous 51