Back to Shared Semantics

Back to start

We started the session with a quick overview of the RFC that was posted on Monday per the 4 week deadline. There remain a number of things to be done before the RFC is in its final state, but due to the 4 week rule we posted the RFC in its current state as a snapshot of what we have.

One place in the RFC has a blanked reference 'xxxx' to whatever is or will be the standard which will define the change management metadata. It is our intention not to replicate this information in this RFC since, at least for the change management aspects of the metadata in xxxx, we would want to defer to that (the spreadsheet which forms the current workings of xxxx also as it happens includes some provenance terms, so it is does not exclusively consist of the metadata which we want to defer to in this way).

The question is, what should be the reference for xxxx and how soon will we know what it is and be able to put the formal reference in the RFC text?

The xxxx will be an “AB Recommendation” so the reference xxxx should be referring to that. This will be an AB document or specification and will have an OMG document number.

That is, this will not be a standard, RFP or RFC as MB had assumed.

In the section of this draft RFC that refers to Shared Semantics, we have treatments for each of a number of scenarios for referencing the original ontologies or standards on which we have tried to ground the semantics of terms in the “Global Terms” section of the model. One such treatment is for XBRL terms, and this is one area where the draft specification is necessarily incomplete as we only started to look at that last week.

At the moment this XBRL Abstract Model is available as a UML model. There is a Public Working Draft. Link supplied by email:

http://xbrl.org/Specification/abstractmodel-primary/PWD-2011-10-19/abstractmodel-primary-PWD-2011-10-19.html

One of the reference mechanisms which we have had to “freeze” our latest thinking in the RFC draft is the treatment of UML models, and in particular the use of SKOS Match. This has been a recommendation that came out of several of these sessions (see minutes) but there was some discussion again today as to whether we really want to or should use this. MB reiterated that the decisions of this nature are decisions of this Workstream group and the aim of the RFC is to agree and then formalize what the best minds on this group can come up with.

As things stand, the following dilemma presents itself as far as the use of SKOS Match for mapping to terms semantics in UML standards is concerned:

• Dilemma: SKOS Match must match a “SKOS Concept” to another “SKOS Concept
• Horn One: UML Classes are not SKOS Concepts - but they could be decorated to identify them as such; however
• Horn Two: The OWL Classes are also not SKOS Concepts.

We previously discussed solutions to this in the form of marking up the class OWL:Thing as a SKOS Concept for example, but did not reach any final conclusions about whether this was valid or practical, similarly whether it was possible for the use of OWL classes to implicitly mean that each OWL class is a SKOS concept (OWL classes are set theory constructs which, by definition any by explicit statement in any given OWL model, are sets of things which exist).

If we are not able to decorate (or imply) the identity of the OWL classes and the UML classes as being also “SKOS Concepts” then any SKOS Match relationships would have to have new model constructs which are SKOS Concepts at either end, and these would have to be mapped by some other relationship to the OWL and to the UML classes. So the SKOS Match usage will have added a level of complextiy without solving the original question of how to represent a relationship of semantic equivalence between the OWL classes we created for a given set of meanings and the UML model classes (in for example the REA Ontology UML models) for those same meanings.

Statement:

• The idea that a given class is a SKOS Concept cannot be implicit
• Have to state explicitly that the class is a SKOS Concept.

Can use an Equivalent Class relationship. This is an OWL Equivalent Class relationship.

MB responds: we do that for equivalences between an OWL Class and another OWL class, i.e. this is the mechanism we use for reference to semantics in other OWL ontologies. See for example the pilot / experimental mappings we did for UN-FAO Ontology as part of carving out these various Shared Semantics approaches. The use of SKOS Match was suggested for the scenario where the other “ontology” is in fact represented as a UML model (and we may possibly use a similar approach or one derived from this, for other non OWL formats where there may be strong enough semantics to derive basic concepts from, such as XBRL).

