KERML — The MetadataFeature::metaclass multiplicity is too restrictive

The property MetadataFeature::metaclass has multiplicity 0..1. Since it also redefines type, this means that a MetadataFeature can only have a single type, which must be a Metaclass.

In SysML, MetadataFeature is specialized to MetadataUsage, which is also a specialization of ItemUsage. MetadataUsage::metadataDefinition redefines MetadataFeature::metaclass, but its type is still Metaclass, with the intent that KerML Metaclasses, as well as SysML MetadataDefinitions, can be used to define SysML MetadataUsages.

However, the checkMetadataUsageSpecialization constraint requires that a MetadataUsage specialize the SysML library usage Metadata::metadataItems, which is typed by Metadata::MetadataItem. The base definition Metadata::MetadataItem specializes both Metaobjects::Metaobject from KerML and Items::Item from SysML.

This works without problem if a MetadataUsage is actually typed by a SysML MetadataDefinition. Since all MetadataDefinitions subclassify Metadata::MetadataItem, the single type of the MetadataUsage will be the specializing MetadataDefinition that is declared for it. However, if a MetadataUsage is typed by a KerML Metaclass that is not a subclassification of Metadata::MetadataItem, then the implied specialization of Metadata::metadataItems will result in the MetadataUsage implicitly having Metadata::MetadataItem as a type in addition to the declared Metaclass.

And this violates the multiplicity of MetadataFeature::metaclass.

Change MetadataFeature::metaclass from a redefinition to a subset

The simplest resolution is to have MetadataFeature::metaclass subset type, rather than redefine it. In this way, a MetadataFeature will still have a single metaclass, but it may also have other Structure types that are not Metaclasses (like Item). This is acceptable, since it is essentially equivalent to have the metaclass subclassify the other types, which is already allowed.