SYSMOAS_ — The OSLC SysML v2 vocabulary, like the JSON schema, is standalone, merges KerML into SysML v2 XMI and does not import or specialize KerML

This is perhaps not an issue and may require no action other than acknowledging that it is being done, and isn’t formally following KerML semantics.

If this is not acceptable, then we can generate the OSLC SysML v2 vocabulary to import and specialize KerML. That would add some additional work and redundancy, but could be done.

If this is adopted, then there is no reason for the OSLC 3.0 API to define the KerML vocabulary and constraints, hence the reason it is not include in #1 above.