Also note on the above suggestion:

• Don't use equivalent class. Use sub-class.

• SKOS Concept is an OWL Class.

• OWL Class is not necessarily a SKOS Concept.

That is, the assertion made in the SKOS specification to the effect that a SKOS Concept is necessarily an OWL Class, does not imply the opposite case, and so we cannot assume that our OWL Classes can be regarded as SKOS Concepts. Therefore we can't use SKOS Match as a mapping construct in our model.

• Can't use equivalent class, that's wrong. Have to decide on a case by case basis as it's not clear there is one approach that will fit this.

Action: MB, PR, and EK to set up a call to look at this on a case by case basis.

Is important that we use SKOS Match at all?

Suggestion: Have a third package that is the REA to OWL Mappings. MB: What form would these mappings take? It is not possible in EA to have relationships in a package separate from their owning classes.

Question: Is there some support in ODM for that? Would create a mapping ontology in ODM.

Given that we have supported ODM in the EA model without every trying or having to try and have relationships in a separate package from any of the classes that they are relationships to (or from), this idea clearly can't be implemented in the parts of ODM that we have implemented.

Suggestion: Another option is to convert the UML model that's in the ISO specification into an OWL ontology.

Well that would work but then we don't have a treatment for UML based external standards, we just have an idea that for individual cases like REA we might take it upon ourselves to create an OWL ontology and present it back to the original owners of that standard and see if they like it. At which point, does it even differ from what we already did?

The point was made that some of the approaches we are suggesting would make it impossible to “reason over” the resultant material. By “reason over” we mean being able to translate all this material into OWL (the terms in our Global terms, the terms in the originating ontology, and the relationships asserting that the one is derived from the other), and performing semantic operations such as drawing inferences about individuals. Mike pointed out that this part of the model is never intended to be populated with OWL individuals (equivalent to instance data in conventional data modeling), and does not need to be reasoned over in any scenario that I can think of. Rather this is our attempt to answer the following:

• Given that we define semantics for terms which are more general than their application in financial services (e.g. contracts, parties), we can exhaustively either:
• Formally indicate their meaning in relation to some competent industry standard in that area of knowledge and practice; or
• Not do so.

This is the requirement we are trying to meet with these Shared Semantics approaches (see also wiki and previous minutes if any clarity is required on this). This use case does not explicitly mean that one needs to reason over these relationships.

On that case can't we use some of the same metadata that we have since developed for the main body of the model, e.g. the Dublin Core extensions for dct:source that we have identified for Term Origin, Definition Origin and so on in the financial instruments models? After all, those were also created with extensive reference to non OWL models, specifically UML and XML Schema.

This sounds like it would work. This material didn't exist when we started the Shared Semantics work.

MB, EK and PR to hold separate session(s) exploring these issues, since it was felt we could not resolve them on this call. Depending on the outcome of that, we have to deprecate the idea of openly declaring the origin of the semantics of some of the terms in the Global Terms sections, with explicit reference to their semantics as represented in their source material.

It is also most likely that for any external ontology which covers terms in the Global Terms sections but which is not stated in OWL or some other dialect of Common Logic, we will simply use the new metadata that is used in the main body of the model.

Detailed notes recorded on diagrams during the session.

This is the model showing our “straw man” indication of SKOS Match relationships used to reference UML classes of the canonical REA Ontology, from OWL Classes. It does not use any of the metamodel terms, and was created for illustration and exploration of these OWL to UML mappings which we went through in considerable detail on earlier sessions. It now seems, from the above exploration and discussions, that we are not to use SKOS Match after all.

So what are we to use? Discussed this.

Conclusion: We should use the same metadata as we would use in the main model, for term and definition origins (this metadata did not exist when we first looked at the Shared Semantics agenda).

One new note, recording our decision on this matter: Diagram Note:Use DC Source and/or the TermOrigin, DefinitionOrigin constructs we already have for our main content.