21 Jan 2016
Mike described he history and general landscape to make sure everyone was up to speed.
We looked at the complete list of “anti-patterns”. These are numbered in a spreadsheet, and the numbers appear on a diagram showing the modeling environments and transitions between them.
There were suggestions on opportunities to automate parts of that, addition of tests and so on.
Mike is some way through the EA-based fixes.
Adaptive have offered to render the required simple restrictions. These correspond to what were implicit restrictions in the way the original EDM Council SME group approached these models. These will be given a default of someValuesFrom, with fine tuning in the OWL environment for any that should self-evidently be something different. Note that some legacy models use the UML Multiplicity for e.g. 0..* or peculiar cardinalities like 1..12, so if these can be detected and translated into cardinality restrictions that would be great. If these will be done later in OWL, via inspection of the legacy diagrams.
There may be more things that can be automated in Adaptive, either in full or as a starting point for subsequent edits in OWL.
We can run tests on the OWL as it comes out of Adaptive, and feed back to potential changes in the XMI
#4 For Object Properties that have no parent – these are automatically a child of TopProperty anyway in OWL, so this is not really an anti-pattern. Mike will review and add parent properties to tho few OPs that were intended to have a parent but were left hanging in draft models.
#5 For Datatype Propertie that have n parent – we should be able to get Adaptive to do something automated, for this
#6 the required pattern for unions that represent a business concept, can potentiall be automated by Adaptive in the transformations, since we can specify the required pattern easily. This is that the union remains as an anonymous union, a class is created for the named concept, and an equivalentClass axion is created between these two.
However, in the 2014 fixes Mike removed names from all unions. Also there are two cases where unions appear, the other being (#7) as logical combinations of things that may be the range of a property (the same as is done in OMG FIBOs). We woul therefore need to distinguish between these two usages of unions.
Proposal for#6 and #7: Pending confirmation that Adaptive can process this - In EA, reinstate the names for those unions which represented business concepts, and get Adaptive to process these according to the pattern given above (class with the name, anon union with the members, equivalent class relation between them), while the ones intended as property range combinations remain anonymous and are processed as before.
#8 Enuerated data ranges – Dean is not sure what the current correct OWL construct is for enumerations of literal values. Some of the existing Enumerated Data Range elements will remain as this.
For those enumerations which should have been sets of sub classes (i.e. lazy modeling, from mainlyWG11 UML models), Mike will add the classes, e.g. kinds of Method, in EA. For some others however, the “Classification” approach proposed by Michael Uschold will be used. Those latter ones can possibly done in the OWL editor environment (CCM or TBC).
#11 Clarification on bad inverses: there are really 2 things going on (split into #11 and #11a):
That is, #11 represents sins of commission whereas #11a represents sins of omission.
On #11a, there are two considerations:
1. Dean suggests that in OWL itself, a desirable end point is to have both a property and its inverse, and for one of those properties to have a domain and range, but for the other property not to have domain and range, since these can be inferred by the reasoner. This is not possible in the EA models (every property has to be nailed down at both ends), so if we did this it would be a removal of a large number of domains and ranges in OWL.
Note this is different from an earlier proposal which was to not have the inverses at all, since their existence can also be inferred by the reasoner, albeit without names.
2. Names: Given that it is possible to infer and thereby generate missing inverses, these would then not have names. Are there simple ways to generate a kind of ersatz name, which could then be updated by hand?
We did not reach a solid conclusion on this. If all the possible missing inverses are added by hand in EA< then (2) above becomes moot but under (1) above, someone would then have to go through the model in OWL and remove the ranges and domains. That is a lot of work also.
#15 – since the majority of annotations should be FIBO-AV:explanatoryNote, we should ask Pete if it’s possible to make that the default. Then those few that should be editorialNote can be changed back by FCTs. If not, we will stick to the current arrangement which translates these into editorialNote, and let the FCTs decide which ones to promote to explanatory notes (#15a).
#16 “Random Bad Stuff” – Mike clarifies that this is a catch-all for some odd patterns that were mainly removed in the 2014 conversion but some might have been missed, plus the addition of various bits of prototyping work (including prototypes of ways to represent restrictions) that have been done since the original EA model was deemed to be retired and was used only to originate illustrations.
We will meet again early next week to identify next steps an firm up the actions.
Some of the above changes will also require Pete Rivett’s feedback – Mike to mail him with further questions.
This meeting as a Word doc: