These are scattered about in the ontology, and should become subproperties of or be defined in terms of the commons 'uses' property.

This issue only impacts the ontologies, not the specification at this point.

Restructured a number of concepts and properties related to language / linguistic entities

This resolution impacts the ontologies only. Documentation for the ontologies will be addressed under API4KP-23.

Two ontologies were affected by this resolution: api4kp.rdf (the main ontology) and api4kp-lang.rdf. The changes involve a handful of updates to better align some of the properties related to language handling in API4KP, including, to the main api4KP ontology:

• separation of the dependency between hasSublanguage and embedsLanguage, including renaming embedsLanguage --> supportsEmbeddedLanguage
• making dol:Language subClassOf lcc-lr:Language rather than equivalent to it
• added api4kp:usesLanguage
• added property api4kp:supportsFormat, domain dol:Language, range api4kp-lang:metaFormat

To the api4kp-lang ontology:

• changed 'api4kp:defines some lcc-lr:language' to 'api4kp:defines some dol:formal language'
• create new 'api4kp-lang:supportsSerialization' sub-property of 'api4kp-lang:hasGrammar', with super-property of 'dol:supportsSerialization', domain dol:language and range api4kp-lang:Serialization
• create new 'api4kp-lang:supportsFormat' as a sub-property of 'api4kp-lang:hasGrammar' and sub-property of 'dol:isLinguisticallyRelatedTo', with domain dol:language and range api4kp-lang:MetaFormat

This issue impacts the ontologies which are described in Annex A. There will be subsequent revisions to the ontologies and thus we will update the documentation in Annex A in a separate issue.

This is primarily about replacing the URIs of the relevant properties with those in the commons, including the dependencies in the table on page 50.

Revised the various ontologies to reuse the commons ontologies rather than specification metadata and LCC

1. In the ontology namespace declarations, remove references to Specification Metadata and replace them with the Commons Annotation Vocabulary, and replace references that use it in the ontology metadata, including imports statements
2. Update the version IRI to 20230201, corresponding to the 4-week rule for the March 2023 meeting
3. Replace references in the ontology header that reused properties from Specification Metadata with those from the commons annotation vocabulary and eliminate those that are no longer relevant/needed.
4. Add the namespace and imports for the Codes and Code Sets, Collections, Contextual Designators, Designators, and Identifiers ontologies where appropriate to reuse properties from the commons rather than from LCC.
5. Replace concepts and properties in API4KP ontologies where there is a corresponding element in Commons.

ISO 1087 was revised in 2019 and our definitions should reflect any relevant changes as well as the references.

This change impacts the ontologies only, not the specification document.

Revise the references to ISO 1087 in the ontologies to reference and use definitions from the latest version

Due to replacement of a number of terms under API4KP-22 with their equivalents in the Commons Ontology Library 1.0, only a couple of references to the older version of the ISO 1087 standard remained. These references were changed to reflect the latest version from 2019.

This issue is strictly against the model files and has limited impact on the specification document. The specification document, which is ptc/21-04-04, should be revised to include the MD diagrams without change to the underlying model under this issue, however.

Migration is important to improve the model files and gain functionality, including but not limited to canonical XMI generation for UML 2.5.1. The eclipse implementation in UML Designer uses an older version of UML and the eclipse dialect.

Thus, the artifacts required to resolve this issue include: (1) the revised XMI file, (2) the updated specification document including the revised images, and (3) the corresponding .svg image archive.

Migration of the Eclipse model is insufficient to address the challenges - it needs to be rebuilt entirely

Because of issues uncovered in the underlying representation, rather than addressing this in two steps, namely (1) basic conversion to MagicDraw, which was this issue, and (2) optimize the model for compatibility with planned work to synchronize with IDL (API4KP-1).

The task force determined that rather than perform migration, the model needs to be rebuilt from scratch, which will be done under API4KP-1 and related issues.Thus we will close this issue with no change, and address the requirement under API4KP-1 and related issues with an entirely new model.