OSLC-OP is working on publishing an OASIS multi-part specification:
OSLC Systems Modeling Language Version 2.0. Part 1: Specification
OSLC Systems Modeling Language Version 2.0. Part 2: Vocabulary
OSLC Systems Modeling Language Version 2.0. Part 3: Constraints
OSLC Systems Modeling Language Version 2.0. Part 4: Machine Readable Vocabulary Terms
OSLC Systems Modeling Language Version 2.0. Part 4: Machine Readable Constraints
This is the same as other OSLC servers and RDF vocabularies, and that Systems Modeling Application Programming Interface (API) and Services can reference these documents instead of directly including copies in the OMG specification zip file. The vocabulary and constraints would also be published on open-services.net and accessed using the namespace URL.

The Part 1: Specification describes the conformance clauses an OSLC SysML server meets. It references OMG Systems Modeling Language. https://www.omg.org/spec/SysML/ for all information on SysML. It is a standard for an OSLC server supporting SysML, with vocabulary terms providing an RDF representation of the normative OMG SysML v2 XMI.

See file:///Users/jamsden/Developer/OSLC/oslc-op/oslc-specs/specs/am/architecture-management-spec.html which is a similar specification following the same pattern.

I expect to have a draft project specification published by OASIS soon.

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.

This namespace will be published at http://open-services.net/ns and will provide content negotiation for tools to be able to access the vocabulary and constraints in various RDF resource representations.

All OSLC domain specifications use an open-services.net namespace, e.g., http://open-services.net/ns/am#. The same namespace is used for vocabulary terms and shapes for consistency, and to support navigation to specific sections in the vocabulary and constraints documents for elements of the namespace. The namespaces URLs also provide machine readable access to the RDF resources for use by tools.

RDF namespaces can include version identifiers, but for OSLC integration standards, the OSLC-OP recommends against inclusion of version identifiers as that introduces integration incompatibilities as the standards evolve.

The section OSLC 3.0 API section in Systems Modeling Application Programming Interface (API) and Services will need to be updated to refer to the correct namespace.

The spec says: "DataVersion.identity should be populated with the DataIdentity that will be deleted in the new commit. When a DataIdentity is deleted in a commit, all its versions (DataVersion) are also deleted,"

This sounds wrong - presumably DataVersions referenced by earlier Commits need to be maintained. This does seem to be the way that the reference implementation behaves.

The spec says: "DataVersion.identity should be populated with the DataIdentity that will be deleted in the new commit. When a DataIdentity is deleted in a commit, all its versions (DataVersion) are also deleted,"

This sounds wrong - presumably DataVersions referenced by earlier Commits need to be maintained. This does seem to be the way that the reference implementation behaves.

The API PIM specification has a Record entity with humanIdentifier attribute. Commit entity inherits from Record, therefore it is expected for humanIdentifier attribute to exist in Commit entity as well. This is not the case at the moment when looking at the API JSON schema.

humanIdentifier is crucial for tool vendors to be able to relate commit UUIDs to version identifiers that are specific to the different versioning schemas used by different tool vendors.

The API PIM specification has a Record entity with humanIdentifier attribute. Commit entity inherits from Record, therefore it is expected for humanIdentifier attribute to exist in Commit entity as well. This is not the case at the moment when looking at the API JSON schema.

humanIdentifier is crucial for tool vendors to be able to relate commit UUIDs to version identifiers that are specific to the different versioning schemas used by different tool vendors.

In the API PIM, under ElementNavigationService, there's a getElements service which is dedicated for dumping the entire model content at a given commit.

This is an overkill for a use case when only part of the model content (e.g. a package) is required to do analysis (or any other task) on.

While theoretical a workaround could be used via getRelationshipsByRelatedElement by retrieving all of the owned elements under specified owner, this would result in gazillion separate calls and would not be efficient under slower networks.

Proposal - introduce a new service getOwnedElements with an ability to collect all of the owned elements recursively under specified root or enrich getElements with optional arguments allowing to achieve the same.