A common world-view? The meta-for metamodel

1. Bryan Lawrence A common world-view?The meta-for metamodel

2. Outline • Information Modelling Paradigm: - Using UML • Letting the standards loose ... • What is OUR metamodel? • Working with Curator • Working Together

3. Using UML • NOT only for software modelling! • “With the conceptual perspective, the UML represents a description of the concepts of a domain of study … we are building a vocabulary to talk about a particular domain.” • “Nobody, not even the creators of UML, understand or use all of it ... You have to find the subset of UML that works for you and your colleagues ...” • “Diagrams are simply the presentation of the meta-model” (in one perspective … not the only one). (Quotes: Martin Fowler, UML Distilled)

4. Climate Model Intercomparison (Producer and User) Community New Committee Metafor/Curator BADC, NCAR, MPIM, IPSL, GFDL etc .. a model is an abstraction of phenomena in the real world; a metamodel is yet another abstraction, highlighting properties of the model itself. A model conforms to its metamodel in the way that a computer program conforms to the grammar of the programming language in which it is written. … a meta-model can be viewed from at least two perspectives: as a set of building blocks and rules to build models and as a model of a domain of interest. … an ontology constructed as a conceptual model describing a particular universe of discourse is much more likely to be the latter than the former …

5. Key ISO Standards(Geographic Information) • ISO19101 – Reference Model • ISO19103 – Conceptual Schema Language • ISO19109 – Rules for Application Schema • ISO19115 (IS01939) – Metadata • ISO19118 – Encoding • ISO19123 – Schema for coverage geometry and function • ISO19136 – Geography Markup Language Why? Designed for describing distributed “geographic” information systems! INSPIRE Compliant! Already in use for a “Model Driven Architecture”: UML encoded according to ISO19103, ISO19118 and ISO19136 Annex E already being machine written into XML schema (and RDF!) with three different code bases existent. (NB: There are some inconsistencies between 19118 and 19136AnnexE … with the latter preferred by the folk we work with) (AND MORE!)

6. Too much ISO soup for Metafor?! • Need a distillation. • Fundamentals of Information Modelling. • http://metaforclimate.eu/trac/ticket/158 • I need help! • … and that distillation needs to be a “starting point for our metamodel”. • And we should allow versioned changes away from it • … and our metamodel needs to be imposed for CIM V1.0 (not CIM V0.X) … although we should conform to “not knowingly doing wrong”, so we can use the ISO naming scheme for example as it’s painless and gets us in good habits.

7. Metamodels, Use Cases, and Implementations. • So a metamodel is a set of rules. • Why do we want rules? • To help serialisation. • To help support the use cases • To simplify the construction of the model. • Do these rules constrain the serialisation? • They had better not! But they should simplify some versions dramatically.

8. The Fried Egg Approach to Standards • Crucial to expect implementation profiles which both constrain and extend. • Need to build this into metamodel from beginning.

9. Why metamodels matter: associations, aggregations and composition! • Reminder: if A is composed into B, then if B is removed A goes too … and A cannot be part of C! • (Composition: closed diamond) • If A is aggregated into B, then what is the difference between that and saying A is associated with B? • Answer: depends *entirely* on the metamodel! • (Aggregation: open diamond) What’s wrong with that diagram? What was Bryan thinking? How could you build an application based on that?

10. Our Metamodel • What is an association? • What do we want it to mean? • Customary difference between an attribute and an association? (Attributes internal: associations are to objects with identity?). • Extending UML: Stereotypes, Tagged Values, Constraints. • Do we want to use stereotypes to indicate anything? Discoverable? Discrete? • Tagged Values: Documentation.

11. Things we might want to be discoverable as entities returnable as documents and harvested by the system Stereotype Candidates(examples: discrete and/or discoverable) Things that will exist as products in the “creation” phase of CIM documents

