We did not discuss these further this week. The full set of metadata terms for Semantic Provenance will be defined off line. The terms required for change management will be adopted from the OMG work. The terms for contextual metadata will be dealt with in a future session.

Of these terms, many of those in the contextual and the provenance space will be fulfilled by terms from Dublin Core, SKOS, and either ISO 1087 directly of SBVR terms for those ISO 1087 terms.

We will derive a normative set of DC, SKOS and ISO 1087/SBVR terms to use, and then see what if anything is left, that is what additional metadata we will require that is not covered by terms from those standards.

The ODM standard defines a number of allowed UML Base Classes (metaclasses) which msy be used for any given OWL construct.

Our practice to date has been to define one UML Base Class from this set.

We should take the same approach with OWL Annotation Property.

The following UML Base Classes are defined for OWL Annotation Property in ODM:

AssociationClass

Association

Property

Class

MB: Recommend AssociationClass
EK: Recommend AssociationClass

In previous sessions, there was some resistance to this choice. Discussed this now.

The rationale behind using the UML Assocuiation Class construct is that it allows for a hierarchy of such terms to be created.

What we envisage is some kind of defined hierarchy of metadata, as a hierarchy of OWL Annotation Classes. Is this a reasonable, realistic idea, or should we simply tabulate the metadata terms by name?

There was no clear consensus on this.

It was suggested that we should define the metadata as an additional Profile within the FIBO model repository. This is in line with what MB has envisaged, so we seem to be in agreement.

Action: Draft profile to be added and presented to the group, with the metadata terms we know of to date. This will be brought up to date with the final OMG decisions on Change Management terms and on a recommended set of DC and SKOS (and ISO 1087/SBVR?) terms to use.

From this, it seems that we will be looking to use OWL Annotation Property.

What would we write. How we import SKOS and how the instance data looks.

Not clear how to render it.

Elisa's example: uses Association Class

Consensus:
Alternative views? Concerns are how to express the facts.

- that is not currently in the ODM spec. Want to update with the 1.1. ODM release, have done a lot of experiments, works consistently with built-in annotation like definedBy and stuff like DC and SKOS.

EK will show it to MB. Can mimic this. Provide profiles.

Migrating our profiles. Sam at EA has these profiles.

This will be part of our big bank profile migration.

For common metadata…

For the specific set we are going to use, we should add a specific tag. (M assumed that's what we would see). Would be an additional profile, not part of RDF OWL profile. Express in ways that can be reused not only in ODM but in other things.

Action: EK will have a crack at this, present and get feedback from the group.

This may not address terms in SBVR. Would need SKOS interpreted as RDF Schema, SKOS in SBVR and so on.

The OWL and RDF Profiles Sam Mancarella is working on. Sam is migrating those into EA. At that point, we could use those profiles.

Meanwhile, the way of representing OWL Annotation Properties is implementation sent to Sam - this is why we would have to do the profile migration before we use the set of OWL annotation properties that we are talk.

Suggest people use the single base class we have defined, in doing FIBO content. This should not of course limit what other people do with ODM in other contexts.

We would was, for people editing, using or submitting FIBO stuff:

a. Only use the single base class defined for FIBO; or
b. Use any base class defined as valid ODM.

Consensus:
From Adaptive POV as long as there are precise rules defined going from ontology to UML then this would not be a problem.

Clearly if more than one base class is used for a given OWL construct, then there will be more than one OWL construct to a given UML base class.

Most of the issues of round tripping here would not be a problem if the stereotype is read when transforming. Previous informal transformations have not read these and have made inferences from e.g. the range.

Processing an import: hard to know if something is in the box or not, you can't see in XMI, you only see that there are properties and what they are owned by.

Display: somewhere you can display datatype properties either as a relationships pointing at the literal, or have in the box. If in the box, presumably it has the Literal shown as its datatype? This is something I may not have done very tidily and would be happy to refactor.

How people want it to look when people import into their tools, of course the diagrams won't get imported with that.

In order to get the diagrams:

See OMG Diagram Definition standard.

There won't be tool support for this just yet, but since that standard exists, presumably there will be in future?

UML specification would have to take advantage of the DD Spec before we will see it in UML. UML 2.5 will possibly take advantage of the DD standard but what we are producing now will not.

Powerdesigner is the UML tool. It does not support the latest UML. API is in VB and tough to use.

It is used in some shops. Once IMM is out, then a number of our tame UML tools will be able to support those thing. That won't affect whether someone continues to use Powerdesigner in their shop.

There is some SBVR support in MagicDraw.

Do we need a statement saying what it takes to play in this standard space. For instance, for the UML, would say “UML 2.x compliant”. Similarly for SBVR, would support any SBVR compliant tool for SBVR experts, and any OWL compliant tool.

SBVR should be added to the set of tooling that we support. This will not necessarily be in the current version. Not in this release but on the roadmap for the near future.