id is not an acronym but short for identifier. So for consistency with the "id" property, and camelcase rules, they should be humanId and aliasId

Update capitalization for humanID and aliasID

"humanID" should be changed to "humanId"
"aliasID" should be changed to "aliasId"

Though Vocabulary in SCE would correspond to Dictionary in MVF, since SemanticElement in SCE corresponds with MVFEntry in MVF.

The refactoring of Vocabularies to KindSets changed the scope of this issue

SCE-7 involved the restructuring of the Vocabulary and SemanticReference capabilities. KindSets are simple, extendable lists and are not related to MVF the way vocabularies would be.
Thus, we can close with no change.

The documentation for id says "uniquely identify" but not the scope - within a single model, universally?
And for humanID (sic) it's also vague: "the uniqueness of this identifier within a model or relative to some other context."

The intended usage is unclear - calling it "human" does not seem helpful since it's presumably not for human consumption e.g. for display on a diagram?
And "human" is also wrong if the model was generated by a tool, i.e. the "modeler" is not a human.

Without further rules, or a compliance point, interoperability becomes unnecessarily hard.

Remove humanId and make aliasIds a list

The humanId was added to make SCE consistent with KerML (as it was being developed). However, the final beta version of KerML (ptc/2023-06-01) does not include humanId (perhaps because of the inconsistencies identified by this issue). Thus, we can remove it.
Further, we should update the aliasId property - to aliasIds and update its description as necessary.

Name is odd if it's meant to represent a specific version. For example OWL uses versionIRI for this.

The property conceptNamespace is being removed through SCE-7/SCE-8

The issue resolving semantic references and kindsets removed this property, so this issue can be closed.

The current SCE XSDs were developed with a faulty translation of UML class relationships to the XSD elements.
To resolve this issue we need to specify the XSD patterns that correspond to the UML class relationships and then update the XSDs.

Use same MM-XSD Mapping as in BPMN, CMMN & DMN

Use the MM-XSD mapping approach that BPMN pioneered for the BPM+ ecosystem to remain backwards compatible (for SCE-40) and allow vendors to reuse their existing language tooling based on that mapping. SDMN is following the same approach in SDMN-111.