Workstream Session Notes thursday 18 August

Back to Technical Model Framework

Annotation Properties

Can be quite expressive.

Reasoners ignore them.

Can do whatever you can do with another kind of property in OWL

Can create hierarchies

Can specify Domain and Range of these

Can use to identify value for certain things.

Common uses:

Dublin Core - identifying source, creators, contributors (part of our Semantic Provenance requirements).

Other possible uses:

• Definitions • SKOS Notes.

RDF has “Comment” but this is not explicitly a definition, it may be a reference, a source, a note and so on. So the semantics of RDF Comment are too broad. So use SKOS for Definition.

Can create a hierarchy of these.

Result!

Archetype:

Each Archetype might be a separate OWL Class and a single AP would link the OWL class to its archetype.

What we want to be able to do: Recognize each UML Stereotype and render it with the AP for “Archetype”.

This needs to be transformed back to Stereotype when exporting for a UML editor.

What is done now?

Currently use the same as other properties. Generally uses AssClass.

Intervening notions: Added some, e.g. whether something is built in or user defined.

Built ins are instances of APs.

Then have a library representation of DC constructs. This will be an addendum / examples annex to ODM.

What we need

We need a profile that extends ODM to express OWL Annotation Properties.

Using stereotypes in the profile.

What we decided: everything needs to be expressed in OWL. Therefore all needs to be in Annotation Properties.

Decisions:

The construct we use for OWL Annotation Properties: UML Association Class (associationClass).

There are folks who prefer associations to association classes for Annotation Properties.

What's in the Sandpiper profile now: • RDFS Comment, etc. etc. seeAlso,

Best practice in SemWeb community is to have all the additional constructs (DC, SKOS) rendered as Annotation Properties.

What's in what standard, and what isn't?

The DC ones are already built in to the ODM Profile The SKOS ones: some of them are

ODM publishes the DC stuff as an Annex ODM published the SKOS as an annex

Both of these are published as “Best practice”, is it not a normative part of the ODM standard.

The actual constructs are of course defined in DC and SKOS. The rendition of these as ODM (which is not part of the DC or SKOS standard), is not standardize anywhere.

Are these, in that form, part of that standard, or a recasting of them?

FIBO wants to normatively cast these recommendations, as a normative part of FIBO.

Let's get the OMG language right:

To recap:

ODM is a metamodel of OWL concepts (constructs), among which is the OWL Annotation Property.

Then there are created some ontology as an instance of ODM. It will have references to those other standards (DC, SKOS).

Currently, in an as yet unpublished version of ODM, there is a non normative annex which defines the Annotation Properties rendition of those DC and SKOS constructs.

For FIBO, we want to have, normatively:

• Which ODM constructs we use out of the possible set allowed in ODM; • What renditions of DC and SKOS from the ODM annex are used and how.

There are also properties invented for FIBO that do not exist elsewhere.

We want to use certain things that are standard but that have been reformulated as non normative annex in upcoming version of ODM.

If these are to be made normative then these should really be made normative by ODM not by FIBO.

What if stuff is not normative now but might be in future?

We have invented various constructs in FIBO. Of these: • Some turn out to exist in other standards; • Some do not

So the question is now we will represent Annotation Properties in this format.

Next session:

Elisa will present on how to do this. Next session.