Would you kindly approve the following Statement as well, please?

KTH Royal Institute of Technology has successfully implemented the OSLC Query Version 3.0 Project Specification 01 (https://docs.oasis-open-projects.org/oslc-op/query/v3.0/ps01/oslc-query.html dated 01 October 2020), in accordance with the conformance clauses defined in Section "Conformance" of the specification. This use of the specification includes interoperation with other similar independent implementations, as well as integration with tools supporting other OSLC domain specifications.

Would you please kindly approve sending the following statement from the KTH side to OASIS:

KTH Royal Institute of Technology has successfully implemented the OSLC Core Version 3.0 Project Specification 02 (https://docs.oasis-open-projects.org/oslc-op/core/v3.0/ps02/oslc-core.html dated 23 April 2021), in accordance with the conformance clauses defined in Section "Conformance" of the specification. This use of the specification includes interoperation with other similar independent implementations, as well as integration with tools supporting other OSLC domain specifications.

The primary purpose of the PIM/PSM models is to separate the logical specification of a system from its implementation so that the two can evolve more independently. 

The PIM is suppose to represents the full functional definition of a system in terms that are independent of any particular implementation. In the case of the SysML v2 Services PIM, that should include a definition of all the functions provided including creating, accessing, updating, deleting searching, versioning, discovering, etc. SysML v5 model resources. The PIM is suppose to make it easier for someone who is trying to understand what the services are, separate from how they are implemented. 

The PSM is a model of an implementation technical architecture, the capabilities of some underlying system enabling it to support applications running in some execution environment. 

In MDA, a mapping between the PIM and PSM describes how the business functions of the PIM are implemented using that technical architecture in order to produce PIM instances capable of being deployed to and run in an execution environment (perhaps with some additional manual contribution). 

The goal is separation of concerns so the business logic and platform technical architecture can evolve separately, and by updating the transformation mapping, new application implementations can be created.

OSLC is a combination of a PIM expressed in RDF vocabularies and resource shapes (constraints) and REST services. Its a PIM, but not one that is expressed in UML. Lyo Designer captures mappings from the OSLC PIM to specific platform implementations PSMs through the generation of servers that adapt the capabilities of some existing system to provide OSLC services. 

For SysML Services, ideally what would happen is the current PIM would be extended to capture a UML representation of the OSLC services: discovery, delegated dialogs, resource preview, configuration management, query, the vocabularies, and the typical CRUD operations. That would provide a full UML representation of the capabilities.

Then different mappings could be created to translate that PIM into implementations specified by the SysML v2 REST Services API and the SysML v2 OSLC Services API - two similar, but different implementations. With suitable use of cardinalities in the PIM to indicate optional features, this would likely be possible.

But is it worth the effort? The current SysML v2 Services PIM appears to be a UML abstraction of the REST Services API as it has evolved. So there is a very close mapping between the two. This is good because the PIM is based on something that has been proven to be implementable and usable. 

Whether its worth it to extend the PIM to include OSLC capabilities depends on how we think SysML v2 will be used in practice, and how vendors will build tools to support that practice. Of course these two are co-dependent based on the interaction/gap between what customers demand and what vendors supply. 

But if you think SysML v2 models are wholly contained universes of discourse that would be supported by a choice of tools, then integration with other tools might not be that important to you. 

If on the other hand, you think SysML v2 models are representations of systems that are to be built and evolve over time, then OSLC integration with other lifecycle tools to support that evolution might be very important.

I had originally hoped that we would not create a situation where it was necessary to make a choice between these two views, that one could be build on the other by simply adding the lifecycle management capabilities. This is why I had hoped that the SysML REST Services API could be a minimal OSLC API - leveraging HTTP, REST, open-wold assumptions and RDF resource representations to provide a simple REST API that can be extended with other OSLC capabilities to support lifecycle tool integration, without creating yet another incompatable REST API. 

As this did not seem to be something everyone agreed with, we decided to take a more independent development approach which has resulted in the question about what to put in the PIM. If we should decide that OSLC services should be added to the PIM, I suspect it would be relatively easy to transform the OSLC REST services, and RDF vocabularies and constraints into an XMI representation of the corresponding UML model of those services. However, that opens some key questions:

1. What part of these extended PIM would the SysML v2 REST Services API be required to implement?

2. How would the existing PIM have to change because of incompatible representations of overlapping services such as configuration management and query?

3. What is the value proposition of having two overlapping but incompatible implementations of the the PIM?

I personally think there's little value in addressing these questions at this point. Rather I think the best thing to do is to provide a mapping between the current SysML v2 Services PIM to OSLC, and leave the specification of the rest of the OSLC services in OSLC. 

An effective way to do that would be to split the SysML v2 OSLC specification into two parts - the mapping from the existing PIM to OSLC REST API would be in the OMG spec, and the rest of the OSLC capabilities for SysML would be in an OASIS SysML v2 OSLC Domain Specification as you suggest.

Vendors and users will now have a choice on how they want to access their SysML v2 models. If they want simple REST services with JSON resource representations, then either API will provide that capability, although in incompatible ways. If they want lifecycle integration with other tools, then they can implement the OSLC SysML v2 Domain Specification. 

I think ultimately the success of SysML v2 will depend on the ability of systems engineers being able to create useful models of their systems, that can be built for and with reuse, that can integrate with systems and tools created by others, and can rapidly evolve to meet changing demands. So I think OSLC integration capabilities are a must and minimum for SysML v2 - we already know that from industry experience.