1. SC32 FBM Study Group Report Korea SC32 Meetings, May 2013 Baba Piprani - Serge Valera 1 ISO/IEC JTC1/SC32/WG2 N1801

2. Agenda 1.Background & Study GroupTaskings 2.Setting the Stage – positioning modelling methodologies 3.Work Examples a.Use Case1 – ECSS (European Cooperation for Space Standardization) Requirement Specification capture b.(Use Case2 19763-12 UML model in FBM) 4.Use case Findings 5.Recommendation 2

3. Background Canada proposal SC32/WG2 N1577 – Objective: Meta model for information models using Fact Based Modelling – Canada submitted initial FBM WD in Greece Sep 2011 (SC32 WG2 N1612) using FBM notation 2011/09 : Greece decision: – FBM notation not accepted, produce UML notation for registry – Canada submitted revised FBM WD in Berlin June 2012 (SC32 WG2 N1640) using UML notation 3

4. Background 2012/06 : Berlin decision – Canada proposal for a new 19763 part for FBM model registrations is presented. – WG 2 question whether 19763 part 12 can be used to register FBM models (ORM, CogNIAM, DOGMA, FCO-IM, NIAM)? – Study group is formed to address that issue including other types of models, i.e. OWL and RDF.  report expected for SC32 Korea May 2013 4

5. Study report An assessment has been done on how to use part 12 for FBM. The conclusion is that this is possible, once an FBM model has been transformed into a Entity/Relationship model following the process of transforming the FBM conceptual model into a logical E/R model as shown in next slide. 5

6. Mapping data modelling methodologies to different technologies 6

7. A conceptual data model specifies the semantics of the data relevant to a domain in some form of a formal modelling notation (e.g. Fact Based Modelling, SBVR, Predicate Logic etc.) A logical data model is expressed in terms of a particular data modelling methodology, for example attribute based modelling like ER as entities and attributes, or UML as classes and properties. A logical data model can be developed from a conceptual data model 7

8. Mapping data modelling methodologies to different technologies A physical data model is developed from a logical data model and is used to define the implementation details for storing the data objects on a computer, e.g. SQL Each transform between modelling methodologies needs to preserve the originally declared semantics 8

9. Part 12 can be used however Transforming a FBM model into a E/R (logical) model requires a process regimen: – adding technology specifics (i.e. E/R technology) and rendering difficult the transformation toward other technologies (e.g. relational, hierarchical, realtime) – incurring loss of semantics: using Part 12, the focus is put on entities and attributes while FBM’s focus is on “system requirements specifications” 9

10. What are System Requirements? An example from the European Cooperation for Space Standardization ECSS-E-ST-70-41C 10

11. ECSS-E-ST-70-41C Use case 2 requirements related to the “parameter monitoring service” specification specified in natural language: Requirement 1: Each on-board monitoring service shall include exactly one parameter monitoring sub- service. Requirement 2: Each parameter monitoring sub- service shall belong to exactly one on-board monitoring service. 11

12. ECSS-E-ST-70-41C use case Using FBM graphical notation, these 2 requirements are represented by the following diagram: Using FBM controlled natural language, these 2 requirements are represented as follows: 1.Each on-board monitoring service includes exactly one parameter monitoring subservice. 2.Each parameter monitoring subservice belongs to exactly one on-board monitoring service. 12

13. ECSS-E-ST-70-41C Use case 3 additional requirements: Requirement 3: Each on-board monitoring service may include exactly one functional monitoring sub- service. Requirement 4: Each functional monitoring sub- service shall belong to exactly one on-board monitoring service. Requirement 5: Whether the on-board monitoring service includes a functional monitoring sub-service shall be declared when specifying that service. 13

14. ECSS-E-ST-70-41C use case Using FBM graphical notation, requirements 3 and 4 are represented by the following diagram: Using FBM controlled natural language, these 2 requirements are represented as follows: 1.Each on-board monitoring service includes at most one functional monitoring subservice. 2.Each functional monitoring subservice belongs to exactly one on-board monitoring service. 14

15. ECSS-E-ST-70-41C use case Using FBM graphical notation, requirement 5 is represented by the following diagram: Using FBM controlled natural language, requirement 5 reads: 1.In each population of on-board monitoring service includes a functional monitoring sub-service, each on-board monitoring service occurs at most once. 2.For each on-board monitoring service, that on-board monitoring service includes a functional monitoring sub-service if and only if that on-board monitoring service includes some functional monitoring subservice. 15

16. ECSS requirement for registration Only specify the WHAT, i.e. no implementation specific.  Findings: – Transformation to logical models is inadequate for ECSS based on above constraint. – Let’s try to directly (i.e. without transformation) model the ECSS requirements to 19763 Part 12. 16

17. ECSS requirement for registration expectation and discovery out of the registration is not entities and attributes but stated ‘requirements’ so the capability of FBM to model fact type readings is THE minimum and mandatory requirement for FBM discovery without that discovery requirement, there is no reason to perform any registration and subsequent discovery search 17

18. ECSS requirement for registration Entity type: Relationship: Relationship end: on-board monitoring service parameter monitoring subservice functional monitoring subservice requirements 1&2 requirement 3&4 requirement 5 Relationshiprelationship end : entity_rolemin cardinalitymax cardinality requirements 1&2on-board monitoring service11 parameter monitoring subservice11 requirements 3&4on-board monitoring service01 functional monitoring subservice11 requirement 5functional monitoring subservice01 18

19. ECSS use case problems Modelling fact types using part 12 relationships is inadequate: – we can model some characteristics of binary fact types, but we loose e.g. the capability to verbalise the fact type (the verbs, …) – we cannot model unary fact types – we cannot model n-ary fact types 19

20. Conclusion from ECSS use case The fact type is THE key element of fact based modelling. If we cannot properly model a fact type using Part 12, using Part 12 for FBM is a NO-GO. If FBM models are to be registered using a 19763 approach, they require a separate 19763 part. 20

21. Similar Conclusion from TR9007 TR9007 Concepts and Terminology for a Conceptual Schema and Information Base Use Case: Car Garage contains 47 Propositions Appendixes contain how each Modelling approach models these propositions + checklist Appendix D – Entity Attribute Relationship Approaches: Checklist shows 22 out of 47 propositions cannot be modelled in this method Appendix E – Binary Relationship Approach (FBM): shows 8 out of 47 propositions cannot be modelled in this method 21

22. Recommendation 1.If SC32 WG2 wants to include FBM registration in 19763 MFI, then there is a requirement for a new part as per use case proof demonstrating loss of semantics. 2.It is not recommended that 19763 Part 12 be used to register any FBM models due to loss of semantics, and inability to return to the user the lost semantics, during discovery. 3.Investigation of OWL and RDF suitability in Part 12 was not conducted at this time. 4.The work of the SC32 FBM study group is completed as they have completed their findings of whether 19763-12 is suitable to register FBM models. 22