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.

Harmonize name, alias, humanIdentifier from Record and subtypes in the API model and JSON schema

This proposal aims to harmonize name, alias, and humanIdentifier attributes in Record (and its subtypes) in the PIM API model and the resulting JSON schema using in the REST/HTTP PSM.

(1) Record.alias will be updated, described in the Revised Text. The attribute alias will also be added to all types of Records in the JSON schema, as described in item (4) in the Revised Text.

(2) Record.humanIdentifier will be changed to Record.name, described in item (2) in the Revised text. For Project, Commit Reference, and Query name will be redefined to be mandatory, as described in item (3) in the Revised text.

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.

Deleted element accessible in previous commits

Add a clarification for data deletion in the description of ProjectDataVersioningService.createCommit operation.

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.

OASIS haw publish OSLC Systems Modeling Language v2.0 PSD01 (Project Specification Draft, revision 01). You can access the files at:

OSLC Systems Modeling Language Version 2.0
Project Specification Draft 01
25 April 2024

OSLC Systems Modeling Language Version 2.0. Part 1: Specification.
https://docs.oasis-open-projects.org/oslc-op/sysml/v2.0/psd01/sysml-spec.html
https://docs.oasis-open-projects.org/oslc-op/sysml/v2.0/psd01/sysml-spec.pdf

OSLC Systems Modeling Language Version 2.0. Part 2: Vocabulary.
https://docs.oasis-open-projects.org/oslc-op/sysml/v2.0/psd01/sysml-vocab.html
https://docs.oasis-open-projects.org/oslc-op/sysml/v2.0/psd01/sysml-vocab.pdf

OSLC Systems Modeling Language Version 2.0. Part 3: Constraints.
https://docs.oasis-open-projects.org/oslc-op/sysml/v2.0/psd01/sysml-shapes.html
https://docs.oasis-open-projects.org/oslc-op/sysml/v2.0/psd01/sysml-shapes.pdf

OSLC Systems Modeling Language Version 2.0. Part 4: Machine Readable Vocabulary Terms. https://docs.oasis-open-projects.org/oslc-op/sysml/v2.0/psd01/sysml-vocab.ttl

OSLC Systems Modeling Language Version 2.0. Part 5: Machine Readable Constraints. https://docs.oasis-open-projects.org/oslc-op/sysml/v2.0/psd01/sysml-shapes.ttl

OSLC Vocabulary and Constraints should be generated using the same approach followed in FTF1

OSLC Vocabulary and Constraints should be generated from KerML 1.0 and SysML 2.0 meta-models using the same approach followed in FTF1, except for the updated namespace URIs to be used (SYSMOAS_-2).

This issue should be closed with no changes.

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.

OSLC Vocabulary and Constraint namespace URIs should be updated per OMG requirements

The OSLC Vocabulary and Constraint specifications are generated for KerML 1.0 and SysML 2.0 meta-models, and used in OSLC PSM of the Systems Modeling API and Services 1.0 specification. The OSLC Vocabulary and Constraint specifications for SysML 2.0 will include KerML 1.0 entities.

This proposal provides the updated namespace URI patterns for OSLC Vocabulary and Constraints, as below.

OSLC Vocabulary and Constraint namespace URIs for KerML 1.0

OSLC Vocabulary namespace URI for KerML should conform to the following pattern : http://www.omg.org/spec/KerML/<version>/vocabulary#

• Example: http://www.omg.org/spec/KerML/20241101/vocabulary#

OSLC Constraint namespace URI for KerML should confirm to the following pattern: http://www.omg.org/spec/KerML/<version>/shapes#

• Example: http://www.omg.org/spec/KerML/20241101/shapes#

OSLC Vocabulary and Constraint namespace URIs for SysML 2.0

OSLC Vocabulary namespace URI for SysML should conform to the following pattern : http://www.omg.org/spec/SysML/<version>/vocabulary#

• Example: http://www.omg.org/spec/SysML/20241101/vocabulary#

OSLC Constraint namespace URI for SysML should conform to the following pattern: http://www.omg.org/spec/SysML/<version>/shapes#

• Example: http://www.omg.org/spec/SysML/20241101/shapes#

In all the patterns above, <version> is the date timestamp when the OSLC vocabulary and namespace documents are generated from the KerML 1.0 and SysML 2.0 meta-models.

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.

OSLC Vocabulary and Constraints should be generated using the same approach followed in FTF1

OSLC Vocabulary and Constraints should be generated from KerML 1.0 and SysML 2.0 meta-models using the same approach followed in FTF1, except for the updated namespace URIs to be used (SYSMOAS_-2).

This issue should be closed with no changes.

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.

Provide API recipe to get all owned elements

A new API recipe titled "Element_Owned_Elements" is being provided as iPython notebook (ipynb) and HTML formats. This will be included in the Systems-Modeling-API-Cookbook.zip file that is referenced in Annex B.2 (Cookbook) and included with Systems Modeling API and Services 1.0 submission. The following two files are attached with this proposal.

1. Element_Owned_Elements.ipynb
2. Element_Owned_Elements.html

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.

Defer

The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future FTF or RTF.

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.

Defer

The FTF considers this issue to have merit, but, due to lack of time, is deferring it to a future FTF or RTF.