Back to Technical Modeling Framework

The main aim of this and the next coule of sessions is to identify what metadata we need, define a structure of metaterms, and define exactly how to render these as OWL Annotation Properties, in the UML version of the FIBO model, using the agreed base class within ODM. Today we look at some of the metadata itself.

We started with a presentation and discussion led by Elisa Kendall, based on some sample metadata that was developed for this week's Proof of Concept presentation.

Elisa went through some of the draft metadata in the attached email. These mainly (but not only) relate to provenance and labels. There are also metadata terms for change management concepts, which will be needed for the new content process changes (see later notes).

This is clearly not definitive, but here is a notional set of metadata for the LegalEntityIdentifier class:

Namespace Legend

EK: Also SKOS ScopeNote will be of relevance.

For the metadata we will need a Laundry list of: - Mandatory - Mandatory if Available - Recommended - Optional

Action: EK can put these in a spreadsheet.

Labels – always use. A label is mandatory whether it’s RDF or SKOS. In SKOS, if Pref label, 1 or 1 per language. So have language label pair. Can have mulptiple of those preferred. Only one preferred oer language,. Aoways see a text definition. SKOS Definition, Note, SKOW Example. 5 or 4 or those describe the textual information we should include in formal definitions. Useful to differentiate. Otherwise in OWL you can’t distinguish what is a definition and what is a note.

ISO - note, example, definition. Pick the ones from SKOS. Source critical. Source for definition important. Not easy / SKOS / DC in any obvious way: further definitions, extended definitions, more notes. Not a nice way of comparing those with additional

MB demonstrates the text fields in UML for some existing terms - showin the various kinds of metadata we have informally developed.. these are to become OWL Annotation prpoperties wihtin the meta-terms described above.

Action: Send EK a list of the things we typically say about a text definition.

If none of the SKOS/DC set of standards (also ISO 1087) have an appropriate annotation we can use, then we will create our own set of FIBO-specific annotations. These may be more generally usable so we may define these as an OMG standard of annotation. Have a single model of these ,as an OMG Metadata view.

The OMG Metadata view would also define the questions (see other notes on other PC today) about mandatory v optional etc.

Then there would be a standard on this.

e.g. if you have a certain kind of detail “you should have x” where x is an annotation property.

Feeds into eval criteria (for example, versioning and dates material).

Some of this done already with SBVR. EK to look at the SBVR notes and some related client work.

Would doubtless have more metadata in an MDR e.g. when registering an ontology.

Note: there is a separate metadata model of terms “about” an ontology. Here we are talking about terms within an ontology.

“Consensus” tag is specific to the EDM Council SR Reviews, and will remain as historical information.

Might also have acronyms from other standards that we retain as the designation of that term (see ISO 1087 “designation”).

The ISO ccy, language and country codes are Symbols not Acronyms. Must classify correctly. See also Ticker Symbols. Would not want to hide such symbols as “Alternate Labels”.

Example: USA as a Symbol rather than an Alternate Label.

Need a methodology on when to use an Alt Label and when to use a “Symbol” (our “Schematic Code”).

List of Dates e.g.

• Date proposed for inclusion
• Date agreed it should be included
• Date modified definition
• Date modified term

Could be optionally included. When a major change made e.g. change to the primary label, deprecation of a label.

MOF Versioning has some of the metadata we will need for detailed change control.

There are also CC concepts in DC which we can use.

Action: Design the process.

Question: how much of this (CM metadata) needs to be in the ontology itself? Want the same metadata in the UML and OWL versions, hence the need to have it as OWL Annotation Properties.

Would also be in document, but people working on the ontologies should not have to also have the document to hand. Important in content models to manage these CM features, as well as provenance concepts.

Also tools that may be able to do stuff with this metadata. Would not want to display this stuff in diagrams.

Can use e.g. InferenceWeb from RPI that takes the provenance metadata and see when a change in the ontology has an impact on downstream ontologies.

People have been asking about FIBO Gobernance Model. Needs an audi trail. Some metadata may be at model level (or module) and some may be at individual element level.

Action: Talk about on Tuesday session in OMG QM.

Part of “Eval criteria” conversation - we have a slot for that. Proposal from EK on this is a starting point. Have to show we are thinking about this from the outset.

2 audiences:

• Business folks
• Modelers - IT folks

May have differences in perceptions on this.

Ontologies can end up getting used in reports to go the highest level!

A good CM process has an audit trail. This is something we need.

See CFTC Data Standards document - legal definitions - where did one e.. get a given ISDA definition from. So this is a specific requirement from regulators.

Action: HS send a list of the specific metadata that CFTC wants.

Q: how does this differ from existing OMG Process:

2 ways:

1. it is down at the term level (embedded in the model)
2. need detailed change control documents themselves - Change Notes, Release Notes, etc.

Also source and definition information. This may change from one version of a term to another.

In the ontology, when we include version information, have a seeAlso against this that points to the reasons for the change.

MB: Rather than simply pointing to minutes etc. we would point to specific Change Notes.

These are distinct from “Issues” as such. Issues would be raised against e.g. a standard document. The OMG Issue process is different to Issues in e.g. software development as just described, but there may be parallels in how issues relate to change notes that describe the specific changes that will be made in response to that issue.

We need:

Metadata that we need Auditable document deliverables that describe and mechanize the changes.

Idea: Describe the categories e.g. accountability, history, and work out what else we need to augment these. SKOS and others have many of the items we will need.

Publish as a single document.

Q: So far we are talking of terms only? What about relationships? MB Clarifies that in FIBO when we talk o f”Term” we don't mean just classes, but ibject properties and datatype properties alos. So thew question aoubout whether we were talkign about only terms or also relatiojnships shows we are using theword Term at cross purposes. Looked at part of the model to illustrate what kind of model construct exist, and what we call terms - looked at the Semantics Repository spreadshete/ table format to show what is called a Term there.

What sorts of term would we have change management metadata against:

A: Any change that may impact a reasoner.

There should be metadata for:

• Classes
• Object Property
• Datatype Property
• Generalization - may have only CM for structural change. Has no definition therefore the metadata we have for the above 3 won't apply but we need to record changes that would impact the model as reasoners would see
• Disjoints - as for Generalization
• Inverse relations - as for Generalization

Actions: MB send EK list including the Spreadsheet headers.

Title it as ontology metadata input.