WS2 Session Notes Thursday 29 September

Additional Metadata as OWL Annotation Properties

Discussion on this topic covers two distinct sets of decisions to be made:

What metadata? How to render the OWL Annotation Properties for this metadata, in FIBO

What Metadata

The first question has been discussed, and we will (off line) finalize what are the specific metadata terms we need. These elements fall into the following categories:

Contextual MetadataClassification FacetsContext markers of various typesSemantic Provenance MetadataExisting: Term Origin, Definition OriginAdditional: Cross reference to (non origin) standards by term and definitionAdapted definitions and the likeChange Management MetadataThese are handled by the OMGsee this spreadsheet for current detailsArchetypesWe 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 bulk of this work will be concluded off line from these sessions.

Rendering

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:

AssociationClassAssociationPropertyClassMB: 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.

A note on OWL Annotation Properties:

These are not really very different to OWL Object Properties, or indeed any kind of OWL Property. The distinction is that reasoners know to ignore these for processing.

That is, an OWL Annotation Property has a Domain and a Range.

Therefore, to define a set of properties with a domain and a range, and to be able to arrange these in a hierarchy, we should use the Association Class base class from UML.

We will draft something for next week in the FIBO EA Repository and see how this looks, then fine tune it.