Support for Create/Udate/Delete operations, that propagate the change requests to the REST API

[jadelkhoury]

No description provided.

[jamsden]

I don't think this is necessary. I had hoped that it would be possible to layer OSLC capabilities on top of the SysML REST Services API. This was the motivation to get them to support JSON-LD - that would result in a minimal OSLC server. However, there are a number of reasons why I'm not sure this is really possible, or desirable:

1. The JSON-LD implementation has some sysml properties that should be dcterms (sysml:name > dcterms:title, sysml:identifier > dcterms:identifier
2. The JSON-LD returning the elements for a project is an array of elements, not a resource graph identified by the project.
3. All the URLs are to absolute version instances with the commit id as part of the element URL. This is incompatible with OSLC concept URLs and would likely be somewhat difficult to work around.
4. The SysML SST is taking a somewhat closed-world view of SysML, making decisions like namespaces, local element IDs, modeling versions and requirements as part of SysML, etc. that don't leverage existing OSLC standards like Core, RM and Config-Management. They want everything in the executable SysML models, and everything in one place, and are not really addressing integration even across SysML models implemented in different tools.
5. OMG is more about model interchange using XMI than model integration with OSLC.
6. Attempting to layer OSLC on top of the REST Services API was resulting in too much undesirable coupling: dealing with the dcterms properties, handling commits as Configuration-Context, translating all the URIs from the JSON-LD, etc.
7. The SST Track 5 team is going in their own direction of query. Layering on top of this with OSLC query is also likely to add a lot of bad coupling.
8. Performance of the REST Services API is quite slow and inhibits development and demonstration
9. It may be more useful for the SysML and OSLC marketplaces to develop the SysML OSLC server independently, but on the same meta-model so that we encourage collaboration across standards bodies and integrations, not SysML monolith solutions.

So I think we should simply develop a standalone SysML OSLC server that as a convenience can import information from the REST Services API. There is no need to keep these synchronized as that would be more bad coupling that is not in the spirit of OSLC linking over syncing.

[jadelkhoury]

I don't think this feature is top prio. But we can still aim to keep it in the backlog. I don't think it's actually a lot of work to make it work.
From a Lyo/OSLC perspective, it would be interesting to demonstrate how a Lyo-based implementation can interact with the backend tool (in this case the Sysml server).
An implementation based on a triplegraph doesn't really reflect a true complete implementation. that's why I'd like to see if we can implement this feature.

[jamsden]

But this is a syncing approach to integration with redundant data. This is not the approach recommended by OSLC. If you want the data to reside in the REST Services API, then the right approach would be to adapt that data source, not replicate and sync.

[jadelkhoury]

I see the Store as an internal implementation. As long as the synching is not advertised, so don't really agree that it is not a recommened approach. OSLC says nothing about implementation.

[jamsden]

But the SysML REST Services Server and SysML OSLC Server are two different integrated servers. OSLC architectural guidelines would recommend adapting or linking these two implementations, not syncing redundant data.

[jadelkhoury]

Interesting. I am viewing this/our SysML OSLC Server as an adaptor to the non-OSLC tool "SysML REST Services". With this perspective, whatever is in between the 2 components is internal to the implementation and hence of no relevance to OSLC guidelines.

Anyway, we will most likely not have the resources to support Created/Update/Delete. So let's take it when the issues arrises?