The Expression::result property in the KerML abstract syntax is suppose to subset Step::parameter, where Step is a superclass of Expression. However, in the normative KerML.xmi it is erroneously specified as subsetting Behavior::parameter, which is a different property than Step::parameter. Further, Behavior is not a direct or indirect superclass of Expression, so the subsetting is invalid in MOF/UML.

(Note that this error is not apparent in the specification document, because, in the annotation for subsetting, the subsetted parameter is shown without qualification – e.g., just parameter, not Behavior::parameter.)

API4KP uses a tunneling approach where 'models' of various nature are wrapped in an API4KP "KnowledgeCarrier" object that adds some necessary metadata about the model.

Implementations that require transport (e.g. based on ReSTful web services) face two problems:

• the serialization format of the wrapper (JSON, XML or else)
• the representation and serialization of the model (in various languages, across serializations and formats)

The former is a classic content negotiation problem, and is expetcted to be handled in the standard way, using Accept-* and Content-* headers

The latter is a similar but distinct model negotiation problem. The standard mandates not to use the content negotiation headers - so that, for example, a BPMN+XML model can be serialized and embedded in an API4KP+JSON KnowledgeCarrier.
Insteadd, API4KP model negotiation defines an "X-Accept" header for requests, and uses the KnowledgeCarrier body itself for the analogue of the Content-Type response.

The use of a header, as opposed to a query parameter, has pros and cons, and should be discussed.
Ultimately, it comes down to the ability to provide a (persistent) URL to a specific knowledge artifact, using a primary identifier composed by the ID of the carried knowledge Asset, plus a coded identifier of the artifact's form

Options:
(1) keep xAccept as it is
(2) replace xAccept w/ qAccept
(3) add qAccept as an optional parameter, together with xAccept

I am strongly inclined towards (3), for this reason:

• {assetd}/carrier
  return (any) "canonical" model form
  
  * {assetd}

  /carrier ? qAccept=formB
  return model form B specifically

• {assetd}/carrier
  xAccept=formB
  retrieve or generate formB using any form available
  
  * {assetd}

  /carrier ? qAccept=formA
  xAccept=formB
  retrieve formA, and use it to generate formB if not the same

Background references:

https://softwareengineering.stackexchange.com/questions/250602/why-doesnt-the-html-dom-specification-allow-hyperlinks-to-set-an-accept-heade
https://stackoverflow.com/questions/374885/can-i-change-the-headers-of-the-http-request-sent-by-the-browser

Reproducer:
Api spec - KnowledgeAssetRepository :: addCanonicalKnowledgeAssetSurrogate

the body parameter does not specify a content type, which is defaulted to /. Swagger-CodeGenerated clients pass the value to the server, but the server may reject any payload that does not have an explicit content type.
This behavior has been verified with Spring-Web (2.7), but also (independently) with some enterprise firewall rules.

Either way, the spec should be explicit, and the use of content types should be reviewed across the 5 OpenApi documents

The levelTag parameters is incorrectly specified as a body parameter - a role that shuold be reserved to the main operand, the carrier of the artifact to be processed.

The parameter is a coded string, and does not need to be a body parameter