12. Metamodels affect Deployments Assumptions? 1) CIM “documents” are created. 2) CIM “documents” are harvested 3) CIM “documents” are loaded into a search system (hello “RDF”, if we didn’t see you helping out in #1). 4) CIM “documents” are returned to the user! Our metamodel had better have the concept of a “document” – we could do this using a <<doc>> stereotype! The <<doc>> stereotype could be ignored by other deployments. Or perhaps we are simply talking about feature type instances …

13. Metamodels affect services and tools Metamodel

14. Associations Matter: Serialisation • What we “intend” with associations will affect code generation (and human interpretation!) • e.g: How do we serialise an association into XML? • It’s a choice thing! • we might intend to have an XML-complex type embedded in another XML-complex type, or • we might have them both at the root of the XML document. • Either way, are the instances referencable in their own right? • GML says yes: and uses xlink to do it

15. Our Metamodel Concluded • So the metamodel affects how we describe the real world … • … and in this case, we’re saying: we have some knowledge of the use cases • “human generated metadata” + “machine generated metadata” = “discoverable metadata” return “documents” • Means: “xml document” + “xml document” = “xml document” re-serialised into rdf triples (of some sort) and then back out into xml … • Now we have a choice, we can use this information in our conceptual model, or application schema, or both. But it’s our choice. • Who is OUR?

16. Working with Curator: New Joint Committee/Working Group The aim of this group is to prioritize development tasks for standardized metadata that will support scientific activities in the climate and related communities. The information needs encompass diverse projects and a variety of physical domains, and support specialists with a multitude of interests. The resulting requirements are that the metadata systems be highly modular, suitable for parallel development, and suitable for both incremental and selective implementation. The success of this group will be measured primarily by the willingness and ability of system implementers to incorporate the metadata produced. A secondary metric is whether others emulate the processes and methodologies employed here. Tasks Identify and prioritize which artifacts (e.g. model input/output files, model configuration files) require standardized metadata in order to support science project goals. Identify methodologies for development of metadata. Develop and maintain a schedule of metadata development tasks conforming to the identified priorities and selected methodologies. Each task should be associated with specific contributors, project targets, artifact targets, dates, and system prototypes where the new metadata will be implemented. Track incorporation of metadata in prototype and production system implementations Constraints This is a body undertaking large scale collaboration. Members are understood to have different missions and a range of priorities, and are participating voluntarily. Members are not required to use any of the metadata packages developed, but do undertake to make and meet realistic commitments against agreed goals. Activities of this group will be publicly accessible via a web browser (no password required to view). Members Members will include representatives of the user communities, metadata developers, technical managers, and system implementers. A Chair will be chosen from members to organize and moderate meetings. Minutes will be posted publicly after meetings. Meetings The group will have quarterly virtual meetings via telecon and/or web conferencing. Meetings are expected to last several hours.

17. Climate Model Intercomparison (Producer and User) Community New Committee Metafor/Curator BADC, NCAR, MPIM, IPSL, GFDL etc How does the proposed committee fit in? I see us trying to exploit UML packages to modularise development. I see us prioritising things differently. I see us trying to exploit the “fried egg” philosophy. Identify what we have in common, and build systems that allow constraint and extension. I see us recognising that it needs to be about more than curator and metafor in the climate community, and that climate modelling doesn’t exist on it’s own in the environmental community! But we need to start the process, and I’ve held things up long enough trying to get our colleagues to agree a “type” of process. Perhaps we should just start?

18. Summary • We need a metamodel! • It will (already does) inform how we can “populate” and “use” the CIM, but depend upon or constrain the actual serialisation(s). • We should work with existing metamodels and methodologies for activities like ours, and • We need to work on colleagues outside metafor to buy into this methodology, because it buys us • “inter-operability” outside the climate community, and • the experience of others who have tried these sort of activities, who rapidly found out that it’s about more than “the ontology”! • We might be able to exploit a lot of the GML (ISO19136) meta model experience without going anywhere near lines, polygons etc … • … but we need to be pragmatic, and iterative, and we will need to bend the rules to deliver!