ISO TC211 workshop to consider the impact of non-relational technologies on TC211 standards BORO Solutions experience 4 th Feb 2021 Apology Slides cobbled together (in haste) from multiple sources The brief: Is there a workable UML profile for managing ontologies? What should the output of such a model be like? (we covered how neither UML nor OWL is ideal for this there are certainly problems generating OWL ontologies from the current TC211 UML profile the TC211 use of UML could be improved, even within its own profile) What Chris brings is experience (in his domain) of using UML to create/manage ontologies (quite probably not expressed in OWL) Background Basis The basis for our comments Our experience on BORO (since the late 1980s) Foundation Data Model (FDM) for UK’s National Digital Twin – since last year Can only comment on TC211 based upon our recently started analysis of INSPIRE and OS Open names 5 Foundation Data Model –Top-Level Ontology “Our Foundation Data Model will need to address the questions proper to an upper ontology, which can describe general concepts independent of a problem domain.” The pathway towards an Information Management Framework (for the National Digital Twin) 6 2010 BORO Background: an (ancient) broad timeline 1990 Ongoing BORO development 2000 ISO 15926 : Part 2 IDEAS DODAF DM2 MODEM OMG UPDM Taken from: https://www.borosolutions.net/boro-related-standards-overview 7 BORO Implementation Landscape Conceptual languages BORO Native Dialects – various (including BUML) Pre-BORO Implementation Languages Multiple ‘language’ implementations C# Python UML (EA) SQL JSON Etc. Sometimes multiple implementations in a single language a separation of concerns perspective A separation of concerns perspective Ontological interest Philosophical interest Technology ‘Locked’ Zone Application Agnostic Zone Greenfield Zone Application Dependent Zone Computation Dependent Zone Technology Dependent Zone Captures and describes content of the business domain Captures and describes the application’s knowledge of the business domain Specifies the computational design Specifies the physical design FDM Architectural Framework Technology Agnostic Computation Agnostic Business Architecture System Architecture Legacy System(s) No System(s) Ontology Agentology Computational Model Physical Model Key Mapping Point Mapping Point Mapping Point Mapping Point based upon the OMG’s MDA separate real world and system concerns BORO, FDM and TC211’s standards belong in this ‘concern’ so the other ‘concerns’ can/should be separated out 10 Adopting a separation of concerns perspective Technology Dependent Zone The good thing is the technology comes with a framework The bad thing (from a technology agnostic perspective) – is the technology comes with a framework If one wants to work using a t echnology/computation/application agnostic conceptual approach One needs a technology/computation/application agnostic conceptual framework In other words, a top level If one wants this to be semantic then one needs a foundational ontology as the framework And one needs to make sure the framework is, indeed, technology/computation/application agnostic 11 Requirements for a Conceptual Modelling ‘language’ A conceptual modelling ‘language’ Given one needs a t echnology/computation/application agnostic conceptual framework in other words, a top level if one wants this to be semantic then one needs a foundational ontology Given one needs to keep t echnology/computation/application concerns out Still … one needs to work on the t echnology/computation/application agnostic conceptual model using some technology so, one needs a conceptual modelling ‘language’ 13 An example of top level The top level Another top level ISO 19109 is a top-level conceptual model ISO 19505 UML is another So, the top-level approach is followed. We would argue that ISO 19109 : is approaching, but not quite yet, a foundational ontology hasn’t kept out technology /computation /application concerns as much as it could 14 A conceptual modelling ‘language’ Two key requirements Expressivity Visualisation 15 UML – lack of expressivity (in no particular order) Native objects – single classification use stereotyped classes as objects (classes can be multiply typed) use a different instantiation relation – e.g., dependency Class levels stratified levels – M0, M1, M2, M3 ignore this restriction bounded upper levels – M0, M1, M2, M3 ignore this restriction Class-Object divide use stereotyped classes as objects Structure – behavior distinction ignore this restriction – just use class diagrams see https://www.borosolutions.net/modem-behaviour INSPIRE also? Relation inheritance reify relations 16 Separating structure from representation EXPRESS example Border controls for the conceptual model: Keeping non-conceptual concerns out t echnology/computation/application conventions usually creep into the conceptual domain When they do, they need to be refactored out Examples from the BORO experience Remove the various ‘apartheids’ - integration Data and metadata Entity and attribute Structure and behavior (process) (see https://www.borosolutions.net/modem-behaviour ) Introduce a separation Structure and representation 18 Separating structure and representation In conceptual model Separation of structure and representation Typically, this occurs in attributes (so related to entity and attribute) So de-attribution involves recognising this separation Structuralise data attributes that are structural Represent data attributes that are representational Architecture of Onamatology 19 Mapping ISO 10303-11 – EXPRESS Data Types {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} Structure Representation To give you some idea of the scope (and scale) of the task. Here are what the mappings for the data in EXPRESS might look like. 20 ISO 10303-11 - Boolean data type 8.1.5 Boolean data type The boolean data type has as its domain the two literals true and false. The boolean data type is a specialization of the logical data type. Syntax: 182 boolean_type = BOOLEAN . The same ordering holds for values of the boolean data type as for values of the logical data type, that is: false < true. EXAMPLE In this example, an attribute named planar is represented by the boolean data type. The value for planar associated with an instance of surface can be either true or false. ENTITY surface; planar : BOOLEAN ; ... END_ENTITY; Is ‘planar’ a sub-type of surface? Or a kind of ‘true’? 21 Onomatology Separating names structure from names representation Another term – onomatology {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} onomatology names the study of the etymology, history, and use of proper names Approach: Good examples of obvious ‘universal’ patterns Passes the Groucho Marx four-year-old child test Rufus T. Firefly: Clear? Huh! Why a four-year-old child could understand this report! Run out and find me a four-year-old child, I can't make head or tail of it. Interesting because: clear, obvious, general pattern, also usually are obviously missing from computer information system 23 Onomatology Two issues Generality Separation of structure and representation 24 Onomatology – Generality Example INSPIRE’s general names INSPIRE: start of a general name type pattern 26 INSPIRE: Examples of non-generic names 27 style.visibility style.visibility Adding a general names layer New General Names layer 28 Onomatology: Separation of structure and representation stories Simple story: Separating Names from the Objects they Name BORO Benefits - 101 Separating Names from Objects One aspect of the BORO process is that it separates Names from the named Objects – enabling these to be analysed separately. Effectively, the BORO Model divides into: NameSpace , and ObjectSpace Where different systems/ messages refer to the same objects , t here are different NameSpaces with the same section of ObjectSpace . 31 Example 1: Exercise Nicknames Flying Fish/08 is in ObjectSpace . The name ‘Flying Fish/08’ is in NameSpace . The name is all you see from the outside. 32 Example 1: OPERATION CODEWORD OPTELIC is in ObjectSpace . The name ‘OPTELIC’ is in NameSpace . The name is all you see from the outside. 33 Model View 34 This separation pattern permeates the BORO models. More technical Story: An approach to names An overview of the grounding ontology and how it can be implemented in a system Described in these papers: https://www.borosolutions.net/grounding-enterprise-computing-nomenclature-ontology and https://www.borosolutions.net/grounding-enterprise-computing-nomenclature-ontology-long-version Grounding levels Euler Perspective Grounding Perspective Identifier Inscriptions (Tokens) Identifying Spaces Identifiers (Types) US ISO Country Code GB ISO Country Code GB GB GB US US US US ISO Country Code GB ISO Country Code US US GB GB Legend Inscriptions (Tokens) Identifiers (Types) Identifying Spaces ISO 3166-1 Alpha-2 Code ISO 3166-1 Alpha-2 Code In this view, the objects in the nomenclature ontology are recursively grounded in a series of levels at ground level, the identifier inscriptions are of spatio -temporal particulars at the next level, identifiers are grounded in their member inscriptions then, the identifying spaces are grounded in their member identifiers 36 A baseline implementation Identifiers as Attributes (Fields) Identifiers as Objects (Rows) Legend Countries ISO Alpha-2 code: String ISO Numeric code: String ISO Alpha-2 code: String = GB ISO Numeric code: String = 826 Country Names Countries exemplar: String exemplar: String = GB exemplar: String = 826 … … Identifier Inscriptions (token) Identifiers (type) Identifying Spaces Country Name Types ISO Alpha-2 Code ISO Numeric Code Schema-Level Identifiers Domain Nomenclature Patterns of Current Identifier Implementation for an Entity identifying space Column (Attribute Type) Table Row Identifier-type Cell Table Row Identifier-token (inscription) Cell Value Cell Value Current system implementations contain tokens and successfully work with them. Enterprise systems show two main patterns Identifiers as Attributes and Identifiers as Objects Neither of which resemble Quine and Davidson’s approaches mentioned earlier. It is not uncommon to find examples of both patterns in a single system. The figure shows the pattern for a single entity type – Countries. In an enterprise system, this pattern is repeated for each entity type resulting in a multiplicity of nomenclature infrastructures. Our goal here is to find a way of unifying them. 37 Troubling tokens - a proposed implementation Existing systems contain ‘real’ identifier inscriptions (tokens) these play a critical role in the operation of the system as they are exemplars of their types, used to identify and reidentify tokens of the same type hence the nomenclature ontology needs to be extended with tokens Given the earlier analysis, we want to introduce the tokens as just tokens with no additional commitments to sometimes treating the tokens as pictures of themselves we also want to avoid committing to a token being either exclusively for use or mention the simplest design is to add the token as a new kind of representation and connect them to their representation in the model This is similar in some ways to Davidson’s ‘word-type-reference to word-token-reference to word-token’ pattern (mentioned earlier) in that the word-type and word-token are referred to and the actual token demonstrated One outstanding issue is that the non-token picture uses of the inscriptions remain in the representations the next step is to remove these, leaving the representations as bare nodes When humans wish to review the model, it is useful to present the nodes with labels to achieve this, one needs first to make a clear distinction between what is stored internally and what is viewed (a kind of ANSI-SPARC or model-view architecture) in the view layer, one presents a framed copy of the token (in a similar manner to Quinean quotations) with agreed framing glyphs the view can recover the names/labels of these nodes algorithmically by navigating from the bare node to their ‘real’ identifier inscriptions one can present the name/label using a bare copy of the ‘real’ identifier inscriptions we have done this for the schema level representations in our models – nodes such as ‘Identifiers’ and ‘Countries’ 38 Troubling tokens Domain Model Nomenclature Model Nomenclature Field Field Model Tokens Exemplar Tokens Model Country Codes [GB] Countries Countries Country Codes United Kingdom Legend represents names models represents types-instances Inferred Names <GB> Token [GB] Identifier ? represents instance names <GB> <GB> Domain types-instances instance names names style.visibility Proposed implementation structure Exemplars Domain Model Management type-instance type identifies instances of type identifies instances identifies instances identifies identifies identifies instances type-instance type Identifies type identifies Nomenclature Identifier Inscriptions Identifiers Identifying Spaces Objects ISO Alpha-2 Code ISO Numeric code ISO Alphabetic code Countries Currencies Legend Bare Nodes Inferred Names Token Nodes System Real World Domain [GB] GB GB 826 USD 826 USD Tokens United Kingdom US Dollar Identifying Spaces Identifiers (type) https://www.borosolutions.net/grounding-enterprise-computing-nomenclature-ontology and https://www.borosolutions.net/grounding-enterprise-computing-nomenclature-ontology-long-version 40 The approach In this approach, all the nomenclature management is handled in the same way there is no schema-data names distinction as in existing systems moreover, all the representations of nomenclature components are bare nodes and so are first-class citizens they have access to the same resources as the domain’s bare nodes tokens are always tokens so there is no need for framing devices such as quotation marks hence, there are no pictures of tokens This resolves the issues identified earlier. This way of managing tokens has a history. for example, in Schapiro’s semantic network SNePS inscriptions are a special kind of thick node joined to the rest of the semantic network of thin bare nodes by LEX arcs Schapiro rightly compares the resulting separation of thick (token) and thin (bare) nodes with Carnap’s example of structural definite descriptions however, the thick inscription nodes are held at arm’s length via the LEX arc, without access to the resources of the bare nodes, making them second class citizens 41 Initial FDM Analysis Fragment of the analysis {5C22544A-7EE6-4342-B048-85BDC9FD1C3A} candidate standard logical expressivity TLO usage Industry usage features comments UML YES (ISO and OMG) OCL-level fragment of FOL UFO, BORO, IES4 Widespread visualisation Note: ODM (UML Profile) extends UML's OCL to CL (CLIF) level. SW Family - OWL/RDFS/RDF YES (W3C) various (most often DL fragment of FOL) BFO, gUFO, versions of DOLCE and GFO, OpenCyc Widespread visualisation, automatic reasoning, linked data This is a family of languages with different syntax and semantics. CL (CLIF) YES (ISO) between FOL and HOL DOLCE, parts of BFO Academic, not used much in industry de facto standard for FOL This is a family of languages with common semantics. TPTP de facto standard FOL and HOL - Academic, not used much in industry de facto standard for FOL and HOL, automatic reasoning EXPRESS-STEP-File YES (ISO) FOL? ISO15926, HQDM Widespread A marriage of two very different languages, one for the schema and another for the data. A common format for legacy system data. Probably not a viable format in the future. Industry Standards Abstract Syntax Shortlist 43 Initial thoughts It is a usual practice to adopt an abstract syntax for documenting a TLO, one that allows for multiple concrete implementations hence, we are considering adopting this approach, though there is no immediate requirement to fix on a particular syntax There are multiple industry standards for abstract syntax we would rather consider one of these, than develop our own it may be a single standard language or a small group of standard languages for example, we could choose to go with CL and UML (maybe with the ODM extension) before we can select a group, we need to establish that lossless translation is feasible 44 Multi-language implementation Hub and spoke analysis Mitigating translation costs General hub spoke 1 spoke 1 = source and sink spoke 2 = sink only spoke 3 = source only spoke 3 spoke 2 One rim – hub and spoke 47 spoke 1 = source and sink spoke 2 = sink and intermediate spoke 3 = source and intermediate spoke 4 = sink only spoke 5 = source only spoke 6 = source only hub spoke 1 spoke 3 spoke 2 spoke 4 spoke 5 spoke 6 Two rim – hub and spoke 48 Example UML EXPRESS OWL RDFS XMI XML … … 50 Abstract Syntax Candidates CL SW TPTP UML EXPRESS 52 UML SW CL TPTP EXPRESS 53 UML SW TPTP CL EXPRESS UML Hub (TPTP to CL) 54 UML SW TPTP CL EXPRESS 55